A necessidade da federação das forjas

• A colaboração em open source parte da percepção de que uma combinação de protocolos distribuídos, que divide entre si a transferência de código e a comunicação, é mais desejável do que uma estrutura que depende fortemente de um único provedor
• A colaboração de código era originalmente feita com a combinação de git e e-mail; depois migrou para a combinação de git e o site do GitHub; o ForgeFed dá sequência a isso com a combinação de git e ActivityPub, e o Tangled com a combinação de git e o protocolo AT
• O Tangled federa eventos entre servidores git, chama cada servidor de knot e, mesmo com servidores diferentes, oferece suporte à colaboração em repositórios, a forks entre servidores e a pull requests para repositórios em outros servidores
• Para a Authenticated Transfer em torno do código, usa AT, lidando junto com issues, pull requests, timeline de eventos, follows e stars, além de também ser usado para convites de colaboradores e compartilhamento de chaves públicas SSH
• Embora se pareça com o fluxo de operar diretamente uma instância do cgit e enviar patches por e-mail, fica clara a direção de se afastar da monocultura do GitHub sem perder a dimensão social e a diversão da colaboração

---

A necessidade da federação das forjas

• Uma estrutura em que grande parte da colaboração em open source depende de um único provedor não é desejável, e isso se baseia na visão de que protocolos distribuídos duram mais do que sistemas centralizados
• A colaboração de código sempre usou dois protocolos em conjunto, com um responsável pela transferência de código e o outro pela comunicação
  • No início, o fluxo era a combinação de git e e-mail
  • Depois, mudou para a combinação de git e o site do GitHub
  • O ForgeFed considera a possibilidade da combinação de git e ActivityPub
  • O Tangled está sendo construído com a combinação de git e AT protocol
• O Tangled federa eventos entre servidores git e chama cada servidor de knot
  • É possível colaborar em repositórios independentemente do servidor em que estejam
  • Há suporte a forks entre servidores
  • Depois de fazer push para um repositório no seu próprio servidor, é possível abrir uma pull request para um repositório hospedado em um servidor totalmente diferente
• Essa abordagem se parece em vários aspectos com o fluxo de operar diretamente uma instância do cgit e enviar patches por e-mail

O papel do Tangled

• O Tangled usa AT para a Authenticated Transfer dos eventos em torno do código
  • É usado para transmitir eventos como issues e pull requests
  • Também lida com recursos sociais como timeline de eventos, follows e stars
  • vouches também devem ser adicionados em breve
• O AT também é usado para convites de colaboradores e compartilhamento de chaves públicas SSH, enquanto o restante continua usando o git existente
• O open source precisa sair da monocultura de plataformas como o GitHub, sem ao mesmo tempo perder a dimensão social e a diversão da colaboração de código
• tangled alpha
• docs
• source
• discord
• bluesky
• twitter (x)
• feed

[GN⁺]

Comentários do Hacker News

• Não sei o quanto isso realmente é melhor que o Mastodon

  • O ATproto não é uma estrutura em que vários servidores trocam mensagens entre si; na verdade, é mais próximo de RSS
    Existe uma camada de hospedagem independente do app, qualquer pessoa pode hospedar seus próprios dados, e por cima disso os apps agregam e exibem os dados de todos os hosts
    Por isso, o próprio conceito de defederation no estilo Mastodon não existe
    Se quiser entender melhor, vale ver https://overreacted.io/open-social/ e https://overreacted.io/a-social-filesystem/
  • O ATproto se federa de forma bem diferente do Mastodon, e aqui não existe o conceito de instance
    As contas são hospedadas em um PDS e os registros vão para lá, mas o que aparece no app é fornecido por um AppView que agrega dados de vários PDS
    Então, independentemente de em qual PDS você esteja, a experiência no app parece a de um serviço centralizado, e também é possível ter vários AppViews ou hospedar o seu próprio
  • O AppView é bem diferente do fediverse e depende de um shared relay em vez de federation explícita
    Vale pensar um pouco no custo de se ter, como agora, uma descoberta praticamente global, mas ainda assim é difícil tratar isso só como outro Mastodon
  • Não entendo por que é preciso necessariamente tomar partido ou escolher o lado certo
    Dá para simplesmente não se posicionar, ou seguir para o lado que você acredita que está certo
  • É um pouco exagerado, mas mesmo que seja isso, ainda parece muito melhor do que uma estrutura em que só existe relevância se você depender de GitHub e GitLab como agora

• Posso estar enviesado porque uso bastante coisas do lado do atprotocol, mas estou realmente muito satisfeito com o Tangled
  É o que mais chegou perto do substituto de GitHub que eu queria, e apesar de ter funcionalidades mais simples, foi meu principal serviço social/git para projetos pessoais open source no último ano
  Minha conta é https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf
  Gosto do fato de que o grafo social que eu já conhecia do Bluesky continua ali, então dá para ligar intuitivamente os commits, PRs e issues às pessoas por trás deles, e o login também é conveniente porque é o mesmo dos outros serviços atproto
  Recentemente também entrou suporte embutido a sites estáticos, então ficou ótimo para hospedar websites client-side ou um simples index.html direto do repo
  O Spindles funciona como sistema de build/actions, e mesmo eu não sendo fã de Nix, serviu muito bem para o que eu precisava
  A open API também é boa, então consegui usar padrões baseados em atproto para montar visualizações de informação com facilidade, criar bots e adicionar alguns recursos ao npmx.dev
  Você pode operar seu próprio knot (servidor git) e runner (Spindles), ou usar os hospedados, mas o ponto central é que os recursos sociais são separados, então mesmo que o servidor git esteja em outro lugar, as conversas de issue e PR continuam na camada social compartilhada
  Não é perfeito, e o rótulo alpha na navbar não está ali à toa, mas há uma boa chance de eu continuar usando para trabalho open source

  • Tenho um pouco de receio de que o atproto acabe sendo arrastado pela falta de tração do Bluesky
    Ainda não sei se isso é uma preocupação realmente válida

• O clima dos comentários está bem negativo, mas embora eu também desconfie de capital de VC, ainda acho que a concorrência nessa área deve ser incentivada
  Neste momento, começar algo assim por bootstrap parece muito difícil ou praticamente impossível, e sim, eles também acertaram o timing com aqueles posts criticando o GitHub que estavam no topo do HN ontem, mas mesmo assim quero torcer por esse tipo de tentativa
  Espero que consiga se firmar em uma escala relevante

  • Para mim, isso não é simples negativismo, e sim uma preocupação real
    Quando vi só o título fiquei animado, mas no momento em que soube que havia capital de VC envolvido, saiu da minha lista de consideração na hora
    Se eu vou colocar meu projeto de estimação, que nem dinheiro me dá, em uma plataforma, quero escolher um lugar em que a chance de um rug pull daqui a uns 5 anos seja baixa
    Projeto com VC precisa dar retorno ao investimento, então imagino que em algum momento o rug pull vai vir de um jeito ou de outro
    Por isso, hoje prefiro serviços em que eu seja cliente pagante, ou nos quais eu pague uma mensalidade como cooperado e tenha direito a voto nas decisões
  • Projeto com VC costuma acabar em rug pull, publicidade, invasão de privacidade ou empurrando recursos pagos de forma forçada
    Então, do ponto de vista do usuário, é importante saber disso de antemão
    Não gosto muito de serviços que vendem idealismo em excesso quando esse futuro bem provável já está logo ali
    Prefiro que cobrem pelo serviço, ou, se a proposta for realmente idealista, que comecem como non-profit, ou ao menos deixem o plano de monetização bem claro
  • Não entendo bem por que você considera bootstrap impossível
    Que é difícil, claro, mas especialmente se a ideia é federation, não deveria dar para construir isso com infraestrutura mais barata, e não com o mesmo custo ou até maior?

• Se você tem curiosidade sobre o modelo de dados do atproto, eu escrevi um texto introdutório em https://overreacted.io/a-social-filesystem/
  É meio longo, mas dá uma visão geral bem clara

  • Isso chega a ser modéstia excessiva
    Foi o melhor texto introdutório sobre ATProto que eu já vi
    Fiquei curioso se existe alguma tag ou lista reunindo esses textos em um só lugar

• Pelo que vejo, o necessário não é forge federation, e sim um git repo mais rico em si
  O Fossil já está quase 90% lá ao integrar tickets, fórum e wiki como parte do repositório, e quando você faz clone, também baixa tudo isso junto e pode ver offline
  Dá até para escrever respostas no avião e, se as permissões permitirem, sincronizar na hora ou depois, quando a conexão voltar
  Ainda assim, em vez de hardcodar tipos específicos de artefato no VCS, me parece melhor colocar apps dentro do repo e deixar que esses apps decidam quais artefatos permitem, quais regras seguem e quem pode fazer upload/download e quando
  O forge só precisaria aplicar essa política e renderizar para usuários web do jeito desejado
  Desse modo, migrar para outro forge acabaria sendo basicamente só fazer push do repo

  • Muito obrigado por isso
    Ultimamente eu vinha construindo coisas como sistemas de tickets ou agentes como flat files dentro de um git repo, e agora estou pensando que preciso expandir isso para a própria gestão do repo
    Parece que vai ficar muito bom

• O principal problema que eu sinto em uma federated solution é, no fim das contas, o cold start
  Se você entra em um servidor grande já existente, volta a abraçar exatamente o problema de centralização do qual queria escapar, só que em troca já ganha uma rede grande desde o começo
  Por outro lado, se você abre seu próprio servidor, a rede é zero, a descoberta é zero, o feed fica vazio, e ainda precisa convencer outros sites a federarem com você ou ao menos a não bloquearem você por ser um servidor de uma pessoa só
  Não sei se só eu sinto isso, ou se entendi federation errado
  Talvez isso seja simplesmente um problema mais específico do Mastodon

  • Acho que foi por isso que o Tangled escolheu ATproto em vez de ActivityPub
    Ele foi desenhado para que AppViews centrais agreguem os servidores individuais e ofereçam uma visão única e consistente, como uma rede centralizada
    Qualquer pessoa pode hospedar um AppView
  • Isso tem bem mais cara de Mastodon
    No atproto, cada servidor não funciona como uma zona meio isolada
    Para uma explicação pela ótica de sistemas distribuídos, https://atproto.com/articles/atproto-for-distsys-engineers explica muito bem
  • Eu diria que o ganho está em um meio-termo
    Se um servidor grande ficar suspeito por causa de moderação, política, conteúdo ou problemas técnicos, dá para sair com relativa facilidade e fortalecer ou migrar para outro servidor também razoavelmente grande
    Ou seja, dá para formar um refúgio com certa reputação e escala desde o início
    Já existem forges alternativos como GitLab, Codeberg, freedesktop, Fedora e Debian, então se a visibilidade e a descoberta do projeto forem preservadas, isso já seria um abrigo suficientemente seguro
  • Até agora eu sentia exatamente isso, então costumava manter distância de serviços federados
    Mas vendo este projeto alguns dias atrás, pensei que isso realmente pode dar certo
    Porque o público-alvo se sobrepõe bastante com pessoas acostumadas a self-hosting
    Não preciso que toda a minha rede esteja lá; se só esse subconjunto que de fato tem chance de aparecer ali estiver presente, já é útil o bastante
  • O atrativo aqui é que dá para self-host e também fazer migration entre grandes provedores
    O custo de um servidor de frontend deve ser bem baixo, então parece algo quase sustentável para sempre, enquanto os dados reais são fornecidos por outros hosts

• O fato de o Tangled ter apoio de VC me soa mais como pressão para crescer a qualquer custo do que como estabilidade
  Não vejo muito apelo nisso
  Mesmo que seja federado, se o desenvolvimento parar, quem vai corrigir bugs e fazer manutenção?

  • O Tangled está sendo desenvolvido totalmente em público em https://tangled.org/tangled.org/core, e a meta é permanent software
    Ou seja, tornar tudo completamente reproduzível e self-hostable com custo mínimo
    O capital de VC não é o objetivo, e sim um meio; para dois fundadores indianos na Europa, subsídios levavam de 4 a 12 meses ou mais para sair e eram, na prática, quase inviáveis
    VC foi o caminho mais rápido para montar a equipe, levantar a infraestrutura e acelerar o desenvolvimento, e eles também afirmam ter alinhado fortemente seus objetivos com os investidores, passando mais de 6 meses procurando esse parceiro
  • Quem usar isso pode fazer a manutenção
    O Tangled tem várias escolhas arquiteturais interessantes, mas o código em si é relativamente simples, e pelo que eu vi olhando diretamente, não parece difícil de manter
    Em sua maior parte, são Go modules frouxamente conectados, com HTML+CSS estático, um pouco de TypeScript e Nix para orquestração
    Se me lembro bem, os requisitos de hardware também são bem pequenos, então no tamanho atual uma única pessoa conseguiria hospedar isso por conta própria
    A maior parte da carga de infraestrutura, na prática, fica com os knots, spindles, PDS dos usuários e com o atproto como um todo
  • Este comentário mesmo está sendo escrito em um agregador de notícias financiado com capital de VC, então pensando por esse lado não sei se dá para afirmar isso de forma tão categórica
  • Para mim, VC até vai, desde que não seja dinheiro da YC
  • Quando entra VC desse tipo, eu sempre faço duas perguntas
    Por que precisa ser VC, e por que não financiamento corporativo como no caso do Ladybird?
    E, se os investidores esperam um retorno de 10x, por que eu deveria investir tempo em uma ferramenta para desenvolvedores que inevitavelmente vai sofrer enshittification depois?

• Isso me lembra a piada de que, se existem 4 padrões e alguém resolve criar um novo para unificar tudo, no fim passam a existir 5 padrões
  Piada à parte, acho que falta um argumento mais forte para explicar por que ActivityPub não basta
  Antes de tentar resolver de novo, de outra forma, o problema da comunicação descentralizada

  • ActivityPub e atproto têm formas bem diferentes
    Comparar os dois é meio como perguntar por que precisamos da web se já existe e-mail
    O ActivityPub, como o e-mail, é uma estrutura em que servidores atuam como caixas de entrada e trocam mensagens entre si
    Já o atproto, como a web, é uma estrutura em que repositórios de usuário hospedam os dados e os apps agregam e exibem esses dados
    Essa diferença de topologia muda as propriedades do sistema: no atproto, você pode mudar de hospedagem sem quebrar a experiência no app, e qualquer pessoa pode criar um novo app com base nos dados já existentes
    O ActivityPub não permite isso; no fim, ele se parece mais com pequenos serviços centralizados, cada um com hospedagem e app acoplados, trocando mensagens entre si
  • Acho que também é preciso olhar para a diferença entre o fato de que o Tangled conseguiu lançar um produto sobre ATProto mesmo antes de captar, enquanto o ForgeFed segue avançando lentamente há anos
  • Está linkado no texto original, mas os próprios autores do ForgeFed explicam em https://forgefed.org/blog/actor-programming/ por que ActivityPub não se encaixa bem nesse problema

• Também existe https://gitworkshop.dev/ como uma alternativa ao GitHub relativamente madura rodando sobre Nostr
  A ideia central é que o repositório pode ser publicado em vários relays nostr compatíveis com GRASP, e se um servidor cair, a sincronização transparente segue por outros
  Então, se você escolher servidores confiáveis, chega bem perto de 100% de disponibilidade, e repositórios, atividades, issues etc. também são assinados criptograficamente

  • Não me parece tão maduro assim
    Já pelo nome, parece violar a política de marca registrada de git
    https://git-scm.com/about/trademark
  • Posso estar enganado, mas esse projeto parece closed source
  • Eu não consegui abrir nenhum repositório naquele site de forma funcional
    Em alguns casos dizia que o navegador não suportava URL ssh ou https, em outros só aparecia Failed to load file tree carregando infinitamente
    Então não acho muito convincente chamar isso de fairly mature

• Eu apoio federation com bastante convicção, mas nunca entendi muito bem a utilidade de uma federation of forges
  Que tipo de dados exatamente os forges precisam trocar entre si?
  Por que um forge de Blender precisaria se conectar a um forge de Ubuntu?
  O maior valor que eu tiro do GitHub é um login único que me permite circular entre projetos, e acho que forges independentes já conseguiriam oferecer boa parte desse valor só com social login, sem precisar de uma federation complexa entre forges

  • Quando as pessoas procuram software, no fim elas começam pela busca do GitHub
    Se você hospeda seu próprio forge, ninguém vai encontrar seu software a menos que ele já seja um nome grande como o Blender
    Então, para o código não desaparecer no vazio, manter espelhamento no GitHub acaba sendo quase obrigatório
    Se quisermos evitar isso e permitir que forges menores compitam como um conjunto, é preciso uma rede única em que o software possa ser encontrado independentemente de em qual host ele esteja, e o ForgeFed mira exatamente nisso
    Também reduz o atrito de exigir um login específico de forge para cada novo colaborador, embora isso seja um aspecto secundário de um problema conectado
  • O Git já é descentralizado por design
    O GitHub só resolveu muito bem a parte de UI, issues e PRs, a ponto de iniciantes conseguirem trabalhar pela interface, e nesse processo centralizou tudo
    Federation está mais alinhada com a filosofia do Git, mas não precisa chegar ao extremo de uma descentralização em que, se um nó cai, o upstream some ou nem pode mais ser encontrado
    O Git não resolve disponibilidade, e federation pode complementar isso mantendo a filosofia descentralizada
  • O maior problema, no fim, é discoverability
    Precisamos de uma forma fácil de encontrar projetos open source espalhados por vários servidores
    A busca de projetos do GitHub só funciona dentro do GitHub
  • Um identity provider interoperável é claramente útil
    Além disso, isso também pode tornar tudo mais resilient quando o host do projeto desaparece, muda de política ou é bloqueado por um governo
  • A vantagem aqui é que os dados vivem em um único lugar, o PDS, e se você quiser pode hospedá-lo por conta própria
    E o AppView agrega os dados de vários PDS em uma única interface
    Se o tangled.org sofrer enshittification, ainda assim você pode continuar exatamente do mesmo ponto em qualquer outro AppView, e o tangled.org em si não ocupa uma posição privilegiada
    O social login entre forges independentes ajuda, mas pessoalmente prefiro ter uma única conta, e graças ao AT protocol, mesmo que um forge individual desapareça, os dados continuam acessíveis por outros AppViews