tl;dr: exploring how we can bridge the Web 2 and Web 3 ecosystems in the long run and how identity plays a big part in it.
I think Web 3 is here to stay. By Web 3 I mean the philosophy, concepts and technologies that prioritize user choice and ownership, and can be used to build decentralized services. Blockchains (e.g. Ethereum, Solana), tokens, protocols (e.g. IPFS, TheGraph, Lit), services (e.g. ENS, Filecoin), dApps and users’ keys make up Web 3 (not meant as an exhaustive list).
I’m unclear about how successful it will be, and I don’t think everything around today will remain so. But I think it will be successful. I believe it’s already successful for some things.
I also think that Web 3 is not “the only” web that will exist. It will co-exist with web 2, at least for some years (decades?). I’m not alone in thinking that:
After that, maybe, another paradigm might come along. As a developer, and particularly a developer building products for other developers, I spend a lot of time thinking about what this will mean. I thought it might be interesting to share my thoughts in writing.
This post is mainly for
- devs building Web 2 apps that talk to Web 3 services
- devs building Web 3 services that you want to be consumed by Web 2 apps
In this post, I link to Ethereum docs and concepts because I am most familiar with those, and it’s the largest platform for devs today. Similar things apply to many other chains.
Web 2 apps using Web 3 constructs
Web 2 apps can enhance experiences for users via Web 3 constructs.
Shopify is diving into “tokengated commerce”, customizing shopping experiences based on a user’s NFTs. There’s a very clear, in-depth article about this here. Tokengated commerce is a wonderful idea. What you own says many things about what you like. Customizing the shopping experience based on your NFTs feels natural.
Twitter and Stripe are partnering to allow crypto payouts, making it easy for content creators to get paid with cryptocurrencies.
Reddit is building its community points system on top of a blockchain.
These are large consumer-facing platforms. They didn’t become dApps, but they are dipping their toes into Web 3.
What does it means for developers?
Developers will need to figure out how to integrate the Web 2 and Web 3 worlds. We are already starting to see this surface in different ways, but companies creating developer tooling and infrastructure are exploring and implementing Web 3 integrations:
- Stripe is building web 3 payments infrastructure
- Auth0 announcing Sign in with Ethereum support
- Google Cloud is forming a web 3 team
The pattern: these large companies that build Web 2 development infrastructure are now creating components that make it easy for Web 2 app devs to integrate with Web 3 concepts (NFTs, cryptocurrencies, ENS, etc.) without going all-in (i.e. building a dApp).
They are building a bridge between Web 2 and Web 3 worlds. Their bridging is about allowing Web 2 developers to interact with Web 3 constructs, and that’s the focus of this post.
Another aspect of bridging would be to make web 2 data available to Web 3 devs. I might do a blog post on that if this one spurs interest.
The Web 3 trust model
Web 3 philosophy is decentralization. Each user owns their data, their $$, etc.
The Web 3 trust model relies on asymmetric cryptography, where the source of trust is the user’s private key.
While there are some delegation use cases, third parties are commonly not trusted to act on behalf of users, and delegation would be a user’s choice.
For a bridge between Web 2 and Web 3 to exist, trust about the user’s address ownership has to flow in both directions.
Identity is the bridge’s fabric
Ultimately, the user’s address in the context of web 3 is their “identity”, who they are. Yes, they might have many of those, each being a separate “identity”/view that they present in different contexts. But it is their identity nevertheless.
Bridging the Web 2 and Web 3 worlds means solving identity on both sides of the bridge and making it easy for developers to build on top of that foundation.
Naturally, Web 3 principles should not be compromised when building the bridge. We might need to adapt the way Web 2 identity protocols (e.g. OIDC, OAuth 2) and standards work to accommodate the Web 3 needs and philosophy.
It all starts with an address
A Web 3 address has a related private key and public key.
The number of addresses is growing fast:
But the number of active addresses is growing slower:
From the previous charts, we can infer that the percentage of internet users that actively use their Ethereum address is low. Metamask said they have 30 million monthly active users two months ago. But what of users that don’t own an address?
For Web 3 to gain long-term adoption, a paved path has to exist for mass users to adopt it. Not everyone is crypto-curious. An approach that allows users to continue using the patterns they are used to (e.g. sign in with a social provider) and only become aware of blockchains (and keys) if they later want to is extremely valuable.
While the number of addresses is growing extremely fast, a relatively small % of all internet users solely own their private key: either creating the key pair offline or via a hardware wallet. A lot more exist as “custodial wallets”, where services are the ones managing the keys. Centralized exchanges like binance or coinbase are the most common example.
While that might not be “pure” from a Web 3/decentralization perspective, it is very positive. It’s bringing some of the Web 3 ideas to the masses.
From a developer perspective, bridging the Web 2 and Web 3 worlds means custodial services have to associate blockchain addresses to user accounts, manage keys securely and provide control (at least for other internal development teams) to manage wallet interactions.
Services like magic.link, bitski and venly are helping to bridge the Web 2 and Web 3 worlds by creating key pairs for typical Web 2 login mechanisms and providing developers with APIs and UIs to manage those private keys.
Once a user controls a private key, that’s where the fun begins :)
Sign in with my private key
Let’s look at a relatively simple scenario and see how it’d work in a Web 2 and a Web 3 application. The user:
- Identifies on an app.
- Changes their profile picture to {input A} and saves.
- Realizes they made a mistake in #2.
- Change their profile picture to {input B} and saves.
A Web 3 app (dApp) allows users to “connect” one of their addresses. This operation essentially gives the browser the user’s blockchain address. There is no “backend” other than the blockchain and other decentralized services. Typically, operations that require authenticating the user on a Web 3 component require a signed message from the user’s private key.
Web 3 case
With Web 2 protocols, users don’t have to take action to prove their identity on every operation. Users typically sign in once, and the client/browser stores a credential that is sent on subsequent requests to the backend, which uses it to authenticate the user.
Web 2 case
The diagrams above are oversimplified to get the point across
The Web 2 user experience is better. Bridging the Web 2 world with the Web 3 world requires keeping a UX similar to the one from Web 2, and when calling the blockchain (or any other Web 3 native service) proving the user controls the private key and intends to perform each specific operation.
How do devs associate the address with the user account as part of a Web 2 app?
Services mentioned in the previous section already associate the private key with the user account. But what about those that don’t? What if the user uses Metamask, Argent, Trezor or any other type of wallet?
That’s what Sign-in with Ethereum solves. It allows users to establish a session (in the Web 2 sense of the word) with a service, using their private key as a credential to prove ownership of the address.
Image source: https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/
If this sounds interesting, you should follow @signinwitheth and the @SpruceID folks.
And once a Web 2 app knows a user’s blockchain address for a fact, this opens up a world of possibilities.
Potential use cases
Once the user’s Web 3 identity is known, it’ll be natural for Web 2 devs to want to go further. That will mean:
- Reading/writing publicly available data (e.g. on-chain) related to the address and using it for business logic. Let’s call these “operations that don’t require user authentication”.
- Reading/writing data that requires authentication (e.g. a user’s private video stored in decentralized storage or making on-chain transactions). Let’s call these “operations that require user authentication”.
Let’s look at each of these in detail to understand how it could work.
Operations that don’t require user authentication
This one is the simplest case. Developers will be able to call any API that takes an address and does not require authentication. Some use cases that come to mind are:
Reading ENS or Unstoppable Domains to fetch profile data and display it, which would open up possibilities for a “global public username and profile pic” if users so choose to have it.
Implementing token gating by fetching a user’s POAPs and restricting access to resources based on them.
Transfer assets TO a user’s address on-chain.
Down the road, if they become mainstream, use services like proof of humanity to avoid fake user accounts.
Note that there are other ways to achieve some of these via digitally verifiable credentials, and those don’t require public data. But that’s a story for another post…
Operations that require user authentication
Oh, things get tricky :) We are all used to a dialog like this:
If you want a Web 2 app to access your Gmail data, you log in with Google and then get a dialog to consent to the resources from your account you want the Web 2 app to have access.
How should this work for Web 3 services? If your Web 2 app wants to read data that exists in two different Web 3 services:
- should you have to “log in” to both of them?
- or only consent to grant the app permissions to both of them?
- what’s the UX like in each case?
In the context of the Web 2 app, a token issued by an authentication server (Google in the previous example) is used to access Gmail’s API (Gmail is the “resource server”). The Web 2 app sends that token on multiple calls to the API on behalf of the user. In the Web 3 services case, how should this work?
- should the user sign a challenge for each interaction with the Web 3 service? Not the best UX…
- should they delegate permissions to the app? how?
- how do Web 3 services need to adapt for these delegation scenarios?
The folks from Spruce have started to think about these challenges for some scenarios. I think that’s a positive step forward. We need to learn about use cases and real-world scenarios to generalize those cases into repeatable patterns/guidance for all developers.
I think this is a big part of the challenge ahead.
Conclusion
I’d love to know what you think about this because I am actively thinking and working on figuring this stuff out. As part of my team’s work at Auth0Lab, we are exploring how to bridge the Web 2 and Web 3 worlds, not in the context of just one app, but in the context of providing tooling for all developers.
If you have challenges, anecdotes, or use cases around this topic, I’d love to learn about them. You can DM me on Twitter or join the Auth0Lab discord, whatever you prefer. Let’s build this bridge together!
Thanks to Jose Romaniello, Tomas Soracco, Matias Woloski, Patricio Worthalter, and Gabriel Gruber who reviewed this post and provided great feedback.