Jan 9, 2020

17 min read

2020: The Year of Launches

A deep look into the new roadmap for the Cardstack Project

The ultimate goal of any software-driven network is to be useful to its participants, enabling transactions that aren’t possible without the software acting as a facilitator. Usage is the one value that drives all other metrics. For companies, usage translates into revenue, network value, and market perception. Yet, we steer the decentralized tech ecosystem away from a competitive approach, where all tech companies compete against each other for eyeballs, dollars, developer mindshare, and screen time. At Cardstack, we believe that the next 10 years, starting this decade, will be about cooperation between network participants, including service providers and early adopters.

In our ecosystem, we see three audiences or groups of participants we need to bring together:

Users, who drive usage, which makes them the source of economic value in the ecosystem
Developers, who create new tools and broaden the capability of the ecosystem
Protocol community, which manages the incentive and governance model, ensuring that all participants are working well together

In 2019, we started focussing on use cases for our software, building open-source applications around decentralized finance, content syndication, as well as decentralized software and media registries. Having our core team work on specific use cases successively allowed us to exercise the underlying software development kit (Card SDK) and our server-side runtime. Through this process, we learned what exactly the software is capable of and how the developer ergonomics affect the developers’ productivity; we also discovered the gaps in the architecture that were preventing Cardstack from achieving its full potential.

We spent the first part of last year building and releasing a series of open-source applications on top of the Cardstack network:

As we approached the middle of the year, our framework team took a look at the commonalities of these separate applications and saw the opportunity to unify many of their features into one common runtime. This decision led to our work on Card Schema V2, which encapsulates cards in a way that allows users to mix and match cards from different suites — whether the focus is finance, content, data management, or workflow — and run them on the same server, in the same framework, with the same hosting provider. All our applications now share the same foundation.

Card.Space: Reimagining our hosting service

We planned to release a hosted version of Cardstack called Card.Space that was meant to serve as a hosting platform for decentralized apps. The aim was to empower users who do not have the technical capabilities to run their own decentralized node and server runtime (either on the computer or in the cloud), offering them a one-click hosting service that is reliable, cost-effective, and easy to use. Now, we have found a way to make Card.Space even more powerful, by adding a level of flexibility that allows this platform to combine cards on a field level.

Additionally, we want to make sure that the platform can be properly maintained for its users once the apps are launched. Therefore, the architecture for long-term data storage and our encoding approach has to be based on Card Schema V2. With our understanding that Card Schema V2 provides a way for us to unify all use cases into a catalog of reusable cards, which we call card templates (e.g. form, collection, layout, thread, action), it made sense for us to make Card.Space the generic hosting service for all cards built using the V2 approach. The initial set of templates for cards will be the foundation for a lot more vertical-industry as well as horizontally applicable use cases.

We have been working on extracting the common infrastructure for building and running a Cardstack app into its own project, called Card Infra (standing for card infrastructure), which allows Cardstack applications to be easily deployed to public cloud services like Amazon Web Services (AWS). As of the time of writing, Card.Space is running on AWS, with its codebase coded in Card Schema V2.

We plan to invite early adopters to try out the upgraded Card.Space service in the next few months, so as to gather feedback and initiate enhancements. This Card.Space hosting service will work like any other platform: Once you have an account, you can create your own space — for yourself, for your team, for your private or public group, or (if you are part of a larger organization) for a hierarchy of interrelated subteams. You can run any Cardstack application written in Card Schema V2, just by opening a template in the browser, and immediately start interacting with it.

Card SDK & Cardstack Builder: Developers and users as card makers

As a way to increase the number of cards that are available for people to adopt and use in their personal workspaces, we want to facilitate both code-driven and “no-code” approaches to card making. In our ecosystem, we see card makers as anybody who makes new cards by translating their experience and expertise into new mini-apps. This includes developers who code as well as users who don’t code, but who know how to work with Excel, how to configure a Web platform like Airtable or Notion, or how to administer Salesforce.com. Therefore, we create two different entry points for card makers, which are designed for developers and users respectively.

Card SDK for developers

Cardstack is designed to be open source. Therefore, we continue improving and updating the Card SDK, so as to provide developers with clear documentation and useful tutorials, which will guide them as they create brand-new functionalities within the Cardstack ecosystem. Last year, we launched Card SDK V1 with the corresponding documentation, which teaches developers to build applications that are similar to our open-source codebase and which tap into the full power of the Cardstack Hub — with its indexing, transactional writing, access control, API generation, and user interface support, including templating and routing. All this is part of the Cardstack architecture.

Since then, we have been working on upgrading the Card SDK and the documentation to support the V2 model that is currently in development. Card SDK V2 improves the encapsulation of code, making it easier for developers to reuse modules they have created in other cards. For example: If you have built a payment processing card that supports credit card or crypto payment methods, you can insert that payment processing card into any new type of card you are building, such as a card for selling tickets, collectables, or services. By setting your payment processing card as a field type, your other cards can use the exact same payment UI, API calls, and wallet integrations.

Cardstack Builder for users

The greater level of composeability offered by Card SDK V2 allows us to make it even easier for non-developers to assemble their own applications. Instead of having to write code to embed a payment processing card inside a concert ticket card, users can use the UI to simply drag a payment processing card into their ticket card.

Since 99.9% of humanity does not code, providing drag-and-drop tools for card assembly and point-and-click tools for configuration greatly increases the number of card makers who can actively contribute to the richness of the Cardstack ecosystem. Therefore, the current focus of our research and development revolves around creating the Cardstack Builder. This card building tool is an integral part of the Card.Space service, enabling non-developers to leverage the composeability of Card Schema V2 to create new data-driven systems, forms to capture user input, and workflows that set visibility criteria based on organizational rules and access control patterns.

We will announce an early-access program for community members who would like to test the Cardstack Builder in the coming weeks; keep an eye on our Discord or Telegram announcement channel to be one of the first to get the news.

Card Catalog: Templates over tools

As software gets more powerful — both on the desktop and on the Web — there is a growing array of tools that enable users to design and prototype websites, create applications and workflows, and customize networks or online groups. However, most of these tools require countless integrations, which have to be created through custom programming or tools like IFTTT / Zapier. This means: While many of these tools are considered “low-code” or “no-code” tools, users who can actually wield those independent tools successfully to create a cohesive experience need to be highly skilled, as the process involves a lot of trial and error. Although this process does not technically involve any coding, it is very much like a difficult engineering process that is time-consuming, error-prone, and extremely frustrating.

Our marketplace research has shown that, even with the powerful tools that are available for no-code platforms like Airtable, most users of these platforms end up using templates — either templates published by the platform itself (in the form of starter kits for common workflows) or templates that are provided by other platform users, who share their customizations (which are based on hard-learned lessons) with the broader community. Users who adopt these prebuilt templates basically experience applications in their completed state; they only make little tweaks in areas that are inadequate or incomplete. That is why they can get a SaaS application up and running in as little as 15 minutes, without spending hours tinkering with settings and configuration menus or watching endless Youtube videos to figure out which button to click or where a menu item resides within an app.

We are following a similar approach. In our ecosystem, we encourage all card makers — regardless of whether they write code or use the drag-and-drop UI of the Cardstack Builder — to share their card templates with the greater community. The system we have designed to accommodate these sharing workflows is the Card Catalog. In a nutshell: The Card Catalog is essentially a global, shared folder, to which people can submit the cards they have made. To make it easier for users to find particular cards in the catalog, we will ask submitters to include categories, screenshots, example data, and user tutorials along with their core configurations.

The underlying technology for the Card Catalog is Githereum, which is a git-based file system structure for managing these submissions through the Ethereum blockchain. An Ethereum smart contract governs the submissions to the catalog, including rules like

who can submit new content,
who can approve content, and
who can revoke the privilege of being listed on the catalog in case of security concerns or incidents.

The Card Catalog will be integrated deeply into the Card.Space system. With one click, you will be able to see the directory of all the cards you have already submitted; and with a few more clicks, you can submit new cards to be published in the catalog.

As we looked at other open-source ecosystems, like WordPress, we also realized that the market for premium themes is massive. These are special templates designed for WordPress, which have prebuilt capabilities for certain vertical-market use cases — e.g. real estate, personal portfolios, or podcasts. The Card Catalog will support such premium templates as well, which will be priced either per download or as part of a monthly subscription. We are currently designing the economic infrastructure, which will allow people to use their prepaid balance or the rewards they have earned to redeem those premium templates.

Boxel Design System: Experience over capabilities

At Cardstack, we aim to give users a cohesive experience across all the capabilities we offer:

creating new cards using the Cardstack Builder
searching and collecting card templates in the Card Catalog
adding cards to the personal Card.Space
combining cards to create high-level workflows

The process of combining these actions should be fluid. You shouldn’t feel like you are configuring a complex piece of enterprise software, but more like you are customizing your trophy room in an online game. We believe that the most sensible way of building digital spaces is to borrow a page from the game world’s book. We want the experience to be similar to assembling in-game objects in a spatial-physical area, where all actions — dragging and dropping, zooming in and out of the viewport, as well as selecting and configuring objects — are done consistently across all types of objects in the environment.

We are looking at game environments like Minecraft, which pioneered the use of the volume element (voxel), allowing users to combine blocks of Minecraft objects to create a 3D structure of their choice. Some of these structures have magical properties, while other blocks, like red stones, are actually objects that represent an electric circuit. Many Minecraft creators have built complex machineries that are impressive to look at and play with in the game; but any engineer will tell you that they are actually complex software programs.

At Cardstack, we have spent a lot of time studying worlds that are created by users assembling such building blocks; we have wondered whether we can apply similar principles, like voxel in Minecraft, to the composition of Web 3.0 experiences, so as to provide the same joy of experimentation, immediate feedback, and gratification. This is the reason why we have developed a whole theory around composeable Web 3.0 experiences, based on the principle of box elements, which we call boxel.

This architecture now underpins all our work, including the Cardstack Builder. We are currently creating the UI component library, ensuring that all the form elements in our new card building tool are based on this boxel concept.

Furthermore, we are building a motion engine, known in the game world as physics engine, to make sure that the movement of box elements is consistent and realistic in the user environment. We are designing the motion engine in a way that requires minimal programming from developers. Once they have created a card that satisfies all the user interaction requirements, their card automatically inherits the capability of becoming a boxel, including all the animation rules that are automatically injected without any animation programming.

The UI components and boxel engines are under active development and will be part of the Cardstack Builder when we launch our card building tool. They will be extended to the Card SDK as well, enabling developers to tap into these capabilities without having to dive into the privileged codebase of the Cardstack framework.

We expect to turn our boxel concept into a complete design system that supports full theming. Brands and companies will be able to create their own themes, which will apply to all boxel components of all cards that are being used in their environment. While this is not a short-term goal, it is an important part of our long-term white-label plan — especially once new business networks are built on top of Cardstack and the customization of their look and feel becomes an important differentiator.

Multi-Hub Interaction: Cooperation over conversation

There has been a lot of growth around platforms that facilitate conversations via chat groups, social media posts, comments, and forum messages. These conversations drive engagement and screen time, but don’t return a lot of transactions in terms of dollar values. On the other hand, transactional systems — e.g. for e-commerce payments, crypto, or B2B workflows — typically have very little support for collaboration. They let you interact with a form that represents a machine, hoping that you’ll click the right button to make it work.

Cardstack will support a new type of workflow that combines both transactions and communication: It’s called cooperation. In this workflow, business transaction data can be carried through a card that represents a purchase order, a payment request, or a digital asset. This card can travel from one user’s or organization’s space to another user’s or organization’s space. The Cardstack Hub or platform runtime is built on what we call card data services, which are currently in development. These will make it possible for cards to be imported into a hub; and once a card has been imported or received, it is fully functional within the hub, including the UI, APIs, security control, and data query capabilities.

We are in the process of designing a query service we call multi-hub interaction, which enables cards to move between spaces seamlessly. These spaces are formally called realms, with each realm representing a certain type of security and access control. You can look at it this way: Think of your private folder on your computer as the first realm, your shared Dropbox folder for your team as a second realm, and a public folder where you can drop files others can download for free as a third realm. Unlike Dropbox folders, though, realms are not limited to files in PDF or certain image formats. They can contain any card that is built using the Card Schema V2 format; this includes anything that can be represented by one of our base templates — e.g. forms, collections, actions, threads, and layouts — or a more specific version of these templates, such as a job application form instead of a generic form. These multi-hub interactions are based on the capabilities of the git protocol, which allows for version control and tracking, as cards move between realms.

Allowing multiple hubs that are run by different organizations to cooperate as one extended network will lead to promising new economic models. Ultimately, this will facilitate not only decentralized SaaS, where application logic and data is shared intentionally, but also decentralized business networks, where new business relationships can be formed and new transactions can be conducted purely on top of this multi-hub interaction protocol.

Moreover, we expect to extend this protocol to support the necessary cryptography for key signing and key generation as well as automation in connection with existing enterprise systems. At the moment, we are working on examples of decentralized business networks in collaboration with our partners. Once these projects are finalized, we will provide details on how these enterprise systems are constructed and how we can automate interactions with existing business systems, using the plugin framework provided by the Cardstack Hub.

CARD Protocol: Revenue drives rewards

At the end of the day, the only thing that drives truly sustainable value in any economy — whether it is the economy of a nation / state, the economy of a digital marketplace (like an online marketplace), or the economy of a crypto network — is top-line revenue: Customers must be willing to pay cash or a cash equivalent for products or services. That is why we need to provide useful services, for which we can charge real customers real money, thus ensuring that these services become the well leading to increasing downstream rewards for all contributors.

To that end, we focus on building use cases for real users, such as easy-to-use hosting and off-the-shelf templates, organized in a global catalog. Fortunately, one of the fastest-growing sectors in the economy is software as a service (SaaS). As more and more activities go online, individuals and businesses need a lot of software-based tools to manage their lives, grow their businesses, and run their organizations. We see Cardstack as the world’s first cooperative SaaS platform, where a network of designers, developers, and service providers can work together to provide valuable software services to users, which will end up substituting the existing SaaS services those users subscribed to in the past.

An essential part of our strategy is our billing and reward system, Tally, which was launched to testnet mid-2019. We will continue to work on extending Tally to support the new Card.Space hosting service. In order to drive revenue, this system will allow users to pay for their usage of services on the Cardstack network in the currency of their choice. To achieve this, we will integrate Tally with payment gateways to process credit card payments. For users who are already familiar with the crypto ecosystem, we plan to integrate with a few of the top decentralized exchanges (DEX), such as Uniswap and Kyber, enabling these users to pay for services in their preferred token. Once these integrations are done, we expect to push Tally to mainnet and fully integrate the CARD Protocol with user-facing services.

We plan to create an ambassador program for users who would like to be part of the community, contributing their time to testing and providing feedback. For this program, we will distribute free-trial tokens as part of Batch D of the CARD token distribution plan. This group of users will be able to use the Card.Space services; and if they make meaningful contributions to the community, they will earn additional CARD tokens as a reward.

Governing the Card Catalog

The CARD Protocol will support staking as a means to govern the Card Catalog. This allows people who are knowledgeable about crypto economics and software quality to act as reviewers for new cards that are submitted. By using the CARD token as a governance token, we plan to delegate the ongoing management of the Card Catalog — decisions like which cards get listed in which categories under which conditions — to a community-governed process.

This process will be extended to allow for the development of a registry of service providers. That registry will be built on the Githereum registry system. It will allow providers who want to offer services in different geographic locations, as well as developers or designers who want to offer consulting services to customers on the network, to list and promote themselves in a way that makes sense to them. This registry will also be curated using the CARD token as the native accounting unit and the fee denomination for maintenance of the registry.

Our goal is to give people who are not familiar with tokens a seamless experience, without ever requiring them to know anything about crypto. With that in mind, we expect to seek out active partnerships and integrations with fiat on-ramp and off-ramp providers, so that the on-boarding and off-boarding of value to the network can be as intuitive as subscribing to a SaaS app or receiving a PayPal payment for selling something online. A lot of innovation is happening in the space at the moment, especially in the Ethereum ecosystem; we are keeping a keen eye on these developments and will integrate with a popular method when these solutions mature.

We hope that this article gives you a better understanding of our 2020 roadmap for the Cardstack Project. We continuously adjust our priorities and resourcing levels, based on the lessons we learn as we keep working on multiple levels of the stack simultaneously.

2020 is the year of launches. We are taking our open-source codebases — which we have released in our GitHub repository — improving them, packaging them, and making them available as off-the shelf software for the mass-market.

While our roadmap contains many elements of our decentralized architecture (especially the bottom half of the chart), what sets Cardstack apart from other crypto projects is our emphasis on the user experience. We aim to deliver this experience layer on top of the decentralized architecture. Our goal is to release software that doesn’t need a qualifier — one that presents the decentralized nature as a justification for the software being less user-friendly, more jargon-filled, or less capable. If Web 3.0 is to win in the marketplace, it has to beat the incumbents and the current products that are available on the market in every dimension — including price, selection, and customer support.

In order to better communicate Cardstack’s product orientation, we will be launching a new Cardstack.com website, which describes the elements of our roadmap in a much more user-accessible language, as we prepare for the launch of Card.Space and the Cardstack Builder. The community will get a sneak preview of the new Cardstack.com as well as further documentation very soon.

We look forward to your feedback on the upcoming launches we have planned for this exciting year!

Learn more

To get all our latest updates, sign up for our newsletter on cardstack.com, star Cardstack on GitHub, and join our Discord channel or our Telegram group and announcement channel.