Cardstack’s Development Frontier
As we build up the stack, we strengthen everything underneath
In Part 1 of our project update series, you read our vision for creating a Web 3.0 that combines the best of Web 1.0 and 2.0 with the promises of the Web to come, while eliminating the rampant lock-in effects that currently leave users without control over their own digital lives.
Part 2 describes how we’re advancing this goal of digital sovereignty using cards, which are carriers of truth for the Web. The article explains how cards enable radical composability: the ability to build, share, and reuse work with others while maintaining consistent ownership.
In this blog post, I will briefly explain how Card UI is made possible by the Cardstack Hub, our data fusion layer. Then I will explain our ongoing progress in building the full stack around it.
How Cardstack Does Data Fusion
Our revised roadmap, featured in my last project update video, shows off Cardstack’s development frontier: every time we move to the right on our roadmap, we’re moving up the stack. The more we build, the faster we get, and all work strengthens the underlying codebase.
The first layer of our roadmap is the Hub. The Cardstack Hub is the data fusion layer that provides the foundation for everything else in Cardstack.
When a user runs Cardstack, the Hub is the webserver powering it. It is the home for your cards. When you compose cards together, the orchestration happens inside your own Cardstack, so your data objects are interacting within an environment that you own and control.
Hubs can also talk to each other, and the outside world. So if you want to build something with others, your Cardstacks sync up so that you can compose your objects together. When you want to push your changes onto the Open Web, your Cardstack does that for you too.
The Hub uses plugins to talk to different kinds of data sources, including blockchains. Each new plugin increases the power of a user’s Cardstack by allowing the user to create and use cards that represent new kinds of data.
Here’s some of the capabilities we’ve already built for the Hub:
- Ethereum and PostgreSQL plugins that take information on-chain and make it queryable and indexable
- Git plugin that can ingest content from a Git repository (e.g. GitHub)
- Drupal plugin that can ingest content from a Drupal content management system
- Card UI design and movement principles of Card Deck, Card Space, Card Flow, and 4 Edges
- Dozens of card types
- Use case templates
Currently we’re moving full speed ahead to ship use cases that take advantage of these capabilities, to demonstrate the potential of radical composability.
How Cards Change the Web Development Model
In today’s world, dApp development follows the app store model: build an app for one very specific thing then distribute it. But there’s a better way to get usability and scalability outside of this “one feature per dApp” system.
Cards aren’t just a fancy way to represent data. In the Cardstack ecosystem, cards form a living library of open-source functionality that can be shared and reused.
As a developer using Cardstack you’d have a leg up because there’s just so much you can use off-the-shelf. You can choose from the library of card types and templates, so when you’re building your own Card Space you have a catalog of everything you’d need.
As you build, you’ll be contributing to a community-owned ecosystem and participating in an open-source network that distributes power among its users. Sharing code gets us toward a richer, more innovative, more collaborative world.
Metering and Billing
Cardstack’s goal is to compensate open-source creators and contributors fairly. We want users to pay a fair amount for the software they use, and makers of software to receive a fair reward without a middleman having to determine who gets what.
We’re developing a metering and billing system for software usage that makes buying and selling software as simple as an e-commerce transaction or filling up a prepaid phone card.
The Cardstack Token (CARD) makes this possible. CARD is universal fuel, which means it acts as a single unit of account for all the transactions that happen within the Cardstack ecosystem, even if the underlying transaction is being conducted in fiat currency or another cryptocurrency.
To accomplish this, we are pioneering the CLUTCH compliance mechanism — a one-way staking function. Short for ‘Conditionally Locked Until Token is Contractually Handed Over’, CLUTCH allows the Cardstack Token to be locked from trading when it’s being used for its utility or access functions, then unlocked when conditions are met.
We’ll be releasing a technical paper that describes this soon.
In the weeks to come, you’ll learn more about the use case templates that we’ve described above. Before long, you’ll be able to try building with the card types we’ve been working on.
Our goal is for community members to play with a kitchen sink of many card types we’ve created and make something of their own. That’ll let developers and end-users build upon our resources by contributing their own ideas, driving new usage and expanding our network. You don’t need to be a blockchain engineer to get started — anyone with coding experience can add to the project.
Starting next month, we plan to share team demos on our new Discord channel, with the first demo showing our progress on the media metadata registry use case.
Sign up for access here, and take the next step with us in the journey toward building the full-stack framework for Web 3.0.
Chris Tse (@christse) is a technologist and designer. In 2014 he founded Cardstack, where he leads a team of open-source contributors to build the experience layer of Web 3.0. He previously co-founded two startups that pioneered use cases for distributed ledger technology, and has more than a decade of experience leading R&D and innovation teams for Fortune 500 companies.