Will the Agent be the Browser Equivalent for the Decentralized Internet?

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 Core Capabilities 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.

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:

  1. 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.
  2. For mainstream adoption, Agents need to auto-provision decentralized resources for users on the back-end and abstract technical complexity.
  3. Successful Agents need a killer application or app protocol to bootstrap and catalyze demand. This is the “elephant in the room”.
  4. 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.

In the next post, I will discuss how an Agent can actually help a user get jobs done by interacting or engaging with other dApps and Services in the ecosystem.

Anandan (AJ)