All posts
Synapse TeamCore maintainersOctober 22, 20266 min read

Why we built Synapse in the open

We did not start out wanting to publish a protocol. We started out wanting to fix the thing that annoyed us most about the tools we already used.

The annoying part

Most team chat is a black box with a REST layer bolted on. You can post a message, but you cannot see how delivery actually works, so anything slightly outside the supported path becomes guesswork.

Every integration we wrote carried that guesswork forward. When the vendor changed behaviour without telling us, we found out from users rather than from a diff.

What openness changed

Publishing the wire format moved debugging from inference to reading. A bug report now starts with a version number and a trace, not a description of symptoms.

The second effect was harder to predict: people submitted fixes for platforms we had not planned to support, because they could trace a change from the client through the protocol to the server.

The cost

Open code is a liability you accept on purpose. Threat modelling happens in public, and a careless change is visible before it is reviewed.

We pay for that with a slower merge policy and an explicit rule that wire-format changes go through a written RFC. It is a fair trade, provided the RFCs stay short enough that people read them.

Want to try what this post describes?

Install a client, or run a node of your own — both are MIT licensed.

Download Synapse
Next postSelf-hosting your own social nodeOne container, one Postgres database, one TLS certificate — what running Synapse for a community actually takes.

Built in public, written up as we go

New posts land with each release. Subscribe through the repository releases page.