Arquitetura em blueprint do ActivityPub do GitLab
O blueprint do GitLab para adicionar federação baseada em ActivityPub à sua plataforma está gerando debate sobre como forges de software devem interoperar e se isso ajudará a romper os efeitos de rede centrados hoje no GitHub. Comentadores ponderam os benefícios de um modelo aberto e federado — no qual issues e merge requests possam circular entre GitLab, Gitea, Forgejo e outros — contra fluxos de trabalho existentes baseados em patches por email ou interfaces web centralizadas. As questões se concentram no alinhamento de padrões com esforços como ForgeFed, na viabilidade de permissões e privacidade entre instâncias e se grandes players como o GitHub provavelmente adotarão protocolos semelhantes.
Relação com ForgeFed e os forges existentes
- Alguns se surpreendem com o fato de o blueprint do GitLab não mencionar ForgeFed, Forgejo, Gitea etc., que vêm trabalhando em federação interoperável.
- Outros apontam para uma discussão de epic do GitLab que indica conhecimento e provável suporte futuro a ForgeFed.
- Há preocupação de que o GitLab possa construir uma rede centrada no GitLab, mas um comentário vinculado no epic sugere que a intenção é interoperabilidade, não uma alternativa proprietária.
- Uma observação: o comentário relacionado ao ForgeFed no epic é de um colaborador da comunidade, não da equipe do GitLab.
Email + git vs forges web vs ActivityPub
- Um grande fio debate email+git (estilo Linux) versus forges modernas (GitHub/GitLab/etc.).
- Argumentos a favor de forges: UX mais rica, integração com CI, melhores ferramentas de revisão (comentários inline, resoluções), descoberta, labels/tags e menor dependência de convenções sociais.
- Argumentos a favor do email: padrão aberto e federado; clientes poderosos e personalizáveis; boa estrutura de encadeamento e discussão; independência de qualquer forge único.
- Várias pessoas dizem que fluxos de trabalho por email são dolorosos, propensos a erros e escalam mal; outras dizem que a dor vem בעיקר de clientes ruins e falta de ferramentas.
- O fluxo de trabalho por email do kernel Linux é citado como sofrendo com a escala, e há referências a ferramentas do kernel (por exemplo, lore, b4) que tentam contornar os limites do email.
ActivityPub vs “é só usar email/git”
- Alguns gostariam que a ferramenta tivesse sido construída sobre email em vez de inventar uma nova pilha de protocolos.
- Outros respondem que, uma vez que você constrói ferramentas sofisticadas e camadas de metadados, você efetivamente já tem um novo protocolo de qualquer maneira, então usar ActivityPub/HTTP é mais limpo.
- O ActivityPub é visto como permitindo dados estruturados para patches/issues, evitando convenções ad hoc de email e pontes de email sob medida entre forges.
Descentralização, lock-in e GitHub
- Muitos estão animados com “um fediverse para código”: poder abrir issues/MRs entre instâncias sem contas extras.
- Isso é visto como uma forma de corroer o lock-in do efeito de rede do GitHub, permitindo que projetos se movam enquanto mantêm a colaboração aberta.
- Continua a haver ceticismo sobre o GitHub algum dia implementar ActivityPub; a maioria acha que isso só aconteceria sob forte pressão competitiva ou regulatória.
Permissões e privacidade
- A federação de recursos privados é descrita como um não objetivo no blueprint do GitLab.
- Alguns observam que o ActivityPub suporta requisições autenticadas e poderia, em princípio, lidar com permissões entre instâncias.
- A privacidade é limitada: não há criptografia de ponta a ponta; administradores de instâncias podem ver mensagens diretas.