Ultimately, the point of snapshots and this encapsulation of data and code is to do something relatively simple: We want to create this idea that cards are completely mobile. So, your ticket card — which contains its own template, its own look and feel, the fields, the linkages to Google Calendar, the payment, the snapshot data, and the link — is just one JSON file. All of this is just one data structure, much like everything in your financial model is just one XLS file. That one thing is the code + the data + the value, and it exists in your library. You can also submit or share it. Say you bought a ticket that you put on your home page, which runs Cardstack, and you want to gift it to a local NGO, because it’s a nonprofit that gives underprivileged kids access to this amazing concert. You can send them your ticket through a workflow system or just by copy- and pasting the URL. But that URL (unlike a YouTube video) is actually pulling all the information — including the ticket, payment, transfer, and maybe even blockchain records of who owns the ticket — and giving it to this new shared workspace.

This is not about installing or uninstalling apps, or making sure that versions are compatible (Is it the same WordPress? Do you have an Airtable account?) None of that matters anymore. Is your Airtable aligned with my fields? Of course not, because the schema and the data are separate; they are different between the tenants in a multi-tenant system. But Cardstack completely encapsulates it, so that you don’t have to worry about tenancy anymore. Every workspace, every library, every site, every network, every registry, every consortium is just a folder that contains these cards. A card contains its own data. And if you want to compose it, the cards provide the APIs and service to each other. Most importantly, the Cardstack Framework does all the hard work. All the things we talked about, all the layers of architecture, all the tools and APIs we’ve built — all of this is about creating the illusion that a card is a physical thing you can exchange with the people you like. And when you exchange it, the card goes where you want it to go, including all things necessary. To render it, to link it, to see it, to reliably render it even if you don’t have the permission — all that exists within this promise that is provided by the card stack.

Status & strategy (33:47)

1. Current open-sourced projects are on Card Schema V1 and will continue to work: Card Board, Card Folio, Tally, dotBC Music Registry, Card SDK Project Template

As we embark on the upgrade of this framework, we acknowledge that we have a lot of current open-source projects that are on the first version of schema (Card Schema V1). There’s usually a Git repository with the definition of the file, and then another one that is appended with “-data” — this one has all the data, such as content for articles and images for Card Board; cryptocurrency addresses for Card Folio; prepaid-card accounts, service providers, and billing relationships for Tally; music recordings, albums, and artist release schedules for the dotBC music registry. We are also creating a much simpler Card SDK project template for new developers who want to learn about Cardstack. They can see how card schemas work and get this idea of encapsulation. But these are two separate kinds of repository.

2. Future projects will use Card Schema V2 to support use cases that require multi-party, multi-hub, and multi-version workflows: Card Space, Card Flow, Card Catalog, Multi-Git Registry

Going forward, we will continue working on Card Schema V2, until we can release and start using it. We see a lot of use cases where multiple parties need to work together, exchanging data. So, if someone says, “here’s a new license request; if you fill it out, you’ll be able to get this blockchain license of my song or movie,” that means we have to encode the form to apply for the license, the legal language, the version history of negotiating the terms, as well as the payments (which can be done in cryptocurrency or the traditional way). All of that requires the card V2 encapsulation of app + state + link.

We also see a world where, instead of having Card Board as your blog, you have a multi-hub federated network, where you can exchange articles and syndicate between communities. If someone creates a new article type, which includes a card that could be some data-flow-diagram-based visualization, that card has its own template, its own logic, and you can install it. The hub brings in those schemas and dependencies, with the Card Catalog providing protection. It acts almost as a registry, which uses some additional cryptographic or other type of moderation technique to make sure that the catalog you can depend on (that allows you to share and move across card boundaries) is safe, similar to chrome plugins that you can install in your browser. And that’s what we call Multi-Git repository. The catalog itself is a Git repository containing cards that are submitted and version-controlled by the community or by sellers of premium ticket templates. Card Flow is the way we move it all. And Card Space is how you accumulate and build your own personal library.

As we work on this, the basic structure of a card is not going to change. But the way we encode it, the way we allow these cards to be stitched together through Card Schema V2 allows us to accomplish a really flexible multi-party workflow that will be the foundation of the decentralized way of working, of sharing information, and of conducting business transactions that get you paid and create economic value. So, while Card Schema V1 and V2 will coexist, future Cardstack products will use Card Schema V2 to enable multi-party workflows.

3. Create more with less code — user interface to compose the complete card (schema + templates + data) using only a browser: Leverages the four edges of the Cardstack environment to point and click to a Cardstack app

Card Schema V1 supports some sort of light editing. If you define your schema, we give you editing tools (the right edge) that show you all the fields inside that particular schema and allow you to edit them, even if you don’t provide your own editing template; you just click on something and we give you the field editor for that. Yet, one important design goal for Card Schema V2 is to let people add a field. Imagine you download an article template and it’s missing one field that allows you to make a corporate blog; you want to be able to add that one field. And because the definition of the card (the article card or your derivation / adoption of that card) is just a JSON file, it is easy for us to create a user interface that allows people to create schemas. This is similar to adding a column in Excel or a new field in Airtable. Those types of user interface (what we call the Four Edges in the Cardstack environment) provide the tools for power users to not only look at a website, but zoom out a little bit and see the tool palette, so they can change the look, the layout, and maybe the template or the structure. They could add a field and decide whether or not they want to accept cryptocurrency as payment. These are all configurable. Some of them will actually change the schema, not just the data. And to the degree that makes sense, we want Web developers who know HTML, CSS, and a little bit of JavaScript to say, “I want to make this ticket or this event or this invoice or this presentation look a little better. Let me go into the little coding panel (like what you see in CodePen), start making modifications to the markup, and have the card reflect the latest changes.” That’s the type of foundation we are building.

One of the major projects that will enable this is Embroider. Our lead developer Ed Faulkner has been working with the Ember community as well as the Cardstack team to build a new build system, which leverages Webpack and connects to the Ember ecosystem — a big part of our framework is on top of the Ember stack — so as to enable much more dynamic loading of new components. Those new components could be new controls for you to edit fields; for example, if your need a fancy date range editor. But the entire card itself — this invoice card or podcast card — is actually just another module; in JavaScript terms, every single card and every single field inside every single card is an NPM module, which we can install in real time as the user encounters it. Say you receive a new licensing request; that’s when your application loads or auto-imports the necessary code to render the template, giving you a drop-down control or letting you select how many impressions you want to get, and changing your licensing price based on that limit.

So, creating more with less is about providing the tools to allow many more people to create, iterate, and share in this card-based economy. We want to break out of these apps on our phones that we both love and hate. Only iOS developers and Android developers can craft these perfect nuggets of scrumptiousness. But in fact, these apps are little prisons of our data that don’t want to interact with each other. The card vision, which is based on the World-Wide-Web vision (that’s why we call ourselves the application site for Web 3.0), is about recombining these pieces that are now locked into apps with branded icons on your home screen, and letting them flow a lot more fluently. This way, it’s all in your workflow within your space, shared in the catalog. And we use open-source tools like Git and blockchain to share that between different people.

We have been trying to rethink what a document-driven, a unit-of-exchange-driven economy on the Web is going to look like. We will get closer and closer to realizing this vision. Card Schema V1 gave us most of the plumbing for indexing, display, rendering, login, logout, and search. And now, we want to make it one level better, so that the new encapsulation actually makes a federated, decentralized Web a reality — not just in theory, but in the same scrumptious, amazing user-interface-quality you expect from an app that you subscribe to today.

Learn More

Star Cardstack on GitHub and join our Discord channel or our Telegram group and announcement channel to get all our latest updates.