A lot of questions about the nature of cards can be answered by the Card SDK (our software development kit). It’s like building apps for the Apple ecosystem, where you have an iOS SDK or an iPadOS SDK, which gives you a standard set of tools. Once you get into the tools and you understand the API, you can build an app that fits very nicely within the iPhone (not just when you open it up full-screen, but also in the way you share, save to camera roll, use widgets, or swipe the thing and flick it away). The SDK controls what the card can and cannot do, as it provides a lot of power through well-defined APIs.

The Card SDK (a front-end / back-end concept) runs on the Cardstack Hub. The hub is our decentralized application server. This means that the same card and the same code can run on many hubs. The same way Microsoft Word can be installed on different computers, the same app can be on different devices — whether that’s on a server on a personal computer or hosted in a cloud. Cloud deployment means that these hubs, which are run by service providers, are instantiable in a cloud (like an Amazon cloud) or in a data center based on hardware.

Allowing us to do all these things requires the framework team to think about what kind of templating UI, tool kits, and server runtime they want to use. In this case, we chose Ember.js, because we have deep relationships with Ember and a deep understanding of how this very mature JavaScript framework works. Additionally, we are using NodeJS — which is the hub (our application server is basically a NodeJS server) — with a very specific type of patterns, plugins, and middleware that allows us to do it the Cardstack way. When we run the hub and we need to index data or do searches, we use Postgres, which is a standard open-source database. Any dependencies of running services, including Postgres and the Ethereum back-end, are managed by Docker.

While we are working on this full-stack technology — starting with the framework — we want to tap into existing open-source tools as much as possible, so as to enable people who know these tools to be productive right away. Therefore, a big part of the Cardstack Framework is really about learning our version / adaptation / orchestration of all these tools: Ember Core, NodeJS, Postgres, Docker, etc.

Product team: environment (9:23)

Once we have the framework (which is basically an SDK), we need the environment.

The analogy here would be that there’s a home screen on your iPhone, which a developer of an iOS app doesn’t have to build. Plus, there is a way to control volume and camera. These are standard environments that already exist (almost like the OS on your desktop). And that’s what the product team at Cardstack is working on — the team that we want to grow to 100+ people. There are many new things coming (workflow, space, different types of environments, a library for searching, etc.), all of which are standard. Every single card that is built using the Card SDK benefits from these standard sharing or zooming controls. And that’s the idea of the Cardstack Framework. Using the framework, product developers build these standard experiences for mobile or desktop, so that users have a space where they can store files, workflows to interact with other people, and a catalog to share different cards. That’s all part of the product.

This product area requires a somewhat deeper understanding of the Ember ecosystem — like using add-ons for dialog boxes and UI components. For Cardstack add-ons, we tap into the Ember.js community, with all the pre-built components that exist in the add-on ecosystem. This means that a Cardstack add-on is actually an Ember add-on and we have a really rich library of add-ons to utilize.

Back-end engineers: integration cards (11:02)

Once we have this environment, we can start thinking about the type of integration (adapter to back-end systems / data sources) we need.

What sticks out, especially for people in the Web 3.0 or dApp space, is that this is how we talk to Ethereum. Ethereum is a data source. It’s an adapter that exists as a plugin to our hub framework, allowing us to get the latest data from the Ethereum ecosystem and index it. Then, we can get a list of something or provide the data to a card — for instance, rendering the balance of a particular account that contains DAI, ETH, or CARD tokens.

But here’s what’s really interesting: This is not the primary data source. Unlike a lot of dApp frameworks, Cardstack’s default data source is not a blockchain; because a blockchain is a specific type of data source / data destination / database / ledger that has certain trade-off characteristics. It’s very good for high-value stuff, because it has double-spend protection, it needs consensus among several people, it can’t be faked, and it is append-only. But if you want to simply store a bunch of information about something you created in the last five days (say you’re making music) on-chain, that would be prohibitively expensive. A megabyte of storage costs about USD 100.

Storing everything on-chain and relying on the blockchain to accept information would be relatively slow and not very competitive. That is why we use a chameleon of data sources: Git. Git is a data source that doesn’t really have a place. It is a version control system that controls versions of files. And it could run on the computer or on the server, since it is just a file system similar to My Documents, where people can store things. But unlike My Documents, Git has a precise way of managing these metadata. When a card wants to store some data (like a new survey or a new event), that data can be written to Git in a very precise way, using JSON or different encoding. Git, as a technical architecture, is actually very close to blockchain, because Git databases / repositories are basically a hash-linked, immutable append-only ledger. It is content-addressable like IPFS, so we can use cryptographic hashes to keep track of these progressions.

Using Git as a default data source means any card can first exist in Git. Then, we can use that data source to say, “let’s bring that Git data structure of an event / survey / payment into Ethereum or Google Calendar, or the future Ethereum or EOS version of Google Calendar.” So, we see back-end engineers — people who know how to use NodeJS and the extension we’ve added through the Cardstack Hub, and who know how to interact with REST APIs and databases — come and build new plugins; whether it’s to blockchains, to Stripe (to do credit card payments), to GitHub (taking what is in Git and allowing open-source contributors to come around), or to Gitchain (which is like GitHub without the centralization aspect; we use blockchain and IPFS or Ethereum as a way to anchor this Git history to a much more open network that is not controlled by a single company like github.com and the corporate parent Microsoft).

Plugins can be encapsulated as integration cards. They are essentially configurations like a printer driver — you install it and set up your credential, “here’s my EventBrite login, here’s the key, here’s my membership, here’s my tier.” When something is created, we can use that integration card and the corresponding API, and syndicate that data to a cloud or, in some cases (“here’s my Ethereum address, here’s my key”), we can actually syndicate that information to the blockchain.

Integration is a modular system. The only real, official data source we support is Git. Other Git implementations — on-chain or in a cloud, like GitHub — will be done through integration cards, which back-end engineers build and offer, saying, “I’ve installed this new integration, so you can take your survey and put it into this enterprise system.”

Front-end engineers: common cards (15:48)

The front-end now takes advantage of the fact that there is a default data source to create common cards.

Here’s an example: Before we think too much about what an article is (Is it like Medium or is it like WordPress, is it like Facebook or is it like the New York Times?), we need to realize that they’re all branded versions of what an article can be. At the core, an article is an article: It has a headline, a byline, tags, etc. And it turns out that this idea — that there is a lot of commonality between different kinds of articles, resumes, recipes, events, or movies — is something search engines care about.

The reason why search engines are important here is that they made the Web, with all its variety, searchable. Google is the most famous one, but there are many others, including ones in other languages around the world. A search engine figures out what’s in common; so that a Google News search can show all the relevant news articles, headlines, and pictures in the right place.

And the search engine needs to get these metadata — these common schemas about what a survey is, what an article is, what a place is, what a location or a product is — from the people making websites or e-commerce sites. That’s why there’s schema.org, which says, “If you want to tell the search engine about your unique type of movie review, please tag your Web page with these terms.” These terms basically became the common nouns of Web 2.0 (our current Web).

Google takes advantage of this to surface products people search for or to show places in a map with GPS coordinates, addresses, and phone numbers, for instance. To do this, Google uses the information that is marked up on the website or in an email to a customer. “If you send a receipt, please mark up the price and the purchase date; if you send a boarding pass, please mark up the seat, the airline, and the confirmation number.” Marking up these nouns in emails means sending schemas that Gmail collects; and now, it shows the customers (through their inbox or Google home device or Android device) that “your flight is leaving in 23 minutes.” How does it know that? It’s because of this commonality.

What does that mean for the Cardstack Ecosystem? It is such a good idea to use schemas as a way to create commonality across different implementations of user experiences, websites, and e-commerce sites, that we should start with this and not just end with it. Initially, the Web was a messy place, where all pages looked completely different and had no metadata on them. Now, because search engine discovery / searching optimization is so important, people tag their websites with these schemas; they create very different-looking implementations on a Java-based Oracle database versus a Shopify system. They all speak the schema.org of what a product is.

Since we are building a new decentralized ecosystem, wouldn’t it be great for us to start with the common nouns? We could say, “If you want to build an event catalog, why don’t you start with the event card?” Not only does it have all the schema.org language already defined; it also comes with an editing form (to edit the time, how often it repeats, etc.), because the card is a mini-application. And when we build these common cards, we build in dropdowns and design systems, to guarantee a great standard experience. The goal is that this looks very much like what you get on salesforce.com. You can create a new product, add fields to it, and have a standard UI that’s pretty decent (it may not be the most attractive or customized one, but enough to capture information).

We look at schema.org and beyond, at payments and all this stuff, and ask, “What are the common nouns that allow this new Web 3.0 ecosystem to thrive?” Borrowing heavily from the knowledge, the taxonomy, and the understanding of actions — “I want to cancel my flight,” so okay, there’s a “cancel” action that’s actually in the schema.org definition — we want to create these common categories of cards that are connected to the default data source. We could write one for calendar providers, so that one click updates the Google Calendar event automatically. But newcomers (who don’t have the ability to be Google or Microsoft) can create a plugin that works with this common schema.org event base card in the Cardstack ecosystem; then, anybody who uses this event card will have another option, through a little drop-down that allows them to connect to this ecosystem.

We use common cards as a starting point to build this decentralized ecosystem, to allow back-end providers, integrations, or even new blockchains (like a calendar or event blockchain) to get into the user experience of the system.

Web developers: template cards (21:17)

Common cards are fairly boring, right? They are usually design-system driven, very standardized, and easy to learn how to use. But the Web is an interesting and diverse place, and that’s where template cards come into play.