Decentralizing Online Chat
The need to connect and freely communicate with others lies at the core of being human. And it is quite natural to expect that our communication with one another is not susceptible to eavesdropping, censoring, or at the mercy of centralized gatekeepers. However, numerous examples continue to show us that many of today’s internet services and applications are built in an overly centralized way.
Luckily, there are more than a handful of projects aimed at creating alternative paths forward. Broadly speaking these initiatives are creating distributed versions of today’s historically centralized systems (e.g.: electronic money, data sharing, etc.). And while there are far more questions than answers, we are certain these new tools will allow us to create completely new types of applications that better serve our desire to connect freely.
As we actively work on Nomad, a distributed real-time message broker (imagine a distributed Kafka, built on libp2p and IPFS), we’re also working at the application layer, creating provocations of what might be built with decentralized infrastructure, implemented as working code. One question that we’re particularly interested in is: What happens as we pull apart historically monolithic systems, and start distributing their functions?
When facing something this broad, you need to start small.
So we chose to explore it by building a distributed, browser-only, real-time chat application. This is of interest because what the centralized versions do is so basic, it’s almost invisible. But you soon realize that the task of taking things apart (function by function) and putting them back together, in the most distributed way possible, is no small task. The once invisible becomes an obvious challenge.
A very clear role played by centralized chat providers (let’s use Twitter as an example) is one of granting, and validating a user’s identity. This includes ensuring unique usernames, and authenticating control of that name via a password login. With a service like Twitter, unique usernames, proof of identity (via password), and messaging are all wrapped into one service.
A decentralized service breaks these functions into modules. A user’s unique identity can be self-generated: a pair of public and private cryptographic keys. A separate service can then map a user’s public key to a human friendly name, another can help a user keep track of private keys, and a third can actually send and store chat messages. This modularity feels more complex at the moment, but it offers a level of service scalability and reuse that we just don’t have today except at the deepest layers of the internet technology stack (TCP/IP, DNS, etc.).
By creating and using the tools that are shaping tomorrow’s infrastructure, we will continue to explore this emerging landscape with a healthy mix of imagination, intuition, design, and engineering. We will also continue work with an intent to connect with others shaping the space. Openness is the spirit in which we work.
We’re currently focused on stabilizing the in-browser version of Nomad that powers the chat application mentioned above. It is rapidly advancing alpha software (there be dragons) and relies heavily on the Javascript implementation of both Nomad and IPFS. If you are interested in contributing to either, your help is welcome! You can dive in right now by participating in Nomad or the JS-IPFS community. Welcome aboard!
