Can the Agent be the Browser of the Decentralized Internet (Web3)?
The Netscape Browser in 1995 made the Internet (which had existed since the 1970s) go mainstream.
What could be the equivalent of the Browser for the decentralized internet in terms of similar impact? Is it a wallet, a dApp Browser, or something else altogether?
We believe it might be the Agent.
But…what the heck is an Agent?
An Agent in the normal world is “a person who acts on behalf of another person or group”. In our context, it is software that seeks to provide agency for the user with the following characteristics:
It is owned and operated by the user.
It is a tool to help users navigate the world with agency in terms of identity, payments, data storage, and communication.
It is the user’s gateway to the decentralized internet to get her jobs done.
It can inter-operate with traditional web sites if they provide support for some (or) all the Agent’s decentralized constructs.
A good Agent will not just operate in a parallel world, but also enhance the user experience with the Internet as it exists today.
The Agent will have a network of web sites and dApps supporting the ability to read/write to the Agent’s services.
An Agent has 4 fundamental pillars: Wallet (How does the user pay and get paid), Identity (User’s credentials and who does she want to be in any context), Locker (User data store), and Messenger (How user communicates).
The Four Pillars of an Agent
Identity: Provides the user the means to engage with any dApp or service. The identity can be as simple as a faceless public key or a multi-layered identity with more detailed profile data. The user can choose what to expose to whom at any point in time ranging from fully anonymous to full legal identity.
Wallet: The user has multiple public-private key pairs and can engage with a given counter party using any one of them. The Agent can create a new key-pair or must be able to link to an existing one. (Note: Agent does not store or manage custody of private keys; they are provided by the user during engagement).
Locker: The locker is where user data is stored. A user can engage with any counter party (dApp or a web site that supports decentralized engagement) by: a) providing data to the counter party that feeds the interactions (authentication, payment, purchase history, intents, etc.) and b) Receiving data from the engagement and committing to the locker. The user can provide revocable and time-bound permissions to external parties for data access.
Messenger: A peer-to-peer private and open messaging protocol that works with minimal or no dependency on third parties.
Companies that provide agents must be open: i.e. they should support third party decentralized identities (like uPort or Sovrin), decentralized wallets (like Metamask or MEW), or decentralized lockers (like IPFS or Storj). Decentralized Messengers are not a real thing yet (Ethereum’s Whisper notwithstanding), but they will become a critical element as the decentralized internet takes real shape and form.
Agent Helps Users Dock Their Personal Data
The best way to understand the Agent might be to imagine how a customer (indvidual or business) can bring his/her own data to a website owned by a vendor.
The user with an agent has already created her wallet and identity. She also has a private locker.
Now let us say the user is on the website of a telco or an Insurance company she is planning to become a customer of.
Instead of creating a new account or using FB Connect/Google login, the user can decide to connect to the website using her agent. (Of course, the site needs to support the agent). This is what we refer to as the “docking”.
Once docked, she has logged in and can decide to share as little or as much data as she deems fit depends on what she perceives as the current status of the relationship. She can also choose to be anonymous or pseudonymous in some situations.
If she becomes a customer, the initial order and other data (policy, rate plan, invoices, etc.) are sent to the Agent locker on an ongoing basis.
She can choose to set up a payment arrangement from the agent so it is signed with her private keys. Vendor’s site does not have her credit card data and she suffers no risk if the vendor gets hacked.
Her ongoing relationship with the vendor can be managed through an in-built messenger that is connected to the vendor’s CRM system on the back-end. She is instantly authenticated while using the agent and her account context is auto-transferred to the support rep.
If the user already has a decentralized id, locker, wallet, and messenger, why does the user need an agent?
The agent orchestrates a simple yet compelling user experience and unifies disparate interactions across multiple services into a common underlying foundation. The a la carte experience of users specifying decentralized systems for identity, wallet, storage, and messenger, for each dApp or service they engage with, will find its own niches, but it is likely that mainstream adoption will require bundling, interoperability of tokens, interoperability of blockchains, and UX simplification.
Some Agents might offer their own protocols and dApps for decentralized identity, wallet, locker, and messenger. It is too early to say if there will be one big winner or multiple winners, but a skewed power law outcome is more likely than not. Users have only so much time and bandwidth to figure out and resolve complexity and choice. The Agents who provide the best user experience will enjoy the greatest network effects.
Finally, let us keep in mind the following:
Agents cannot exist only in the Web 3.0 world of dApps and blockchains. They also need to be compatible with Web 2.0 sites and provide a laddered approach to adoption that is more inclusive.
For mainstream adoption, Agents need to auto-provision decentralized resources for users on the back-end and abstract technical complexity
Successful Agents need a killer application or app protocol to bootstrap and catalyze demand. This is the “elephant in the room”.
An agent should exist in light-weight and embedded forms so that user acquisition can be distributed within the ecosystem and there is little dependency on Install Ads, Google Ad Words, or dApp Stores.