North star: the read-write web
The web began as a medium you could write as well as read. XTXP aims to finish that job: any document on the web, live, editable by many people at once, forkable into sessions and mergeable, in an ordinary browser.
The goal: XTXP in the browser
Section titled “The goal: XTXP in the browser”XTXP as a first-class web standard, built into the browser. A browser that speaks XTXP runs its own muppet, opens xtxp:// links, and treats any page as a live document that many people can edit, fork into sessions and merge, with no JavaScript on the page and no app to install. Collaboration becomes part of the web itself, the way links and forms are.
Compatible everywhere
Section titled “Compatible everywhere”Backwards compatibility is part of the standard, so XTXP works in every browser, not only those that speak it:
| Browser | How it takes part |
|---|---|
| Speaks XTXP | Runs its own muppet natively. The goal. |
| Runs JavaScript | A Wasm muppet polyfills the same engine into the page. |
| No JavaScript | Plain forms, links and HTTP caching, with a server-side muppet doing the CRDT work on the browser’s behalf. A full participant, not a fallback. |
Native apps (Inkscape) and mobile clients (through an XMPP bridge) are peers on the same mesh. Every client may get more or less on screen, but none gets a different document.
The test
Section titled “The test”Every design decision gets checked against one question:
Does this still work with no JS?
Some consequences:
- Edits from a plain browser arrive as form POSTs, followed by a redirect and a GET, so refresh and the back button behave.
- Passive viewing uses
<meta http-equiv="refresh">with ETag /If-None-Match, so an unchanged document costs a304 Not Modified. - Onion skin, redline and session previews are rendered on the server as SVG layers. To a browser they are just images and markup.
- The hand-off to a native client is a plain link to
xtxp://, not a script that probes for a protocol handler.
Tim Berners-Lee’s read-write web
Section titled “Tim Berners-Lee’s read-write web”The first browser, WorldWideWeb (1990), was also an editor. It could edit only local files, because HTTP PUT wasn’t implemented yet, and as the web spread, reading won and writing became the job of separate tools and, later, of each site’s own JavaScript. The read-write web is the idea XTXP comes back to.
Many people’s work since
Section titled “Many people’s work since”Many people have chased that idea since: wikis, WebDAV, shared editors and more. Around 2005, David Campey wrote an experimental Jabber proposal for streaming document updates over XMPP, aiming to replace HTTP, in conversation with Jabber folk such as Peter Saint-Andre (stpeter).
Local-first software
Section titled “Local-first software”Ink & Switch’s work on local-first software argued that collaborative apps should keep working offline, keep data on the user’s own devices, and sync through CRDTs rather than a central server. XTXP’s peers, sessions and pure engine follow that line (prior art).
“Surprise, it’s server rendering”
Section titled ““Surprise, it’s server rendering””Schalk Venter’s talk at PyCon ZA, Surprise, it’s server rendering, stacked up the browser features that let server-rendered sites feel live without a JavaScript framework: CSS View Transitions, the Popover API, Speculation Rules and declarative partial updates. It started a debate: could we, and should we, stream a site’s content into the browser without JavaScript polyfills at all?
That debate led to XTXP. This time HTTP stays: it’s the no-JS edge every browser already speaks, one of the layers that make XTXP compatible everywhere, alongside a lean streaming protocol for documents over WebSocket, with XMPP kept as a bridge for the mobile and chat clients it serves well.