TLDR; Let’s make a framework for protocols that introduces the notion of ‘user’ and handles federation and user device connectivity.

If I were to become an all powerful god who could dictate all and any decisions made, we would have instant messaging. Not Signal, WhatsApp, Facebook Messenger, iMessage or even Matrix, but only instant messaging. When you would want someone’s contact, you would ask only for their address. And to buy them a coffee, you wouldn’t be asking if they have Bitcoin or PayPal or Revolut or N26, but you would only ask for their address. And when you wanted to share some files with them, you could invite them just by their address.

It seems that whatever this address points to should be an omni-functional piece of software that would be so complex that it could only be developed by armies of developers. I believe it may not be so, and you are here to prove me wrong.

How would it all work?

A digital representative would be a piece of software that would represent an individual or organization in the digital world. Think of email server but for any service that we could standardize. Your DRS (digital representative server) would host your account with an address where you would be reachable via any of the services you would have enabled.

When Bob would add his friend Ana (via her address), Bob’s DRS would ask Ana’s DRS for a list of services that she uses. The reply would say something like “Oh hey I am Ana’s DRS, she would like you to know that she is reachable via email and file sharing, but does not have instant messaging set-up.”.

Bob’s DRS could then contact Ana’s individual services via their own protocols. Protocols are then free to do their own magic, with alleviated pain of doing own authentication and peer discovery. Services could include:

  • email (asynchronous, large messages)
  • instant messaging (synchronous, small messages)
  • file sharing (similar to Dropbox, OneDrive, Google Drive)
  • authentication (automated flow instead of email conformations and such)
  • personal information lookup (instead of me filling out forms, ask my DRS!)
  • financial transactions (just the negotiation, actual transactions would be hard to pull off)

(I intend to write more about what each of them.)

These services already exist, we know how they should work, we would only have to reshape them, so they would fit together in a larger, confluent structure.

Digital representative server

DRS would have two core responsibilities: managing different user devices and managing connections to other representatives, i.e. other users.

For the devices, we need authentication, secure communication channel and downstream messages (push notifications). This could be achieved by issuing a client certificate that would then be used to open a TLS connection(s). It would also be useful if client protocol would have a ‘user dialog’ interface, where service could ask user a question or notify them about an event. DRS would then be responsible for reaching the user and returning the feedback, regardless of the device are they currently using.

On the other end, managing relationships with other representatives must support semi-automatic registration of new contacts (like described above), where the servers communicate with each other to present which services each of them wants to use. This would probably include simple user interaction, like ‘do you know this person?’ and ‘how much of your information do you want to expose’. After registration, federation protocol should provide authenticated and encrypted channel for services to use, so federation does not have to be part of every other service.

In effect, such system would start to shape an ecosystem of services. Apple, Google and Microsoft are already doing this, and they are quite successful. But to be sustainable, we need an open-standard solution which is not just a bunch of protocols glued together. We need a structured, designed internet.

But why?

Currently, the internet is ruled by private companies and a few communities making apps: self-contained well-designed cloud-connected well-funded and highly-profitable software. Competition on the market is fierce (at least for the most prominent services) and the battles are held on the grounds of UI design and ease of use.

New decentralized protocols like Matrix that are just entering such market, have to compete with organizations of thousands of employees. After including downsides of decentralized protocols, their only hope of long-term success is tech-geeks convincing the masses to switch to a new message app.

Digital representative would give a competitive advantage becuase it would alleviate a large portion of the pain when designing distributed protocols. Also it would provide interactivity between services, which could increase ease-of-use and become appealing to a common user.

Now, why don’t we like companies making the apps? Well, when a company provides a service, it does that companies do: optimize for its profits (not exactly, but prominently). Usually, this goal is aligned with goals of the users, but this is not a general rule. When large corporations start to look for new ways to increase profits, immoral or illegal tactics start to evolve. We all know what this leads to:

  • Lack of control over stored user data. This is getting better GDPR, but privacy is still a major concern with current state of the internet.
  • Dark patterns - interface design which serves the company and not the user.
  • No federation - users cannot interact with users of the same service by other providers (e.g. you cannot send messages from WhatsApp to Signal)
  • Vendor lock-in: users have difficult time transitioning to other service providers. Even though established service protocols do not ensure that migrations between providers would be easier, they provide standard message formats and opportunity for open-source projects which help with the transition. Currently, most service providers do not even provide easy access to the data (in whatever format it is).

If we introduce an open standard for all these services, probably new client & server implementations will spring up, serving different needs (personal, enterprise, specialized). Also, it would be easier to embed a service into other products. A few years ago, I had to add simple instant messaging to a real estate marketplace, but given the client’s budget, the result was barely functional. We would have been much better off just embedding an IM protocol into the product.

Why hasn’t it been done?

For starters, it is not a small effort to develop all the protocols, and it is hard to organize such an enormous effort without immediate return of investment. There are also no obvious gains for the investor who would the risk in exchange for long term returns and profits.

Second of all, the Messenger and WhatsApp and Signal are not all exactly the same. I made it sound like they are all the same, but in truth it may be hard to draw the boundaries between features to include and features to discard. If we make the protocols too broad, implementations will struggle to support all the features, and if we make them too narrow, they may not have the functionality to draw the attention.

And at last, we would need a critical mass of users before such approach would become better than current solution. At first, this ecosystem would be almost useless due to lack of users to interact with. For it to succeed, there would have to be enough people using it even though it provides worse experience than competing systems.

Motivation

This has been on my mind for some time. I am bothered by large tech companies competing for market shares of the same service. This drives innovation, yes, but also motivates mechanisms to lock users to a service. It all seems counter-productive. And I am frustrated, because as a software developer I see no technical barriers between internet we have and the digital nirvana.