Milestones
decided in shape, draft in detail
M1-y-sweet and M2-y-sweet
Section titled “M1-y-sweet and M2-y-sweet”Before XTXP’s own host is built, M1 and M2 run on a stock, unmodified y-sweet (v0.9.1), used its own way (decision 25). The review of y-sweet recommends borrowing from it rather than extending it, and a self-hosted binary rather than Durable Objects; this spike tests how far it goes as it is.
- M1-y-sweet is CLI only. Xmesh peers on Yrs 0.28 sync through y-sweet over WebSocket, through the chaos proxy, and a person can watch and edit a drawing from two terminals. Its first part, with no network, is built: Xmesh, the hand-written vectors, the fuzzer, and a probe that replays every vector on y-sweet’s Yrs 0.19.2.
- M2-y-sweet adds the Inkscape fork and a browser with no JavaScript, served by a server-side muppet that is one more peer of the y-sweet document.
What y-sweet can’t express (key grants, refusing a session, the signed handshake) is recorded as a gap, not built. The spike answers whether y-sweet can hold “every connection edits in its own session” and how it behaves on a patchy network, and puts something in real people’s hands. Then the full M1 and M2 are decided on what was learnt.
M1 — Headless convergence
Section titled “M1 — Headless convergence”Three CLI peers (Rust, embedding Xmesh), one of them a late joiner that loads the full state, connect over WebSocket to a headless muppet hosting the session and replay the fuzzer’s vectors, with connections dropped on purpose to exercise reconnect sync. Each peer authenticates by key and binds its client ID. There is no UI. This proves convergence over a patchy network and the identity handshake before anyone draws anything.
Deliberately small (decision 22):
- One host binary, serving
@mainonly. Each peer edits in its own session, merged into@main. - Keys from files, and static grants signed by the owner.
- File storage: append, then compact.
- A chaos proxy between peers and host that drops, delays and duplicates frames.
- Revocation only as “stop merging that key’s session”.
- It follows M1-y-sweet and M2-y-sweet, if they show XTXP’s own host is needed.
M2 — Inkscape plus no-JS
Section titled “M2 — Inkscape plus no-JS”The Inkscape fork, linking Xmesh through its C interface, and a plain HTML browser served by a server-side muppet edit the same drawing. This is the first demo a person can see, and it tests the north star directly.
M3 — Inkscape plus Wasm
Section titled “M3 — Inkscape plus Wasm”A Wasm muppet in the browser joins as a full peer.
M4 — Inkscape plus Conversations
Section titled “M4 — Inkscape plus Conversations”Mobile and chat users take part through the XMPP bridge. What a stock Conversations user gets is open question 7.
Later: the muppet disco and live web branching
Section titled “Later: the muppet disco and live web branching”The muppet disco is a future milestone, deliberately deferred. Until then, a host serves its own sessions directly, which is all M2’s no-JS path needs. Where live web branching fits is open question 9.
Roadmap
Section titled “Roadmap”Deferred until the first milestones show they’re needed. Each one starts by checking what the Yrs toolchain already offers.
| Item | Why deferred | Until then |
|---|---|---|
| Ledger: a chronological patch log in cold storage, for unbounded, branchable undo | The Yjs ecosystem already persists documents by appending updates and compacting them | Append-and-compact storage per session |
| Keyframes: hot snapshots tuned for instant loading | Yrs can encode a whole document as one compact update | The full state as one update |
| History limits and garbage collection | Snapshots need Yrs’s garbage collection off, so deleted content is kept | Keep everything; measure growth |
| Native C++ Xmesh | Yrs is already native code; a rewrite would be about owning the engine, not speed | Xmesh on Yrs, through its C interface |
| Elixir / BEAM hosting | Worth considering at large scale, for the BEAM’s supervision and clustering | Rust hosting, one actor per session |
| XTXP in the browser: a first-class web standard, the north star | Needs working implementations and a spec mature enough to propose | The compatibility layers, which stay afterwards: no-JS browsers through a server-side muppet, and the Wasm polyfill (M3) |
| Signed hash chains of each client’s operations | Signing only at identity steps is enough to start | Authorship from client bindings |