In this short note I propose a system for decentralized web applications, mostly independent of Bitcoin, but using it where it makes sense. This proposal is heavily inspired by nostr.

What the heck is a Web 3.0?⌗

Recently Jeremy tweeted about Web3.0 on Bitcoin, I will use this as an excuse to write about a distributed application design I’ve been thinking about for a while.

Let’s begin with the problem definition. Jeremy states it as “Web 2.0 in self sovereign”, which is rather vague but enough to work with for now. For me that means the likes of Twitter, Reddit, forums, rating sites, etc. I’m leaving out more commercial services like Amazon since these, by nature, require a trusted counterparty (to deliver the product) and are thus less interesting to decentralize.

So generally, for the named services, we don’t have to counteract strong incentives for equivocation (telling two parties different truths in an attempt to defaud them) since there’s no money involved. This means we can relax consistency guarantees. Not everey user needs to see the same state. Ideally this view converges and only becomes more complete over time, but even occasional conlicts are not that bad (just show the user that there are two versions of the same reply, someone probably tried to temper with history).

This means we can make an entirely different set of trade-offs than for Bitcoin, where such failures would be considered catastrophic.

Assumptions⌗

I make the following assumptions:

  • All users are addressable pseudonomously (e.g. run Tor hidden services or Nym which also runs in the browser)
  • Users have sufficient storage for all their community’s content
  • Bandwidth is not too limited (if you are streaming a full HD video in the background to listen to some music it probably isn’t)

I think these assumptions are generally necessary for really decentralized systems. So they are probably not limited to my design.

How to build a Web 3.0⌗

My vision for Web 3.0 is a forest. A forest, in the mathematical sense, is a set of trees. These trees consist of nodes which at a minimum contain a reference to their parent (to define the tree) and a payload (e.g. reddit post, forum comment, …). At this stage the system resembles reddit the most, a loose collection of discussion threads. Users “subscribe” to interesting trees or subtrees, meaning they ask their peers for any new nodes when they sync up with each other.

Adding Structure⌗

But Reddit is not the web. There are many more interesting applications that require more structure. For that we introduce another field in each node: a predicate. This predicate has access to the entire subtree of its node and defines which node additions are valid. These should generally be designed such that a different order of node additions is handled gracefully (if in doubt, alert the user) since there is no global consensus. In practice predicates could be encoded as WASM since it is efficient, versatile and easy to sandbox.

With these predicates we can now define e.g. a Forum, limiting subtree depth of topics to 1, or a Twitter clone that e.g. limits who can reply to posts, product rating sites that only allow one comment from everyone with a proof that they bought a product etc. Most interestingly these predicates can also enforce a schema for the payload section of each node, allowing for more structured data to be stored.

User Interface⌗

While some older internet users might be comfortable working directly with the forest, most people would want a smoother interface. One option would be specialized clients for certain trees or types of subtrees. The problem there is distribution. But we are talking about the web, which has become an application platform over the years anyway (for better or worse).

So instead of requiring users to download a special client or plugins for a general client, why not allow encoding a custom user interface in the root nodes of application subtrees? These UI definitions could contain views and forms that allow users to easily read and create valid nodes on the subtree.

Weak consistency⌗

To solve the problem of users creating alternative versions of the tree retroactively and feeding them to new peers, nodes could be time-stamped using OpenTimestamps on Bitcoin. This would reduce the ability of users to retroactively alter history.

It does not prevent user from creating two versions from the beginning though and publishing the second one delayed. Where necessary this problem might be solved using bonded oracles. I don’t think this will be generally necessary though, maybe for rating sites with some commercial interest. But generally equivocation isn’t worth it for potential attackers imo.

Monetization⌗

A lot of content today is financed by ads. We generally don’t like ads. So some alternative form of monetization is needed. One possibility would be automated Lightning tipping for visited articles or upvote functionality that requires one to pay the author first (not a big deal if one actually enjoyed the article). It’s also imaginable to pay peers for synced nodes, especially old ones they kept archived.

Name Services⌗

User readable names are a big problem in decentralized systems. I think a name service (like DNS) can be built as one of the trees in the forest. Its validation criteria for child nodes would be either proof of payment to some entity (way to finance development?) or proof of burn. Ideally the amount would be inversely proportional to name length, making squatting short names prohibitively expensive. Names should also require renewal to prevent useless squatting.

Applications Involving Money⌗

I left out a big chunk of applications that involve money (market places etc.). For these I’d suggest federated models. If there are too strong incentives to defraud users then the lack of consensus in the described system would be detrimental. But fortunately markets make money which can be used to incentivize a federation to be set up and maintain all the consensus critical state (arbitration contracts, merchant ratings, …).

Conclusion⌗

There are ways to build most interesting applications in a Web 3.0 fashion without creating a new token or consensus system. Relaxing the requirement for consensus makes the system much more scalable. CRDTs can probably be used to make such a system operate smoothly.