Chatterbox: Federated Chat that Doesn't Suck

Have you used Matrix? Do you like it? Trick question, of course you don’t. It seems like nobody likes Matrix, at least not once they’re familiar with its… quirks. It’s frustratingly overengineered, difficult to work with, full of bugs, and its insistence on E2EE makes it hard for nontechnical users to comprehend.

For the past several months, I’ve been working on a better solution for federated chat. Chatterbox is a new protocol that, I hope, will make federated chatrooms actually nice to use. It’s still in development; currently, I don’t have any working software to show, just the plan and the API.

But, in case it sounds interesting to you, here’s some of its key features:

  • User-friendly defaults: The default experience uses ordinary password login and does not ask you to save a recovery key or anything else complicated. There will be a default flagship instance at cbox.cx that is only used to host user accounts that federate to other servers.

  • Client-to-server federation: When you connect to an instance other than your home instance, your client connects directly to it, and your home instance doesn’t know.

  • Optional public key auth: Power users can choose to identify themselves with a self-managed Ed25519 keypair. The default password login lets the server manage your private key, but you can switch to a personal key any time.

  • Credible exit: Users can move between instances, switch public keys, and revoke keys. If you manage your own key, you can move servers even after your home server goes down or bans you.

  • No E2EE by default: Depending on your perspective this may or may not be a good thing. But in my experience Matrix E2EE is more trouble than it’s worth for 90% of use cases, and there are plenty of uses that don’t need any more encryption than HTTPS. Future versions may add optional E2EE DMs via MLS.

  • Bot API: Extra features can be added via bot users, which have access to additional API features like annotating existing messages and receiving private /-commands. Link previews, for example, are implemented as a bot, but, unlike Matrix’s maubot, the preview appears an an annotation on the message, not a separate message.

  • Optional replication: Servers and rooms exist on one instance by default (avoiding the Matrix issue of overloading your server by joining a large room), but can optionally be replicated across multiple instances, for high availability or as part of a migration process.

  • Simple, easy-to-implement protocol: The protocol is a single WebSocket connection with Protobuf messages, using a simple custom RPC system. The entire API is defined in one .proto file. (I considered switching to a REST API but decided to simplify the WebSocket API instead.)

Interested? I’ll hopefully have more information soon, but for now you can read the work-in-progress chatterbox.proto that defines the entire protocol. Let me know what you think on Mastodon; I’ll post updates there with the tag #Chatterbox.