Cardstack Project Update – November 2018

Hello everybody. I'm Chris Tse, the Founding Director of the
Cardstack Project. I want to spend some time today to give you
an update on what's going on in the Cardstack ecosystem, especially around the design and
development activity that we have been undertaking as well as a commentary on the general state
of the market and how we believe that the idea of the decentralization movement and
the idea of building a much more healthy technology for the rest of us is going. For us, the decentralized internet really
is an abstract concept. We really think that we're building the Web
3.0 system — the experience for that — and the question really about it is: how will
people experience Web 3.0? For those of us have actually played with
different aspects of blockchain, crypto and different type of decentralized technology,
it's quite important to share those instincts and those understandings, and we want people
to be able to, through Cardstack, experience what it means to learn this new way of interacting
with technology and each other.

For us, Cardstack’s main vision is to really
build that stack so that people can, through Cardstack, get to that kind of visceral understanding
and experience for themselves. The question really is what is Web 3.0? There are many definitions of it. One of which is the kind of Ethereum-Gavin
Wood version when they talk about web3.js which is that this is about crypto — Web3
is about the Internet of value: verifiable transactions, and transferable assets that
synchronize around the global ledger. The problem that I think people are realizing
is that after a while, that particular type of technology and saying that that's the only
definition — it's only narrowly applicable. Only a small subset of things are really just
about value. There's so much that goes on in the internet
that's not about that. And the decentralized apps that have been built on top of that
are relatively hard to use. I do believe they'll get easier but they typically
are very specific to just exposing the capability of this new kind of blockchain Internet of value.

For me, the Web 3.0 — really a healthy way
to look at it — it's really a combination of the Web we are today, Web 2.0, and some
of the principles and ideas of Web 1.0. Remember, in Web 1.0 people have their own
homepages, websites look completely different. In Web 2.0, because of the network effects
and the centralization around a couple websites, it becomes just a couple of big websites you
go to. What if we can combine that kind of quirky
innovativeness and uniqueness of Web 1.0 with the network effects and propagation and
ecosystem of 2.0? Because if we can do that, what we realize
is that this Web 3.0 — that's the combination of 1.0 plus the 2.0 — is much more inclusive
because 4.2 billion people are on the Web today.

They want to see what's going to come after
this — what's after these digital super powers dominating the landscape. What I love about the Web is that it's linkable
so that things can come together. My page and your page come together not just
within one giant website —, — but across a much more healthy, diverse

What we've learned about the Web is that it's
also very referenceable. It almost doesn't exist unless you can say
here's a link to something, even like: here's a link to a transaction on Etherscan, here’s
a link to a page or this is a proof that something has happened. People still rely on that URL, that referenceability, and that's a great quality to build upon. One of the problems of Web 1.0 obviously is
that it’s very static: the capability and technology around making webpages doesn't
really allow for interaction — it's mostly a publishing platform, but more interactive
social stuff is centralized.

What if we can bring those things, those ideas,
and really deliver a new experience? To do that we need another actual version
of Web 3.0, which is Web Dev 3.0. The tools that we used to develop the Web
have tremendously improved. It used to be “it's all about HTML” in
Web 1.0 — then LAMP stack, PHP, MySQL, WordPress, Drupal and all these kind of tools — but
now we have this new generation of JavaScript and APIs that allow us to do something a lot
more functional, focused and empowering. Very similar to what's going on in native
apps, but in a way that is much more empowering to people, so you can create on the Web just
as easily as you can create on a desktop app. The problem with that is that it's extremely
siloed — each person building for these things is building a website with certain
features and there's a lot of duplicated effort. ‘Forget password’, and all this kind of
stuff — everybody has to do it every single time.

While everybody's very productive and building
amazing new apps, everybody is repeating the same tasks over and over again. Is it possible for us to say, "Hey, let's
share the modules between ourselves"? That hasn't really happened yet — there's
open-source sharing of libraries and toolkits and frameworks, but not really sharing features
among different developers who are building the apps. That, I believe is the substrate
of what can really unlock the value of the Web 3.0 by providing those features and community
around the developer building for and designing for Web Dev 3.0. One thing that we want to talk about is that
in some circles Web 3.0 really means the spatial Web — Web 3D, AR or augmented reality, virtual
reality — these are all things that people talk about. Taking what we’ve learned from games — having
tangible objects, handling things and upgrading and interacting in a massively multiplayer
way — these are all things that I think are extremely interesting.

Because that's the type of infrastructure
that people have already really fallen in love with. There's something that feels much more physical
and real when you're playing a game than when you’re browsing a website and being passive
in your interaction. The problem with Web 3D, obviously, is that
it's just a game. This is not real. Every game that we create has its own virtual
open world, but the next version comes and you start from scratch.
And finally when we talk about 3D on the web is really a little bit strange
— sometimes the third dimension really gets in the way. So our conception is really about 2.5D: bringing
together different aspects of of the Web in a way that allows us to be completely connected
and hyperlink between the objects. What does this mean? That means that there are four things that
we are really trying to bring together, four definitions of Web 3.0: Web3 from crypto;
the new idea of connecting to the people who are on the Web, meeting people where they
are; this new capability of development tools as bringing together; and the potential of
tapping into the some of the ideas from gaming.

This idea of bringing these qualities — verifiability,
transferability, synchronizability, linkability, inclusiveness, referenceability, functional
focus empowering applications with spatial tangible interactives — these are the elements
I believe would really become the root of what would really encompass and be embraced
by people who would say, "Oh this feels materially different than the Facebook that I check every
day." The question then becomes: what is this unit
of interaction within Web 3.0? For us, Web 3.0 is really about connections
between different objects, like in a game that is each a webpage, and then some of
them represent assets or payments that's tangible. And when you want to edit it, when you want
to manipulate it, you can treat each one these objects as its own mini-focus app and be able
to tap into it and make it focus. That's essentially the Cardstack vision: we
want to be the stack for Web 3.0 to support the creation of these objects (which we happen
to call cards), and letting them link together and letting people manipulate them the same
way they would manipulate and create their world in a game, or create a website with
these tools.

But in a way that feels a lot more connected
to the way the world is today. Web 3.0 can best be thought of as a bunch
of cards representing content data — sometimes memberships and agreements — and they can
come together to orchestrate in workflows, and get automated, and lead to payments, and
selling of products, and obviously messaging and other types of duplications of what currently
happens in Web 2.0. These cards are essentially mini web applications. Each application itself contains what looks
like— The work that you would do to create an app.

It has templates for layout and styling so
it looks like a Web thing using the latest Web platform to render it beautifully with
animation, and it also has JavaScript or AppLogic, so it has fields and constraints and permissions. Then underneath it, it maps to a data model. This is a database that allows you to say,
"When I create this agreement, it will get saved somewhere. When I send it to you, you'll be able to retrieve
that and look at it, edit it, and send it back to me.” So there is a kind of underlying truth that's
being shared. Now, whether that JSON API or this object
is persistent on blockchain or a cloud service on your computer — doesn't really matter. We think that the apps don’t really care
where it goes to with the data, as long as this app feels like, "Hey, this card that
represents this piece of content or this article exists." One of the things we work really hard on is
that cards that stay independent of each other, it's cool, but then you get different apps
and silos and stuff like that.

It'll be great if these apps can embed each
other — they can take each other's capability and bring it together. So relationship delegation and metadata access
allowing an article to include a place, include an event, include a map, include another thing
that is maybe a value statement or an agreement that includes a picture or a signature. This idea of embedding is really key, and
it’s something we’ve worked a lot on in Cardstack. Cards are great, but if they can be composed
together and you build greater and greater applications that become less and less mini,
even though they can still move around in these kind of affordances, like giving someone
a card and receiving something, but that thing could just be a docket, like an agreement;
a deal that includes the other things that mix it up.

When we talk about what this ecosystem of
cards looks like, we're really talking about multiple cards sourced from different data
sources. Let's say we have five cards here: a user
card can come from a OAuth identity source — this is my identity from this system,
an enterprise system or a consumer system. I have a document that could be version controlled. That could be open-sourced on places like
GitHub, or be stored in a content management system. I have a news feed that takes that together
and shows me all the documents that people have uploaded. I have a video which may have some binary
that requires it to go to a file storage. Now, this could come from a cloud-based file
storage like S3 which is run by Amazon, or it could come from something in the future. Then if you have a wallet card, which is another
kind of mini application, that can tap into the Ethereum protocol. These things exist as a way to completely
give you the facade that “these things are mine and I can move them around.” If you want to say all of these things are
actually connecting to this data source, you're in luck because we've actually built all of
these things already.

The key is to say when you have the ability
to have these cards built back into the decentralized world, the question is can we turn it into
a decentralized world? Here's what happens: when you want to decentralize
these cards, all you do is swap out the data source. So we built something called Cardstack Hub
that allows you to abstract what these cards require in terms of data to populate it so
it looks like a real thing. Instead of going to an enterprise system,
it can go use a decentralized identity.

Instead of using GitHub which is a centralized
service hosted and owned now by Microsoft, you can use Git, which is a very decentralized
protocol, and blockchain to version control between people without uploading to a central
server. Instead of using your own database, you can
use GraphQL to go around and look for things to put together this newsfeed. Instead of using a cloud storage to store
the video, you may be able to use IPFS or Swarm. Obviously, for wallets, you might want to
tap into new type of public ledgers coming in, like EOS and Tezos.

There's a question from the community, "Do
we have a plan to support EOS?" The idea is yes. We have a plug-in system, EOS and EOS apps
are just essentially plugging into that particular system. With this particular set of abstraction, once
you build these user cards and newsfeed cards, you're done. The front-end, the user experience is complete. We can just delegate to engineers who go work
in the backend and say, "Hey, let's make this healthy, let's connect it to decentralization
protocols”, and then the experience become wider reaching but without saying, "Hey, you're
going to have to uninstall and reinstall everything." It's just the same Cardstack experience but
now tapping into a new type of protocols.

How does this actually become the type of
application that we want? Essentially, cards becomes what we call Decks. Decks are basically a collection of cards
that make up a particular application. If you're making an official site like a website
or a web portal, then you may have something more typical of a document, a promo, search
results, and homepage, podcasts, and team. These are more content and more interaction
in community engagement type of a card. If you're building your own personal kind
of private space for you to keep track of your possession and your relationships in
the world, you may have a card that represents you, your wallets (whether that's a hardware
wallet or even a remote hosted wallet), your membership where you belong on lightbox, what
you're working on right now — this would be a personal deck that will be only viewable
by you.

In building collaborative applications, you
might add things that are more social: message and threads and checklists and requests and
approval and figuring out who's a member and who's a participant. The idea of a Deck is to find a way to have
a collection of cards so that through these compositional costs, you actually see a fully
working application that looks no different at first glance as a really advanced website
that people spend a lot of time on. What's different about it is it's compositional
— you don't have to code each thing and get a developer to code each nesting. The card runtime automatically decides, "Oh,
you put this inside that, let me just render it all together.” As a way to dogfood this, we built
a Deck: the first Deck called cardstack/deck.

Now this is a private GitHub repository we've
been working on for about two months now, and we will open-source a version of that
very soon. What we did was we built 27 different type
of cards representing what would be the official website for the Cardstack community, and in
each one of those 27 cards we have templates and JavaScript JSON API. They have completely separate applications
that happen to be kind of combined in this mono repo (a mono repository is just a place
where everything’s stored). When you interact with it, we actually create
another repository for data persistence in GitHub where the corresponding data are stored;
everything you created is actually checked in through revision control. It works, and it's amazing to see that ability
for this rendering system really come to life in a relatively simple content use case — but
the rendering pipeline is really what we're trying to do. When we're looking at these Decks that come
together, we're really grouping these Decks into two types of delivery. Once you have the Decks, a card can be at rest,
it's like gathering at a website and a portal, or can be in motion — I'm sending you something,
submitting something for your approval.

For us, when a user interacts with Cardstack
it always becomes like, are you dealing with it and searching and querying for it in the at-rest Space? Or you're trying to take a card, lift it and
conduct a workflow, Card Flow? Let's be a little bit more concrete. The first use case we're working on is a community
contribution system. In this case Card Space and Card Flow work
together in conjunction.

A Card Space would be: I'm creating a new
document for my awesome idea. When I submit it, I create a Card Flow — which
is a new type of ephemeral space that's created, again another container that allows these
card to exist — then I send a message saying “please review.” The other person gets invited and they say,
"I'm a reviewer and I approved it." Now this card gets merged into an official
site and can get published. The user doesn't see all the things that are
going on, whether it's the Git stuff — the revision control, the indexing, the publishing
— all they see is I have a card I submitted to someone, and they've accepted it so it
shows up somewhere. That's an illusion that we want to be able
to give people. This first version of it is actually done
entirely using Git: we have a Git-based workflow, so that all the changes — the new content
that’s actually done in a content addressable way — and then we create this commit, which
is your new changes.

We submit it and we merge it using GitHub
as the first service provider, so you're actually making an open-source contribution when you
bring it in that way. This is an example of what this looks like:
this is actually live code that I pulled from our servers, which is a complete rendering
and query pipeline where the cards are brought together to create a website. It has 27 different mini apps cards that are
being built here, so you can browse all of that, create new cards, generate the pull
request (which is submitting revisions). We have this data model which defines different
content types, and then we give you a standard editing interface for it. We inspect your model and give you a field
summary (in this case editing the title), and then this idea of add-ons that in the
future, if you have advanced property types, you should be able to come here and add that
into this particular experience.

This is something that is totally running. We'll give some public demos very soon so
you can see how you can actually construct an entire community site not just controlled
by one or two parties, but anybody can essentially contribute now. Obviously, editorial rules apply, but the
basic mechanism of the construction of this catalog of content, data and settings is curated
through this Git-based workflow. This is a little sneak preview of an upgrade
on the way this looks. We have been working on a design system called
4 Edges Design System, which brings the capabilities of all these administrative tools and all
these helpful tools — configuration, sharing, searching your library, switching, getting
notified and seeing cards in its different form — all those things card developers
don't have to do.

As long as they construct the card in a template,
we give you all these powerful tools. The same way that once you create a screenshot
Instagram will give you all the filters for free, you don't have to do much. This idea of 4 Edges is that each of the edges
provide different capability, but they're all shared across all card-based applications,
so that once you learn how to use the properties panel, for example, for for one type of card,
it's the same whether you're configuring a piece of content, a data source or configuring
your wallet — it's using the same capability.

One of the biggest ideas of the 4 Edges system
is that as you interact with different card-based systems, you're collecting this library that
of all the things you've seen. Almost like you download it directly on your
computer into your document directory, so that anytime in the future when you want to
be like, "Oh, I already did something, I have user a profile or I've already done KYC, can
I reuse this information, this card in this particular workflow?" You can bring that from your library and apply
or drag it or pick it from this collection. This idea is pretty radical — that your
cards, because they're so mobile and modular, and so tangible, allow you to collect things
that may come from different networks, interact with different people both at rest and in
the workflow and you just accumulate these assets that you can reuse in the future and
it's all yours.

Now, obviously you can use the library search
within the particular site as well, and that's really the type of duality that we support. When we talk about use cases, we're not just
trying to create a content system. Another system that is actually really similar
with this Card Space and Card Flow, card at rest, card in motion idea is to build an immediate
registry. A blockchain media registry just means that
I want to create like an official registry of all the ownership information about every
piece of recorded music in the world. We've been working on this project for about
two years now as a way to drive the use case of what the platform would be, but also to
get the use case of this blockchain music registry to drive our understanding of the
real application and enterprise workflows that people want. Companies want to synchronize their data:
"Oh, I own some songs, you own some songs.

Let's figure out who actually is correct." You submit what you have and then you amend
them to kind of approach the truth. That is a very good approach for using not
only blockchain as way to synchronize all the amendments and all the edits, but using
Git as a way to track the changes so that this is not just “I say something, you said
something”, but our truths actually converge and merge into the real truth. If you look at this a little bit, it's actually
very similar to the community contribution system — you've got the the label and publisher
creating and forking and editing something, you want to add a name and then you submit
that as an addition, someone says, "Okay, I approve that's okay", then that ends up
updating a song dashboard with that new name or that new writer. If you look at that first use case we talked
about, the community contribution system we’re working on, it's extremely similar. It's just the same document and message and
approval, and this container of the public space where this stuff ends up.

With the song dashboard, what's really amazing
about this is that it can actually be hosted by anybody who's subscribing to this blockchain. If you're running your own server and you're
within your network, you just look at the blockchain from the blockchain, get all the
information out using Git (the blockchain tells you where to get the Git) and then the
Git constructs and then you have this new object, and this would be a song dashboard. If another person wants to build a different
type of registry or use it for their own kind of analysis, they can use this and build a
very different type of card, very different type of dashboard using the same underlying
data that exists in the shared repository. That's the idea of the project. For us, the key is that all of these use cases
that we’ve talked about share a unified layer of the stack. We're building up the stack layer by layer:
on the Hub layer — this is something we've talked a lot about — we have these core
technologies about this runtime that runs everywhere.

Whether it’s on the server or on the desktop,
JavaScript is the key. Git is how we compose this data so that it
can move up and down over time and be able to not only fork — which is something we're
good at at blockchain — but also merge, and that's one of the power of that you can
get better; your content and data and and understanding of the world can become better
if you can merge this together, and Git provides that. Obviously, Ethereum and Postgres are things
done during our TGE, which is taking information on-chain and making it much more queryable
and indexable.

We've completed that work right now so we
have this really powerful indexing system so that anything that the Hub brings in allows
you to do that. We’ve also integrated GitHub so that the
community contribution system is actually going to GitHub. If you're contributing to our community catalog
of Cardstack content, or, for example: we're creating a catalog for Web 3.0 ideas, concepts,
projects and techniques — you can contribute to it using the same UI, but that becomes
a contribution to GitHub as a way to build up this catalog. As we move on with this basic core set of
features that's shared across all Cardstack applications, then we can start building adapters
and arrangements to other dApps, like lower-level integrations, whether it’s on EVM or EOS
— that just becomes another data feed into the Hub. The Edges provide standard features, like
allowing you to configure a card, look at what fields you need, and providing various
quick ways of editing it. You don't have to make the forms — once
you make the template and create what the card looks like, we already know what fields
you have in there and we can give you a standard editor.

This allows you to search your library and
find things you have looked at before. Dealing with notifications, like someone’s
submitted something please look at it — that queue feature is universal whether you're
dealing with music, editorial, wallets, or trades — whatever it might be, it’s same
queuing system that we provide for free. An environment dealing with visibility, sharing,
looking at what's official in public and what's being in-draft, with teams able to work together
— that's all standard features that are provided outside the card, outside the edges
of the card.

Within the card itself, we want to be able
to build a lot of different types of card bundles, these Decks. Things that deal with data, we've dealt with
that in the TGE: you can see balances, you can see on-chain status as well as bridging
into GitHub stars — all that stuff is sucked into the Hub and presented as data cards. Obviously, we saw a lot of content stuff,
as well as things for messaging, and second for actions. Our goal is to move to asset cards, or cards
that actually reflect the asset that you have traded and you've bought an insurance contract. These are all just cards exposing their state,
and that state can come from anywhere that is connected through the Hub.

Spaces itself, the type of Space where you
can bring these cards together, could look like a website, could be a catalog like the
registry, could be a dashboard for you or for your team, it could be a portal for your
customer to interact with you, or it could be a true market where people come into this
Space, put their things in and take their things out with different type of products. Finally, with flow, there are a lot of similar
processes with submissions, decision making, approve/deny. Obviously, when you deal with more processes,
you want to have automation. The great thing about having Card Flow being
a separate data model, is so you can analyze and you can look at all the approvals and
all the messages going in and do some automation where we could use very simple rules like
IFTTT or Zapier, e.g.

“If this thing comes in from this person
auto-approve”, or it could be smart and futuristic where you use rules and maybe even
machine learning and AI to automatically approve or deny certain types of transactions. The great thing about that type of thing is
that it really is compositional, you can build up on this data model that Cardstack provides. Everything has an API, so you can build small
and have a smart thing. Finally, with organizations, we want people
to be able to use Cardstack to, almost like when you create a Slack organization, everybody
shares in different channels, but each Slack group is different. Each Cardstack org is also different. It could be four teams, just between four
or five people, sharing cards and constructing some new narrative, or it could be for an
organization. That’s an enterprise — within them, their
boundaries backed by maybe a blockchain, maybe not.

Maybe it’s just using Cardstack as a way
to expose a certain enterprise system and kind of arrive at some shared truth and conclusion. But what excites me the most is this idea
of using a consortium where at the boundary of an organization, using a blockchain to
synchronize data across multiple organizations, similar to the Dot Blockchain use case, but
also if there is a syndication mechanism where different catalogs of content and data become
synchronized through a blockchain then you can build this larger entity: a union, a digital
union, beyond one organization. I think that's what it really comes down to,
as the promise of blockchain: is that actually becomes the reason you do all this stuff underneath
not only within the Cardstack universe, but also all the blockchain thinking that's behind
Ethereum EVM and EOS, and all these kind of use cases. So. We have been working really hard towards this
roadmap. This is really where we are. We have this idea of a development frontier,
which is that every single time we move to the left, we also move up.

We want to build up the stack and get more
features into the stack. In Q2 at the conclusion of our TGE we had
an Ethereum plugin. It's configurable and has data that represent
what’s going on with the whole process and log in and KYCs and that type of thing. That's all built on the Cardstack Hub and
the capability. We've added the ability to deal with indexing
and the Git workflow so that you can create content-oriented system and we're working
on that now.

Our goal is, by the end of Q4, to do some
of the more blockchainy thing with Sawtooth around synchronizing this distributed content
management system using Git. Once we get to that point we feel like we've
got most of the idea of Card Space and Card Flow in the code. Now, obviously every single time we move up
and out we also have to kind of focus on the underlying capability and solidify the underlying
codebase. By doing it that way, that means that anytime
we add new features, we're solidifying the underlying foundations that when we build
more, things get faster. Looking to 2019, we would do more workflow
features around submissions and the type of action interactions. We have some really good work around what
the user model is and how cards can be embedded, lifted from a Space put into a Flow do something
in edit and negotiate and go back into space and being official, either on-chain or in
your possession.

Then going beyond that really thinking about
what the kind of enterprise adoption story for people who are using Cardstack as a way
to build these kind of experiences that are about bringing your user base and your team
together and then beyond that thinking about consortium as a unification between traditional
public blockchain and the enterprise blockchain. I think there's a convergence there and Cardstack
is very well positioned as the stack to kind of make that all happen. So — what you can do to stay up to date
is to look at the GitHub repository and this is what we’ve been using now.

Now that we have kind of built the Edges in
the Deck we would start doing regular demos periodically so that you can see as we implement
new design like the ones you've seen, it will show up and then we will share with you what
we're working on, in the rendering pipeline, on the deeper lower-level structure and invite
the team to share those ideas with you. Our goal is for community members to be able
to play with this within three months. A kitchen sink which is a lot of card types
we've created that you can go and make something of your own and that will be something that
gives you a visceral feeling, "Oh this card-based universe feels different than just a WordPress
site or posting something on Facebook." Then our goal, and obviously the ecosystem
goal, is to allow people to operate their node, their Hub of their own on their own
cloud, on their own desktop.

Very peer-to-peer is great, but it would be
even better if that was something that can be delegated so that it runs continuously,
but more importantly, it's your Hub, it's your data and you control it, and it's something
that flows in and out of your space through the workflow that you orchestrate, with the
people you trust. There are some questions from the community
around how Cardstack compares to other kind of like projects and I thought a little bit
about it and say, "What we're really trying to do is to figure out what is the tradeoff
between feature-rich, where you can get an app that does a lot, versus integration and
flexibility. I want it to theme it, I want it to integrate
it with my data sources. If you think about packaged applications or
SaaS services, they're very rich, but you can't really extend them.

You custom code everything, then it's everything
that you want, but it takes a long time to get to all the features than off-the-shelf
SaaS products or software products can give you. There are some platforms called low code platforms
that allows you to build a drag and drop and create fields and databases. We have more than that. We really allow you to start with something
like that, but really extend and build your own logic, your own template, and your own

We see ourselves as a programmable application
framework. We are starting here. Cardstack will start more like a custom coding
library with a set of frameworks for developers, but our goal is to move here. Is to really find a way to show people that
all these modules that's being created, these card types, these Decks can become a true
source of features that if you are building a new Card Space, you have a catalog or everything
including multi-step forms and insurance applications, and complaints and stuff like that. These are all built, hopefully, by the community
and that becomes a catalog that you can start from. We've seen that in places like in enterprise
like where you can go to an app exchange and download new real estate,
forms, and sets if you're in the real estate industry, and WordPress in the content field:
"I need something to give me a map and it's plugins and themes that does that." That's really powerful.

There's a catalog of things that exist out
there they can bring together. Obviously, WordPress and Salesforce are not
doing crypto, are not doing blockchain and not doing this deep integration, but it's
a good model for us to say, "Hey, there's good precedent of successful open source and
more proprietary stuff that's there." The question then is, what about the other
quadrant? What are the other things that are in there? There are a lot of tools in the web space
where people can construct new— Quickbase is an example of a product, or Airtable, where
you can create a mini-app.

It's quite restrictive, but it’s pretty
powerful things if you're trying to make a spreadsheet type of database application. For workflow stuff, Zapier/IFTTT allows you
to connect different systems together. These are very off-the-shelf, but you can’t
make IFTTT part of your daily workflow — it's just automation and you still need the UI. Cardstack is the UI that you interact with,
and then we can add the automation capability.

So it's quite a bit different than that. Then in the crypto space, there are a lot
of really interesting products. MyCrypto is a good example of something that's
off-the-shelf — not really customizable, not a dev platform, certainly open-source
— but it's mostly for end-users to use it. A lot of features allows it to interact are
there an emerging ones for other blockchains. Then in the private permission ledger there's
something called Hyperledger Composer, more of a toolkit to get a blockchain up and running. Those are pretty interesting, because it takes
the development of things and makes it more of a low-code experience to bring that out
there. The question then becomes: what are dApps
today doing? dApps are really just right now custom applications that expose the capability
of the underlying smart contracts and blockchains. Very narrow, very focused, integrate only
with its own thing, not particularly feature-rich and it's certainly not intended to integrate
any other dApp.

A dApp for governance does governance and
nothing else. A dApp for asset management does asset management
and nothing else. If you look at dApp development platforms,
a lot of them follow this kind of app store model, which is: build an app for this thing,
distribute it and here are the common tools to use them. We really believe that that's actually quite
limiting as a vision. In a decentralized world, why would you want
an app to only do one thing? Don't you want an experience that allows you
to bring together all four dimensions of Web 3 and bring everything together? That requires us to get outside of this “one
feature per dApp” system.

I’m going to eliminate all that tools that
are not doing blockchain — I don’t see WordPress or Salesforce getting on blockchain
— and this is the landscape. We’re going to start out similar to other
development tools, even though I think by providing Edges and the queue and flow system,
we allow you to start out with more than just some API that allows you to do storage, identity,
etc. We provide pre-built templates that you can
start from, instead of a blank page for you to start from scratch. As a developer adopting Cardstack you’d
have a leg up because there's just so much that we provide out of the box. Our goal, and the ecosystem goal, is to really
allow users, even before any developer comes in and builds great things, from the tools
that exist with our Card Space and card flow to experience Web 3.0 and then learn how to
do it.

And then not only do it within one network,
but take those tools and bring it to all different networks they’re doing. Like, "Oh, I've been using this thing in the
music industry”, or “For the film industry it’s really good so let me go and gather
a small team of people and use Cardstack” and they can use it to, let's say, track a
film project. I don't know what they're going to do, but
if those tools allow them, to instead of using email and PDFs, use cards and workflow as
a way to construct the workflow, how great would that be? End users learning tools and being creative
in how they use it. For developers, this is the real challenge. Developers really only get their work done
when they deliver the usage, their usefulness. So developers can reuse what's there — the
cards, that's open-source, the decks that existed before — and build what's unique
to them. If you're building a film system, maybe there’s
something around film that’s unique to it, but there's nothing about the message and
approval that’s not all the same, so why don't you reuse the existing stuff in the
Deck that we already have? That's how you drive more usage quicker and

I think another aspect of it is that developers
and end-users are great, but developers don't really want to service end-users. They usually have an idea of like, "I built
this website for you, you go host it there or somewhere else," or a SaaS product where
there's a built-in service providing model that will answer your phone or answer the
email. We really believe that this idea of decentralization
doesn't mean that you're totally on your own. Someone still needs to support you, and there's
really a lot of opportunity to provide value and providing value means making money and
earning revenue. So, we want people who support the stack to
compete on service quality and earn loyalty. This is the important thing: long-term, software
is extremely sticky.

When you use a piece of software, you learn
it, and whether it's SaaS or something on your phone or whatever it might be, if it's
good you're going to keep using it, and you're going to keep with the provider that's giving
you good service. It's not about, "Oh, this is all fungible,
it doesn't matter who it's going to be." There's going to be a relationship. Our idea of an application contract is that
the same open-source code is supported by people who made a Deck, have a Space, and
you're using it. They may share in the infrastructure, maybe
even share a hosting infrastructure, but you have someone to pick up the phone and call,
and that's extremely important.

I believe that there's a lot of symbiosis
in that. The row here is that to allow the end users
and developers and service providers to do this, we have to provide the foundational
layer. So this is the Cardstack 'foundation' which
is: building a strong stack, building the ability to have a solid way to build, catalog
prebuilt cards and the use case templates to actually make it all happen. Once we have that, developer and end-users
can in different ways pull this existing resource and say, "We got it. Let's take it from there," and then between
the end users and developers happily build this ecosystem with this idea of new stuff
driving your usage pattern, driving your use cases, and then new service revenue which
is the foundation of the ecosystem.

We have talked a lot about the overall framework
of it: Cardstack is really two projects kind of interweaved together. One is the application framework to build
this future Web 3.0 experience, and the other one is to solve the problem of, how do you
pay for and how do you fund the continual work in this ecosystem? Everything is not free, and whether you're
buying tokens to fund it or paying fiat subscription revenue, we want to make it much easier. Our idea has been for the Cardstack token
mechanism (and this is something that we are going to be releasing a paper on soon) which
is allowing you to use the Cardstack Token to compensate anybody who's providing service,
whether they're running a smart contract on-chain and charging a fee on their token, or running
a cloud service helping you host your site or your catalog.

These are all things that are pretty sophisticated
as a way to distribute the value in a fair way, and obviously, some things are delayed
settlement, some things are immediate settlement, so we're working on a paper, and a design
— a very specific design to upgrade our smart contract, so we can add more and more
of this feature, and can be much more inclusive of all the things that's going on. This particular update obviously, hopefully,
gives you some idea of everything we're working on. I do think that there will be an opportunity
for us to talk more specifically about the 4 Edges design system which we've worked very
hard on. We doubled the size of our team, adding a
lot of people who can help us understand how to solve some detail-level problems around
the design. In the 4 Edges design model talking about
interfaces, design guidelines, and future directions — that will be something that
we’ll do soon. Then obviously, we’ll also talk about the
interest around this idea of CARD being a universal fuel around the fiat on-ramp, the
CLUTCH compliance mechanism, and more importantly how to participate as a host relayer, so that
you can help people whether that's through your connections, and your understanding of
other protocols, if you want to bring people let's say to the EOS system, or you have another
ecosystem you want to bring people to.

People come to Cardstack, experience Web 3.0,
and then use your host relayer to tap into other services, so they don't have to go and
buy their own token which may be too difficult to do. There's a couple of questions that the community
has asked beyond this point. One of which is around how I've spent some
time in Asia in the summer really talking to a lot of projects, especially the technical
founders of the projects that are doing blockchains and smart contracts and say, if we're building
this experience layer, what can we be useful to your ecosystem? A lot of those learnings about what the challenges
are that they're facing in getting real world utility and getting more people to the ecosystem,
is that it's very hard to go and bootstrap entire UX community from scratch. So we provide them the abilities, and say,
"Hey, here's a bunch of cards, let's connect it to this ecosystem," and suddenly all the
things already up and running from day one, just building that one hub plugin. We're going to continue these discussions,
and present essentially like a small deck of basic crypto blockchain project cards that
will expose the capability, and those partnerships are ongoing, and hopefully we'll release not
only for the Ethereum ecosystem but other blockchain project ecosystems will be serviced
in this community, so that they can hit the ground running with all the cards and the
workflow that's already there.

Our project, when we finished the TGE, we
divested out of Ethereum holding — only about 15% left now — and into fiat and Bitcoin. We're a healthy project, we can execute this
vision as planned, and it's exciting to be able to see the progress that our team is
being able to make, as well as seeing the applicability of our technology to a lot of
problems as people move beyond speculation to utility and are looking at user experience,
not only as a differentiator but as a necessary step for us to get to that type of promise
of what the decentralized world can be. I want people to understand that Cardstack
at the end of the day is about unlocking the value and the promise that we see by allowing
people to experience it. We want to put the tools in the hands of end
users, and that's our deep goal.

We want developers to learn from our developers
who are learning from our own core team to figure out how to find the right boundaries
so that these mini-apps can be built really simply with skills that do not require you
to be a blockchain engineer, just a web developer. If you know Web Dev 2.0, 3.0, JavaScript and API,
you will be able to build what looks like the experience layer of these new apps. That's how we're going to get developer adoption,
because we're reaching out, not to the same pool of people who know how to do blockchain,
but broadly go to people and say, "Hey, you're doing JavaScript and using other stuff from
before, why don't you try building with these workflows. By the way, I just turned your workflow into
a Git transaction that uses blockchain, and you're a blockchain engineer now." That type of excitement is really the type
that will really bring new entrance, not only for the Cardstack project, but also to the
underlying protocols we can integrate with.

Thank you very much for your time today. We have a new slogan apparently. It's “Cardstack: Experience Web 3.0.” Thank you very much, and I hope to talk to
you soon..

You May Also Like