Tangled, the AT Protocol code forge, ships new Svelte UI and Rust backend
Tangled, a code forge built on the AT Protocol, has announced a major release on its blog. It describes itself as "the first truly federated code forge": you can host code on your own servers and still collaborate with others. The pitch starts from a complaint about centralised forges. Relying on someone else for uptime, features and good stewardship of your code "hasn't played out well", and the post notes that email, an open protocol alongside Git, has stood the test of time, though at the cost of user experience. Tangled says it wants the longevity of an open protocol with the convenience and polish of a proper forge.
Self-hosting is modular. You can run just the parts you want, such as Git hosting or CI runners, or everything, including the API server and UI, and still talk to everyone else. Because it is built on the AT Protocol, people can write extensions, subscribe to the firehose, or build custom knots (one example runs on Cloudflare Workers and uses Cloudflare's Artifacts product for git storage) or custom spindles such as mitchellh.com/tack. Tangled also says it is "incredibly agent friendly" and that agents have made building hyper-personalised software trivial.
The release has four main parts. First, a new look. The UI was redone in Svelte on top of the new architecture, and the font Inter was swapped for Timeless Sans. The post says things "should now be quicker, visually consistent and prettier".
Second, a new architecture. Until now the web UI and backend were a single Go monolith called the appview, which handled AT Protocol indexing, caching, off-protocol data and UI rendering with html/template and htmx. It ran on a single SQLite database on one medium-sized server in Sweden. That worked well if you were roughly 50 to 100 ms from Sweden, but the post says most users are not. The fix is a standalone Svelte frontend deployed at the edge, fed by a new diskless, entirely in-memory indexer written in Rust, called bobbin. Bobbins are deployed globally in "over 11+ regions", as the post words it. Bobbin is purely read-only and handles only AT Protocol data; the remaining functionality moves to a new set of supporting services.
Third, a new data model and repo-owned data. A new set of lexicons lives under org.tangled., replacing the old sh.tangled. records. Knot2 is the second implementation of the knot server, rewritten in Rust, with a fully custom Git server and an SSH server bundled in the same binary. With knot2, issues, pull requests, comments, reactions and labels are now stored on the knot next to the code as collaborative objects (COBs), each a chain of Git objects in the repo itself. Collaborators, knot members and the blocklist are stored the same way. Knots now behave much like a PDS: they hold signed records with full history, synced over the standard AT Protocol firehose. The reasoning is that a project's issues and pull requests belong with its code wherever it is hosted, which gives maximum portability. To stop a knot from putting words in a user's mouth, every create or edit of a record on a knot also makes the web app write an org.tangled.graph.attestation record to the user's own PDS, pointing at that exact version of the record and the COB change behind it. The post calls this two-way verification. Self-hosters must upgrade their knots to v1.20.0 by following the upgrade guide.
Fourth, Organization accounts. An Organization is a real AT Protocol account with its own DID and handle, hosted on a Tranquil PDS instance. These are passwordless, delegated accounts. Creating one from the New Organization page gives you
The pull request flow was also overhauled. Everyone, whether they use Jujutsu or plain Git, can now submit and review stacked PRs. Git users can interdiff between versions (previously called rounds); Jujutsu users can also interdiff between individual changes.
The launch is staggered over the next few weeks. Up next are private repos, a CLI, SDKs for different languages and skills for agents. The post closes with the line "Your code, your network."
Key facts
- Tangled, a code forge on the AT Protocol, replaced its single Go monolith (the appview, running on one SQLite database on one server in Sweden) with a standalone Svelte frontend at the edge plus a Rust indexer called bobbin deployed in over 11+ regions.
- Knot2, a Rust rewrite of the knot server, stores issues, pull requests, comments, reactions and labels in the repo itself as collaborative objects (chains of Git objects), with attestation records written to the user's own PDS for two-way verification.
- Organization accounts arrive as real AT Protocol accounts with their own DID and handle (
.tngl.sh), hosted on a Tranquil PDS instance; owners can invite members. - The PR flow now supports stacked PRs for both Jujutsu and vanilla Git users, with interdiff between versions for Git and between individual changes for Jujutsu.
- Self-hosters must upgrade knots to v1.20.0; private repos, a CLI, SDKs and agent skills are promised over the next few weeks.
Why it matters
Tangled is pitching a different shape for a code forge: instead of one company hosting your repos, issues and reviews, the pieces can live on servers you choose and still interoperate through the AT Protocol. The notable design step in this release is moving issues, pull requests and comments out of a central database and into the repo itself, as chains of Git objects. The post argues that a project's issues and pull requests are as much a part of it as its code, so they should travel with it, which it says gives maximum portability. The rewrite of the old Go monolith into a Svelte edge frontend, a Rust in-memory indexer and a Rust knot server is also a response to a practical problem: the single server in Sweden suited users within roughly 50 to 100 ms, and most users are not.
Who it affects
Developers who want to host their own code or CI while still collaborating with others are the target audience. Self-hosters running knots are affected directly, since they must upgrade to v1.20.0. Teams that want shared ownership get Organization accounts. Users of Jujutsu or plain Git both get the reworked stacked-PR flow. People who have been using a regular account as a stand-in organization are affected too: a migration path is still being worked on.
How to use it
Everyday users see the new UI on tangled.org. To create an Organization, use the New Organization page; you get
How solid is it
This is Tangled's own launch post, so every claim is first-party. The post gives no benchmark or measured latency figures for the new architecture; the only performance statement is that things "should now be quicker". It gives no user numbers or repository counts. The bobbin deployment is described as "over 11+ regions" in the post's own wording. The post does not name its individual authors, and one sentence in the introduction is garbled in the source, so what Tangled aims to become is not stated. The description of the architecture and data model is detailed and specific, and the staggered launch means several announced features are not yet available.
Risks and caveats
Self-hosters are forced to upgrade knots to v1.20.0, and the move from sh.tangled.* to org.tangled.* lexicons is a data model change. Organization accounts are new, and regular accounts used as stand-in orgs have no migration yet. Private repos are still listed as upcoming, with only 'the next few weeks' as a timescale for them and for the CLI, SDKs and agent skills. The claim to be the first truly federated code forge, and the claims of better speed and looks, are Tangled's own and are not backed by comparisons with other forges in the post. Storing issues and pull requests on the knot means a knot could in principle write words for a user; the post's answer is the attestation record written to the user's own PDS.
“Your code, your network.”
— Tangled launch post