Who Are the Card Makers?
Their skills and their roles in the Cardstack Ecosystem
It sounds simple: Card makers are the people who make cards. But who are these people? Which skills do they need to learn? How many of them do we need for a rich ecosystem? And when does each type of card maker get involved?
To answer these questions and contextualize the architecture of the card stack (the software stack of Cardstack), we present a model called the “Inverse Pyramid Model”: The large numbers of people who make cards are at the top of this pyramid, while those who make the tools for the people who make the cards are at the bottom. All participants of the Cardstack Ecosystem can apply their individual skills to be productive at the different levels of this inverse pyramid.
The Inverse Pyramid Model (1:05)
The inverse pyramid consists of several layers and is a bit of a continuum, as the different tools blend into each other; a programming tool used at the bottom may be something you can access in the middle as well. Yet, there is a clear separation between the skill sets needed in each layer.
Essentially, this pyramid contains all community members who will be contributing to the making of cards. At the bottom is the framework — people who write the software. At the moment, this is largely the Cardstack team, who provides the SDK and APIs which the product team uses to create experiences. Based on that, we can adapt to different back-ends. Then, we put front-ends on top of our back-ends. Web developers create and theme new interactivity around those front-end and back-end components. And finally, power users use those tools to create shareable cards — which is like sharing content, embed code, or social media posts.
Dimension-wise, this pyramid is actually pointing in two directions.
On the one hand, the bigger the number of users (power users are a million-plus people), the bigger the number of potential contributors. As more people learn to create cards using the Cardstack tool sets, more and more cards can be shared and used as starting points for other people’s journeys. Power users can simply take someone else’s template, modify it, and turn it into something totally new. We want to enable a lot of power users to contribute in that tier.
On the other hand, we also understand that, the deeper you go in this inverse pyramid, the greater the technical leverage is. So, if you invest in a new type of SDK or API, then once you build that SDK or API, many product teams and engineers and Web developers can leverage that same capability. This could be an animation capability, a back-end or blockchain capability, or a visual type of re-use of a module.
Think about social media as a platform — whether it’s Facebook, Instagram, or even WeChat. The goal is to have very high technical leverage. Famously, when Facebook bought WhatsApp or Instagram, their product and framework teams had no more than 15 people; but with 15 people, they were able to create leverage for all kinds of creators (they call them influencers) to build amazing tools. And some of those tools are not just for power users. A good example is Snapchat. Initially, only the Snapchat team was able to build filters for the app. But now, they have a kit for Web developers or front-end engineers who know a little bit about augmented reality, so they can customize their own filters to offer to power users.
A big part of the tech industry is this type of gameplay. What kind of leverage, software, and service enables this amplification, so that one framework (like the Snapchat app) can create many experiences for power users (by offering a filter kit with many new filters built on top, for example)? After all, those experiences become content, and that creates the circulation of culture, zeitgeist, and memes that drives the attention economy.
Imagine that model moving beyond advertising-supported data. Software could be assembled with these kinds of layers and become more than just “we have an SDK, let’s have developers work on it” — which is one of the main problems in the decentralized / blockchain / crypto space. A lot of the skill sets necessary to build decentralized apps (dApps) concentrate on back-end or front-end engineers (very few people!), rather than tapping into the amplification offered by each layer of this pyramid.
This pyramid is logarithmic: There is no linear growth; instead, each level multiplies the number of contributors who add to the catalog by ten or possibly 100! In one of our early talks, our Lead Developer Ed Faulkner spoke about empowering the next million creators. These million creators could be Web developers. Our goal has always been to build tools with such high leverage (which also means very easy-to-use APIs, etc.) that Web developers, who are building WordPress and Shopify sites today, can leverage the Cardstack Framework to build new experiences. Those experiences, with the right layers underneath, could tap into this decentralized network that they didn’t even know they could be part of; and they don’t need to learn Web 3.0 or Ethereum to do that, they just have to build in the “card way.” The rest of the architecture built by front-end and back-end, product, as well as framework engineers allows them to sit on top of this amazing inverse pyramid.
Framework team: framework (6:27)
We have mapped the card stack (the software stack of Cardstack) into six layers. The bottom layer is the framework.
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.
Template cards allow developers to theme these common cards. WordPress, for example, has a very simple concept. There is an article or blog post that has certain fields; you may be able to extend some fields, but largely, they are all the same. Now, ThemeForest has a marketplace for Web developers (Note: there are a lot more Web developers in the world who know HTML and CSS than there are front-end engineers who know high-level framework programming languages like JavaScript). These Web developers take WordPress with its themes, the basic shell, and create a vibrant ecosystem that offers ThemeForest and many other types of theme sites. A user can say, “I want something that’s good for a dentist,” and then there will be this amazing template for a dental practice. The same is true for events, universities, stores, repair shops; there are all kinds of different themes for short-form and long-form content.
It’s similar to the way articles work: WordPress has a standard concept of a post, which can be used to create themed blogs that have the same underlying structure, but that can be projected, combined, extended, and given an individual look. That’s what we want to offer Web developers. Yet, when building a theme, they don’t have to deal with the back-end; the common card encapsulates all the data integration and blockchainy stuff. All the Web developer has to do is take the common card and say, “I’ll start with this, remap the fields, and add some fields and texture,” to create a nice template.
End users look at WordPress without a theme and say, ”What do I do with this? How do I turn this plain-looking blog into what I want?” But when they see a theme catalog like ThemeForest, they say, “I get it. I know I can double-click on this one, get it onto my host (the domain registrar who hosts my WordPress blog), and get a website going.” But here’s the thing: WordPress is limited to the types it provides. Sometimes, people have plugins that add some capability. But cards are mini-applications that are composable. So, instead of just having a standard event, you can create something called a ticket, combining an event with a payment. The event is the primary thing (the data aspect), and the payment is the part that asks someone to pay in order to attend the event — ”If you don’t pay, you don’t have a ticket; if you do pay, you do have a ticket.”
With a little bit of orchestration (what we call composites), Web developers — without knowing anything underneath — can create new mini-applications / cards they can distribute. But they can go even further and create something that allows users to assemble everything themselves.
Conveniently, a card can contain a card. Imagine a survey card that someone uses to apply to give a talk at a conference — this would be a CFP (call for paper) for a particular event. The card asks the person to provide personal details and attach a paper; and the applicant can simply drag an article into the card, the same way you can drag a PDF into a field. Once it is uploaded, the article is part of this call-for-paper proposal. And that type of assembly doesn’t even require the person to be a developer. Because of the way cards work, they are nestable; the survey and the CFP contain the structure.
The Git data source shows that these things are correlated. When the application is submitted, we bundle everything together like a PDF, so that the submission has everything in it (the event’s latest information, the filled-out survey, and the full text of the article). Now, if a new reviewer opens it up and the survey or the event has changed, they can go to EventBrite or Google Calendar and get the latest information. In order to connect to the latest version (the Google doc), an integration card of a credential is necessary. However, because it’s in the default data source, we do keep a copy in Git, so it is always possible to look at the old version. It’s like the Excel doc you sent yesterday, which you can still find in your sent emails.
All of this infrastructure is compositional. By the time we get to the Web developer, the only skill set needed is HTML, CSS, and maybe a little bit of Ember, to create some logic around a card — so it shows this particular event, icon, or payment status. But once this template is created, there’s a template gallery; and this could be a standard gallery, where the creator is just helping the community by open-sourcing his stuff, or it could ask for USD 7 per download, for customers who want to use that person’s super amazing tickets scheme.
Power users: example cards (26:37)
Power users can now start using these templates to make example cards.
A lot of the themes you can buy are still very raw. You have three options of how the header shows up; you look at it, you click back and forth until you find the right one, and you spend six hours clicking and adding new sample content, until you say, “aha, I got this thing.” But that thing is only on your Web host; it doesn’t exist anywhere else. So, the idea of examples you create just becomes something you take a screenshot of and share on Twitter, saying, “this is my great website.” You can’t sell or distribute or really share that configuration. With Cardstack, those configurations, examples, placeholders, and snapshots are locked inside your instance. And because of the composability of cards, the configuration itself is also in the default data source — it’s in a slightly different place, but the code (the template) is there, and the instance (the actual data and the configuration) is in Git too. You can bundle that together and say, “I made this sample meet-up invitation. The next person can just start with this.” It is almost like duplicating a Word file or a folder or a Photoshop file, and using it as a starting point. Then, someone else can start with that, put in a new date (the placeholder is in there well), and it gets cascaded to all the places where the date is shown.
So, power users create shareable, publishable, derivable cards by simply using the interface. They are not coding in HTML. They’re just using an environment; they’re using the ability to open the card in a library and edit it. The Four Edges allow them to click on a card, configure it, and look at different options. They don’t need to do anything beyond Web-based administration. That’s the only tool they need to create research report templates, newsletters, conference programs, tickets, and invitations, to name a few examples. Power users are just using the templates that Web developers put out there to create their own version of a reality.
Conclusion: the Card Catalog (28:59)
Cardstack invites people with all kinds of different skill sets, saying, “Your skill set is more than enough. You don’t need to learn NodeJS or Ethereum to contribute to our ecosystem. You don’t need to learn a very strange Web standard to be able to create your own meaning, write your own content, and share it.”
All the cards that are represented in the inverse pyramid are essentially code, which is published in the Card Catalog:
- example cards made by power users, using nothing but drag-and-drop / point-and-click tools
- template cards from Web developers, who theme the cards to make them more attractive (this is comparable to what people circulate within theme marketplaces)
- common cards, which are made by front-end engineers who know how to check things into GitHub and how to publish modules to module registries like NPM
- integration cards made by back-end engineers (all these cards have adapters, such as back-end integration)
The Card Catalog contains all four layers of cards from these different contributors. But many more people can get inspired to provide examples. Without ever looking at an integration card, you can just say, “I like this meet-up invitation.” To do this meet-up integration, you get an EventBrite or EventChain account (you just bring in those dependencies, double-click, and set up the account). And now, you have an event system that can bill and enforce a number of tickets — and maybe, in the future, even trading. Because that’s one of the things we can do with blockchains. “I have a ticket, let me sell it to you, let me treat this as an ERC-721 token.” That’s all part of that package. And that inspiration comes from the power users. The ability to imagine what a meet-up invitation could look like is inspired by a template and ticket that speaks their language.
This lifts us away from the framework and the SDK and the low-level APIs that dominate discussion — not only in crypto, but also in open source. People would like to contribute to open source. But at the framework level, there are very low-level libraries, where it’s not clear how you can contribute if you’re not a front-end or back-end engineer.
At Cardstack, this hierarchy (this inverse model) allows all kinds of people to contribute what they know, thereby making the system richer and richer. The Card Catalog is growing in all dimensions cumulatively: Imagine 1,000 integration cards for every logo, from Google all the way to Airtable; common cards growing as much vocabulary as exists in schema.org and beyond; as many templates as there are themes you can buy; example cards as rich as the Web and the array of things you can search.
Say you want to find a conference program template on Google. A template shows up; you click on it, you like the look, and you add it to your card space / library. Suddenly, within 15 minutes, you are publishing a complete conference booklet that has payments, registration, CFP, paper acceptance, a review process, a voting process, etc. (some on-chain, some off-chain). As long as you have a wallet that pays for the fees, you’ve got a system. You don’t have to think about what it is: “Is that Shopify, is that WordPress, is that Google Docs or Google Spreadsheets or EventBrite or Salesforce.com?” This is the future of Web 3.0 — the Web will be the place where you can take other people’s deliverables as your starting point, your template, your example to create your own journey.
The Card Catalog’s role in the network (32:51)
The Card Catalog fits very nicely into the Cardstack Ecosystem. Developers create cards, which they add to the catalog. End users use that catalog (with these examples, templates, integrations, and core cards) to create their own spaces and workflows. Note: The catalog itself is not the website. We want there to be many websites — as many domains as there exist today, and we want people to build spaces using those domains. This is similar to how they use WordPress and their own domain names to create their spaces on the Web today. At Cardstack, this is all connected. Users can take everything in the catalog to populate their own space and adjust it to their liking. It all starts with this catalog: The key for growth — the ability for us to make a dent in what we call the Web, the tech industry, or the tech landscape — lies in this network of tools. And that is the real power of the Cardstack Ecosystem.
But none of this can be done without the community coming together to help make it happen. We are doing high-leverage stuff. We are working on the framework, the beginning of the product; and there are many people who can come in (back-end and front-end engineers as well as Web developers) — who will find the documentation, the examples, and the guidelines to learn how they can contribute.
4-sided market: developers, users, businesses, providers (34:19)
What we want to accomplish is a four-sided market, where developers use our SDK to create, deploy, and sell cards, which end users then use and share.
Based on the same catalog, businesses build white-label solutions and software for their own networks to coordinate their workflows.
Providers are the people who offer hosting services / blockchain services, using our stack — providing the “do-it-for-me convenience” you expect from the Web and the cloud. Right now, in blockchain, the self-responsibility makes it hard for people to understand how to manage keys, storage, etc. So, we need service providers who offer services on top of Cardstack, on top of the Cardstack Hub, on top of the Card SDK.
This way, you can get great service. But if a service provider starts locking you in or changing the terms, you can take all your examples, templates, instances — your Git repository, your one folder of truth — and just move it to another place. You can take this out! It’s not just like Google Takeout, where you use Google services to download the zip file that contains every photo and every comment you have ever made on Google+. (What can you do with that? It’s just a zip file.) At Cardstack, this zip file / this Git repository can be bootstrapped completely from scratch with a new provider. And this competition keeps providers honest.
Of course, we do hope that you keep the providers you like, enabling them to get sustainable margins — as you keep subscribing, as you keep that cash flow and that kind of value coming, so the contribution keeps growing the network. Then, this ecosystem allows us to share the rewards across all four parties.
Cardstack’s vision is to provide decentralized software-as-a-service. dSaaS is somewhat similar to dApps, which are very self-determined, as there are plugins and you run your own software. dSaaS takes this one-level folder and says: “Can we take what makes the Web such a convenient place, and do it in a way that is a little better than what we have now — in terms of the economics and the ability for us to share a destiny, our knowledge, and our know-how?”
So far, the technical perspective of the framework has been our focus, and we will start to move up the product chain to complete our vision. It is about going up the inverse pyramid, vastly expanding the number of people who know about Cardstack and learn about the tools we give them — who feel comfortable with the fact that they can make an impact, that they have the power to help create the next generation of Web 3.0 technology. Hopefully, Cardstack’s tools provide that catalyst to make it happen.
Learn More
- So What’s the Cardstack Product? Introducing the Card SDK, the CARD Protocol, and the Cardstack Hub
- Building the Card Catalog: Status update & strategy for the Card SDK
- Card Schema Explained: Lightly edited transcript of Chris Tse’s tech talk
- Cardstack.com
Star Cardstack on GitHub and join our Discord channel or our Telegram group and announcement channel to get all our latest updates.
