Braid extends HTTP into a state synchronization protocol for real-time, local-first web apps. Learn what braid.org is, how it works, and how it differs from…
HTTP, as originally designed, is a state-transfer protocol: a client asks for a resource, the server sends back a snapshot, and that's the end of the interaction until the client asks again. This model works well for static documents but breaks down for the collaborative, real-time applications that define much of today's web - shared documents, live dashboards, multiplayer tools, chat apps - all of which need a resource's state to stay synchronized across many clients as it changes.
In practice, most teams solve this by bolting a separate real-time layer onto HTTP: WebSockets, long polling, or a proprietary backend service that handles sync, conflict resolution, and offline support outside the normal request/response model. Braid's premise is that this pattern is repeated so often, and solved so inconsistently, that it belongs in the protocol layer itself, the same way HTTP eventually absorbed caching, compression, and range requests as first-class features rather than leaving every application to reinvent them.
Braid-HTTP, the core specification developed as an IETF Internet-Draft under Michael Toomim's leadership, adds four building blocks to HTTP. Versioning lets resources be referenced at specific points in time rather than only as their current snapshot. Subscriptions extend the familiar GET request so a client can ask to be pushed updates as a resource changes, instead of polling. Patches extend HTTP's existing Range Request mechanism so that updates can be sent as small, targeted diffs instead of full resource re-transfers. And merge-types let a resource declare, in a standard way, how the server or peers should reconcile simultaneous conflicting writes - for instance by applying a CRDT or an operational transform.
Together, these four extensions are designed to let any HTTP resource become synchronizable, supporting concurrent multi-writer edits, offline operation, and peer-to-peer replication, while staying backwards-compatible with existing HTTP infrastructure such as browsers, caches, and proxies. The project also maintains a growing set of reference implementations and demo applications - including Braid-Text, Braidfs, a Braid-Chrome extension, and apps like Quiet and Ethersync - that put these ideas into practice and serve as proof that the approach works outside of pure specification documents.
Braid is not a company and has no commercial owner. It is organized as an open working group that meets regularly (historically biweekly via video call), discusses on public mailing lists and GitHub, and advances its specification through the IETF's standards process, which relies on public drafts and rough consensus rather than a single vendor's product roadmap. This makes Braid closer in spirit to protocols like WebDAV or Server-Sent Events than to a commercial developer platform.
For teams evaluating Braid, the practical implication is that there's no vendor to buy from, no SLA, and no pricing - only an open specification, a set of reference implementations, and a community to engage with. That's an advantage for teams that want to avoid lock-in and are comfortable contributing to or adapting early-stage tooling, and a limitation for teams that need a polished, supported, drop-in product today. Because Braid is still an evolving Internet-Draft rather than a ratified web standard, adopting it in production requires real engineering investment and a willingness to track an actively changing specification.
Braid is an open protocol and research project that extends HTTP into a state synchronization protocol, adding versioning, subscriptions, patches, and merge-types so web resources can stay synchronized in real time across clients, servers, and peers.
No. Braid is a non-commercial, open specification and set of reference implementations maintained by a volunteer community, not a company or a paid product.
Braid is led by Michael Toomim and developed collaboratively through an open working group and the IETF standards process.
Plain HTTP transfers a snapshot of a resource on request; Braid adds versioning, real-time subscriptions, incremental patches, and standardized conflict resolution so resources can stay continuously synchronized.
No. This entry covers the braid.org state-synchronization protocol; 'Braid' has also been used as a name for an unrelated, now-defunct Git submodule tool and for other unaffiliated software projects.
Braid-HTTP is the core Braid specification formalized as an IETF Internet-Draft that defines how versioning, subscriptions, patches, and merge-types extend the HTTP protocol.
Reference implementations and demo apps exist and some production deployments have been reported, but Braid remains an evolving draft rather than a finalized standard, so production use requires engineering investment and tolerance for change.
Demonstration and community applications include Peery View, the peer-to-peer chat app Quiet, the collaborative editor Ethersync, and Braidmail, alongside libraries like Braid-Text and Braidfs.