Tangled - plataforma de colaboração Git baseada em atproto

 (blog.tangled.org)
3 pontos por GN⁺ 2025-10-12 | 2 comentários | Compartilhar no WhatsApp
  • Tangled é uma plataforma de colaboração Git com recursos sociais baseada no AT Protocol, projetada para que desenvolvedores mantenham a propriedade total sobre seu código enquanto a comunidade open source pode se autogerir
  • Adota uma estrutura distribuída de colaboração de código que combina as vantagens do modelo federado centrado em ActivityPub (Forgejo) com o modelo totalmente P2P do Radicle
  • O conceito central, "Knot", é um servidor Git leve e headless que oferece suporte tanto a self-hosting individual quanto a ambientes multitenant em nível de comunidade
  • O App View (tangled.sh) fornece uma visão unificada dos repositórios em toda a rede, permitindo navegar, clonar e contribuir com fluidez em repositórios hospedados em diferentes Knots
  • Atualmente em beta, tem como princípios centrais propriedade dos dados, baixa barreira de entrada e preservação da experiência do usuário, mirando no futuro a construção de um ecossistema Git distribuído totalmente aberto

Visão geral do Tangled

  • Tangled é uma nova plataforma que oferece um ambiente de colaboração Git com interações sociais, no qual desenvolvedores mantêm a propriedade de seu código e de sua identidade
  • Baseado no AT Protocol, aplica à colaboração em Git uma arquitetura de aplicativos sociais descentralizados
  • O objetivo é devolver à colaboração de código um caráter aberto e prazeroso

Modelo distribuído e AT Protocol

  • Os modelos existentes de colaboração distribuída de código incluem abordagens como:
    • Forgejo (ActivityPub): colaboração por meio de federação entre servidores
    • Radicle: estrutura P2P (peer-to-peer) completa
  • O Tangled combina os pontos fortes dos dois modelos e adota o atproto, que permite gestão centralizada de identidade
  • Com isso, os usuários podem manter uma estrutura consistente de ID e autenticação mesmo dentro de uma rede distribuída

Estrutura do Knot

  • Knot é o componente central do Tangled, um servidor leve que permite ao usuário hospedar diretamente repositórios Git
    • Oferece suporte tanto a configurações de tenant único quanto multitenant
    • Também pode ser hospedado pelo próprio usuário em equipamentos pequenos, como um Raspberry Pi
  • O Tangled oferece, por padrão, um serviço gerenciado de Knot gratuito
  • Graças a essa estrutura, forma-se uma rede Git distribuída em que servidores pessoais e servidores de comunidade se conectam de maneira natural

App View e rede unificada

  • O App View oferecido em tangled.sh funciona como uma visão unificada dos repositórios de toda a rede
  • Mesmo que um repositório esteja em outro Knot, o usuário pode facilmente clonar (clone) e contribuir (contribute)
  • Esse design preserva o workflow tradicional do Git, ao mesmo tempo em que remove as barreiras do ambiente distribuído

Princípios de desenvolvimento

  • Para orientar o desenvolvimento, a equipe do Tangled definiu os seguintes três princípios
    • 1. Propriedade dos dados — todo usuário possui diretamente o código e os metadados que criou
    • 2. Baixa barreira de entrada — estrutura e interface simples para que qualquer pessoa possa participar com facilidade
    • 3. Consistência da experiência do usuário — garantir um UX no nível de serviços centralizados, apesar da estrutura distribuída
  • Esses princípios se refletem em todas as escolhas técnicas do Tangled e no design de UI/UX

Acesso e comunidade

  • No início, operava com acesso baseado em convite (invite-only), e os desenvolvedores podiam participar pelo canal IRC #tangled (libera.chat)
  • Atualmente, o login está aberto ao público, e qualquer pessoa pode usar em tangled.sh/login
  • O Tangled ainda está em estágio inicial, mas segue crescendo enquanto valida seus recursos por meio de uso interno (dogfooding)

Conclusão

  • Tangled é uma tentativa de expandir a colaboração em Git para uma experiência conectada como uma rede social
  • Vem ganhando atenção como um novo ecossistema de plataforma Git distribuída que combina autonomia, acessibilidade e uma cultura de desenvolvimento mais prazerosa

Leituras relacionadas

2 comentários

 
lamanus 2025-10-12

Como não há um contêiner oficial, a configuração inicial acaba sendo um pouco incômoda.
 
GN⁺ 2025-10-12
Comentários no Hacker News
  • Como cofundador do Tangled, tivemos recentemente um problema ao trocar a biblioteca de OAuth em que novos usuários não estavam sendo adicionados ao knot e ao spindle padrão (servidor interno de hospedagem Git e executor de CI); acabei de aplicar um patch de correção, então, se você sair e entrar novamente, deve conseguir criar repositórios normalmente; se tiver perguntas, fico feliz em responder
    • A primeira pergunta é se dá para alterar o handle ou excluir a conta no PDS do tngl.sh; a segunda é sobre quais recursos são necessários para criar e operar um AppView novo, por exemplo, se eu fizer um AppView baseado em PDS que simplesmente hospeda e serve uma pasta de site estático como no Cloudflare Pages, o operador do AppView teria que arcar sozinho com todo o custo de tráfego em grande escala? Quero entender como fica a carga operacional nessa arquitetura
    • O Tangled usou a expressão “social-enabled”, e imagino que isso tenha relação com o protocolo AT; queria saber se vocês planejam adicionar mais recursos sociais no futuro ou se isso significa apenas suporte ao protocolo AT
  • Acho este projeto realmente incrível; gosto da tentativa de desmontar a estrutura monopolista dos serviços tradicionais de code forge; o motivo de eu me interessar por essa área é que sinto que as code forges tentam resolver problemas demais de uma vez e acabam sendo ineficientes; a maioria junta repositório Git, visualizador web, ferramentas de colaboração, pipeline de CI/CD, gestão de trabalho e várias outras funções em um pacote só; mas acho que essas funções não precisam necessariamente vir acopladas; por exemplo, se não for necessário acesso direto ao repositório Git, dá para oferecer um visualizador web totalmente estático como https://pgit.pico.sh, ou ter a colaboração em um servidor separado para dividir patches, revisar e gerenciar localmente (https://pr.pico.sh); até subir apenas um repositório Git bare em uma VPS já basta, e isso é muito fácil; como o Git já é um sistema distribuído, acabar recentralizando tudo por causa de serviços auxiliares me parece um antipadrão
    • As pessoas dizem com frequência que “o Git já é distribuído”, mas, na prática, o conceito de distribuição aí é meio ambíguo; em vez de o próprio Git focar em distribuição, ele geralmente se baseia em protocolos mestre-escravo (como HTTP), então há uma tendência de a centralização reaparecer
    • Quando há vários serviços, surge a questão da confiança: você audita um único serviço que cobre 80% das necessidades, ou valida 10 serviços separados? Também não dá para ignorar a economia de escala da infraestrutura e as vantagens de integrar várias funções; por isso ainda há muita gente que prefere monólitos; isso acaba virando um trade-off de experiência do desenvolvedor
    • Configurar um remoto Git em uma VPS é realmente muito fácil; basta acesso por ssh e já funciona; na verdade, acho que a questão central é o "lock-in" (dependência da plataforma); por que GitHub e outros focam mais em lock-in do que em fornecer o serviço em si? Por trás disso há captação de recursos e modelo de negócios; o ciclo centralização → lock-in → receita aparece repetidamente em muitos serviços; se não houver um modelo em que o próprio serviço gere receita, parece inevitável cair nisso
    • Não é que a separação de funcionalidades seja tecnicamente impossível, mas há o problema da viabilidade econômica (cada função isolada não gera receita suficiente para se sustentar) e da usabilidade (as pessoas querem a conveniência de algo “com tudo incluído”); no open source acontece a mesma coisa: há muitos casos em que se ignora a viabilidade econômica, mas no fim a maioria desaparece quando o único mantenedor para; até os projetos open source mais bem-sucedidos geralmente dependem de patrocínio corporativo ou apoio de engenheiros
    • Não é que precise ser separado, mas, de fato, quando vem tudo integrado é muito mais conveniente
  • Fiquei sabendo recentemente do suporte a Jujutsu na JJ Con; dá para ver mais em https://blog.tangled.org/stacking
    • Este serviço realmente oferece suporte a stacked PRs; o GitHub não conseguiu fazer isso em décadas; se eu precisasse usar isso de forma privada dentro da empresa, é uma pena que não esteja claro como configurar uma instância do Tangled para que ela não fique conectada a redes externas
  • Acho que não dá mais para confiar no GitHub; mover ao menos a stack de OSS para o protocolo AT ou outra rede aberta me parece uma boa forma de se proteger dos riscos de grandes empresas, censura etc.; fico feliz em ver esse tipo de tentativa
    • Mas a maioria das pessoas não quer operar o próprio servidor; provavelmente só grandes organizações de OSS conseguiriam lidar com isso; e, fora e-mail, talvez nem desse para oferecer PRs direito
  • Fui uma das primeiras 100 pessoas a se registrar no Tangled; fiquei impressionado com o roadmap de revisão de PRs no estilo stacked patch e com a velocidade das melhorias; também senti uma energia muito positiva na comunidade; estou muito animado para ver como isso vai evoluir; se continuar avançando assim, acho que será possível oferecer uma experiência muito melhor, mais controle de base e sustentabilidade de longo prazo
  • Tenho muito interesse em formas mais distribuídas de colaboração com Git; qual vocês acham que é o maior obstáculo para esse modelo se espalhar? Operar servidores, gerenciar chaves privadas ou, no fim, efeito de rede? Gostaria de ouvir opiniões
    • A maior barreira é spam, conteúdo ilegal e problemas gerais de moderação; como um PDS pode estar em qualquer domínio e um único PDS pode atender usuários ilimitados, isso gera muitas experiências de quebra de confiança; o que fazer se as pessoas começarem a subir ebooks ou séries de TV em massa para repositórios Git? Ou se um projeto passar a sofrer ataques de spam por causa de questões políticas? O conceito de AppView é bom porque, como no Bluesky, uma equipe central de moderação pode aplicar uma política consistente; cada um pode publicar o que quiser, mas no frontend ainda é possível fazer curadoria seletiva; ainda assim, decisões centralizadas de moderação sempre geram controvérsia; esse é justamente um motivo para eu não querer assumir o peso e a responsabilidade de uma rede totalmente distribuída; a abertura do protocolo AT é uma vantagem em comparação com serviços como o Twitter, mas, em troca, ainda é preciso algum sistema concentrado para gestão cotidiana e concessão de autoridade; pessoalmente, hoje eu me pergunto se haveria voluntários para operar um radicle seed node “permissivo” (que permita uploads anônimos de Git)
    • O GitHub é grátis, e descentralização custa dinheiro
    • Estou muito satisfeito porque o Tangled permite usar Git de forma independente sem precisar operar servidor próprio; a maior desvantagem é que ainda é um serviço novo demais; ainda não tem reconhecimento popular, e muita gente nem sabe o que Bsky e PDS oferecem; seria bom ter mais funcionalidades e clients alternativos; ainda assim, acho que os primeiros usuários já estão tendo uma experiência boa o bastante; estou esperando o dia em que mais desenvolvedores vão conhecer isso
  • Fiquei feliz em ver suporte a pipeline de CI, mas é uma pena que o formato pareça com o GitHub Actions; não acho necessário usar YAML só para execução sequencial simples; um script bash já basta; YAML de pipeline faz sentido quando expressa dependências (DAG), não o fluxo do programa; o Buildkite é muito melhor nesse aspecto
  • Amanhã deve sair uma plataforma de negócios no-code chamada “Spaghetti” e um importante serviço de cofre para retenção de dados chamado “Lock-in”
  • Na empresa somos obrigados a usar uma org pública no GitHub; queria saber se daria para fazer o code review (CR) no Tangled e depois sincronizar com o GitHub, preservando a experiência de revisão com a ferramenta jj
  • Gostaria de saber se é possível adotar o Tangled para uso enterprise/privado; o fluxo de revisão com stacked diff parece combinar muito bem com trabalho corporativo
    • Existe essa possibilidade; está sendo discutida uma versão do Tangled totalmente airgapped e separada do AT; é um trabalho considerável, então não deve acontecer no curto prazo
    • No momento ainda não existe claramente uma solução empresarial separada; a discussão da issue relacionada pode ser vista em https://tangled.org/@tangled.org/core/issues/60