Email is Sufficiently Decentralized - The Case for Web2 Wrappers around Web3 Infra

[alice_und_bob]

Tldr: This post makes the case for us creating a web2 wrapper server and client temples around web3 infrastructure

(feel free to share the tweet)

Alice thinks that Bob is a nerd

Successful Web2 products have a great onboarding experience. Google, YouTube, Twitter… If you are just passing by, you can consume it without questions asked. Only after users are getting interested in the product, they are provided with low-barrier ways to increasingly become part of the platform by sharing content and eventually creating an account.

Web3, including Polkadot, has horrendous UX. Most agree with that. In virtually every practical use case Bob has to install client software (signers/wallets), read tutorials, buy tokens from exchanges, bridge them, etc… Just to be able to re-take control of the web and interact without trusted intermediaries.

It reminds us of the early days of the Web, where you were forced to install chat clients (IRC/ICQ/MSN), email clients, etc. just to do one seemingly simple thing.

It’s an impediment that might be tolerable (or even enjoyable) for innovators and maybe early adopters, but that will definitely block us from reaching the majority of Internet users.

CC BY-SA 3.0

It doesn’t have to be that way! Web3 apps could actually have minimal barriers to entry and be easy to use!

It’s already happening: Subsocial recently launched grill.chat, a chat frontend for Subsocial Network that does not require you to have any tokens or sign transactions. It’s a frictionless user experience that allows you to onboard without reading a single line about what web3 is and does. It just works!

When Alice first launches the app, she is not logged in and is presented with a chat UI. Upon sending her first message, the web app automagically creates an account for her that she from now on uses.

Without looking into the code, let’s make an assumption about how this challenge is solved in a Web3-ish way:

• The client handles the key management, signs the transaction on user premises, and sends it to a Web2 service
• The Web2 service repackages the request and forwards the request to the Web3 network, paying the gas for the user

I love this solution because it shows us the direction that we need to push for. Low barriers to entry, hide complexity from the majority. This is why I am championing for Web2 wrappers around Web3 infra.

“But Alice!”, we hear Bob inquire, “doesn’t that lead to centralization?”

Bob has a point. If we make it easy for users and give them Web2 middleware, they won’t need to manage their own accounts fully, won’t take custody of the tokens necessary to use the network, and worst of all, will be relying on a third-party to help them with signing requests.

In terms of IT security properties, if Alice uses a Web2 middleware to submit signed Web3 requests, she maintains integrity and authentication, but risks availability. She might get locked out of the service by the Web2 service provider.

We are in a dilemma of seemingly having to choose between compromising our Web3 values and getting corrupted by the tendencies we wish to overcome. Or instead staying true to Web3 values, but never reaching escape velocity to become widely adopted technology.

Email is sufficiently decentralized

I want to propose a counter-argument: Email

Email is sufficiently decentralized. You can use Gmail or Proton or any other service hosted by a third party to have ease of access. Or you may choose to set up your own servers and keep full control. The protocol is freely accessible and there is an abundance of clients and choices.

You don’t hear people arguing whether email is centralized or decentralized. They just use it their way and get things done. It doesn’t matter if you are in school, an elite IT person, or a grandparent. It just works.

I argue that we should give people more options to participate in Web3. Even if they don’t know what is happening under the hood (you know… like 99% of people)

People need to have the option of using Web3 directly or with Web2 middleware in between.

This is our only chance to achieve critical mass.

Third-Wave Polkadotism

The first wave of Polkadot builders were the OGs that built the original tools. Polkadot, Substrate, Polkadot.js, etc… They laid the groundwork for a multi-chain world. They

The second wave of Polkadot builders were parachain teams. They build chains that take blockspace and transform it into higher-value features.

We are now entering the third wave. App builders that tap into all the features that parachains offer to create powerful apps on Polkadot. It’s their time to shine. To empower them, we need to give them tooling that allows their users to just use the app. We need to get apps into a state where you can just use them. And once you start to like them, you start jumping through the hoops that give you more power.

2 components that can play a role in this:

• Client software (in-browser applications as well as extension) need to handle more work under the hood. There are use cases where
  • account management can happen without the user knowing it; or without forcing them to think about it right away.
  • signing transactions is not a necessary manual task, as long as the user sufficiently trusts their own client machine
• Middleware is a helper service that takes work off the users’ hands to perform it for them. Just like a Web2 product pays for the servers, a Web3 middleware might choose to pay the gas needed to run on Web3 infra.

We need templates for this! A 200 line node.js middleware server would be a great start. A polkadot.js UI sample that allows you to post use a chain without logging in would go far in terms of getting Third Wave Polkadot developers onboarded.

Eating the cake and keeping it too

We have built the infra, now it is time to build the apps. It is already happening. Gear/Vara has something in preparation for app developers here too. Smart contracts that are pre-loaded with gas to just go. Subsocial reacting to user complaints and giving them what they want.

While we build all that, let’s say the obvious: Self-Custody is not negotiable. Nation States and certain institutions will want to divide and conquer us by the question of self-custody. It is not negotiable. Self-Custody is the most important topic to ensure that users are free to consume Web3 in any way they want. Let’s make sure this is granted.

And when that is given, let’s make it easy for the majority to onboard to Web3.

(feel free to share the tweet)

[finsig]

I like the big picture. If I understand the example correctly, the onboarding flow creates a burner address and the network later burns it for not having the existential deposit? Is there some mechanism that can convert that burner address into an address secured privately by the user?

[alice_und_bob]

I think in the case of grill.chat, it creates a private/public keypair for communication with the Web2 service; and the Web2 service then acts as a single web3 user. How it behaves in exact detail is not clear to me.

In the case of a first class Substrate on-chain account, there would need to be a possibility to pay gas on behalf of the user. I don’t actually know if that is the case today.

There might also be workarounds like just-in-time provision of gas to the account in question.

In the case of Vara, the cost is born by the smart contract, that in essence can pay for its own execution; if I understood that correctly.

[tomaka]

@alice_und_bob

Or you may choose to set up your own servers and keep full control.

This is unfortunately not completely true. If you setup your own server you might end up being blacklisted by the big names of the industry.

Often it’s for good reasons, for example your server got hacked and someone is sending spam through it. But sometimes you just don’t know why, as the criteria for getting blacklisted are completely opaque.

[olanod]

We have a similar vision and approach in Virto where user experience has remained our top priority mostly out of necessity but trying harder to remain on the decentralized side of things(we started as a way to decentralize a crypto on&off-ramp in Venezuela used by thousands of normal users that had risk of censorship).
Using Matrix as our “wrapper” we got the seamless user on-boarding without compromising much on decentralization, no need to install anything, just register in a homeserver which can get as convenient as just touching your fingerprint reader(working on a OIDC+WebAuthN/passkey+some hidden captcha integration).
Matrix has a sweet spot between decentralization and usability and we want to leverage that(also improve it). There are many ways we can use the open messaging protocol to give our ecosystem a boost and solve the problems mentioned here and more, we’ll keep building with our (somewhat limited)Kusama treasury funds to showcase some of those points. We definitely can eat the cake and kept it

[rich]

@olanod

Using Matrix as our “wrapper” we got the seamless user on-boarding without compromising much on decentralization, no need to install anything, just register in a homeserver which can get as convenient as just touching your fingerprint reader(working on a OIDC+WebAuthN/passkey+some hidden captcha integration).

this speaks to substrate >< open source api’s, for example this forum is built using Discourse, we are building out substrate >< discourse integration and consolidating the whole governance experience within a unified UI/experience.

@alice_und_bob

The first wave of Polkadot builders were the OGs that built the original tools. Polkadot, Substrate, Polkadot.js, etc… They laid the groundwork for a multi-chain world. They

This was delivered by a centralised team of W3F and Parity. Would it have worked if it had been treasury funded to a random and emergent collective?

@alice_und_bob

The second wave of Polkadot builders were parachain teams. They build chains that take blockspace and transform it into higher-value features.

You can also see this second wave manifest as treasury funded products, tools and media/events funded in relatively indiscriminate fashion - the positives were that this ‘discovery phase’ served to identify domains of investment (problems seeking solutions) but failing to tightly integrate these components under a cohesive strategy, leading into your final point…

@alice_und_bob

We are now entering the third wave. App builders that tap into all the features that parachains offer to create powerful apps on Polkadot. It’s their time to shine. To empower them, we need to give them tooling that allows their users to just use the app. We need to get apps into a state where you can just use them. And once you start to like them, you start jumping through the hoops that give you more power.

Per The state of DotSama there is inherent and likely irreconcilable tension between For Profit Parachains built around independent token economies and Common Good/System chains, which concentrate value accrual around DOT/KSM in their respective ecosystems.

This will likely result in an eventual consolidation of the Polkadot brand under a cohesive ‘super-app’ strategy, as Parity/W3F instigated and driven collectives continue to shape the future of the networks.

I don’t personally believe any parachains can survive in this model, unless they switch strategies towards more common good approaches, or iterate towards new models of value accrual that balance the tensions better than the current model.

In the short/medium term this tension will likely work against the outcomes you would like to see as we see more, not less fragmentation.