Tangled une Git e AT Protocol em uma forge de código federada

O Tangled tenta juntar a durabilidade de um protocolo aberto com o acabamento de uma forge tradicional. A proposta é federar: você hospeda só o que quiser (Git, CI runners ou tudo, incluindo API server e UI) e continua conversando com o resto da rede. Por ser construído sobre o AT Protocol, dá para criar extensões, assinar o firehose ou escrever knots customizados, como um que roda em Cloudflare Workers e usa o Artifacts para armazenamento Git.

A mudança técnica central é a arquitetura. O antigo appview era um monolito em Go, com html/template + htmx e um único SQLite num servidor na Suécia, o que penalizava quem estava longe. Agora há um frontend em Svelte no edge, alimentado pelo bobbin, indexer em Rust, sem disco, totalmente em memória, somente leitura e implantado em mais de 11 regiões. Os dados fora do AT Protocol foram delegados a novos serviços de apoio.

O modelo de dados também mudou: novos lexicons em org.tangled.*, no lugar de sh.tangled.*. O knot2, reescrito em Rust, traz um servidor Git próprio e um servidor SSH no mesmo binário. Issues, pull requests, comentários, reações e labels passam a viver no knot como COBs (cadeias de objetos Git no próprio repositório). Para evitar que o knot "fale por você", cada criação ou edição gera um registro org.tangled.graph.attestation no seu PDS. Self-hosters precisam migrar para o knot v1.20.0. Também chegam contas de organização (com DID e handle próprios, em Tranquil PDS) e stacked PRs para quem usa Git puro ou Jujutsu, com interdiff entre versões.

Para quem opera a própria infraestrutura de código, o ponto prático é a portabilidade: issues e PRs viajam com o repositório, não ficam presos a uma plataforma. Para quem desenvolve, o stacked PR com Git puro e as extensões via firehose reduzem a dependência de um fornecedor. A migração do knot para a v1.20.0 é a tarefa imediata de quem já hospeda por conta própria.