Why We’re Exploring Decentralized Chat

A guide to making a service that allows us to connect freely

May 3, 2017
Reading Time
3 minutes

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 and censorship, or at the mercy of centralized gatekeepers. Sadly, we’re constantly seeing evidence that an overly centralized infrastructure is guaranteed to have critical outages and choke points. Now is the time to explore and start implementing alternative architectures.

Luckily, there are more than a handful of projects aimed at building alternative paths forward. Broadly speaking, these initiatives are creating distributed versions of today’s historically centralized systems (like Bitcoin, Ethereum, IPFS, etc.). And while there are far more questions than answers, we are certain these new tools will allow us to create completely new applications that better serve our desire to connect freely.

As the IDEO CoLab actively works 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: What happens when we pull apart historically monolithic systems, and start distributing their functions?

When facing a question this broad, you need to start small. So we chose to explore it by building a distributed, browser-only, real-time chat application. Why? Because when you pull once-monolithic applications into individual pieces, you realize that the task of taking things apart function by function and putting them back together in the most distributed way possible is quite a challenge. But the experience gained from hands-on interaction with these unique challenges allows us to build our understanding of the space, and glean insights for emerging design principles.

Holy cow! Chatting across a decentralized chat app!

Centralized chat providers grant and validate a user’s identity. That means they ensure unique usernames and authenticate 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. For example, any user’s unique identity can be easily self-generated through the use of public key cryptography. A separate service can then map a user’s public key to a human-friendly name, while 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.). Best of all, the new services that emerge from this budding ecology will reflect the values inherent in our new architectures.

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 the intent to connect with others shaping the space.

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!

Adapted from IDEO CoLab’s post on decentralizing chat here.