Gitea: Federação para organização, repositórios e usuários

Provavelmente seria suficiente para suportar repositórios federados

@kolaente O recurso de federação faz sentido explicitamente para os usuários. Se você deseja compartilhar repositórios, deve usar o recurso de espelhamento. Mas seria muito conveniente para o gerente de projeto adicionar usuários de outras instâncias do git.

Veja também #184 (isso é uma duplicata disso?)

@strk meio que, mas acho que esse vai mais longe

@strk Tipo de. Mas esse problema inclui uma integração completa do recurso de federação para organização, não apenas para solicitações pull.

Você quer dizer para autorização de usuários remotos?
Como acho útil dividir "federação" em vários pequenos
coisas para implementar, ou um único ticket ficaria muito grande.

@strk concordo com a ideia de dividir isso em muitos tickets. Este tíquete pode ser o tíquete de federação do usuário, não é? Mas não quero autenticação para usuários de outras plataformas. Eu quero a capacidade de adicionar outros usuários. O usuário receberá um convite da instância do Gitea do usuário. Ele acessará o repositório ou organização a partir de sua instância.

Conceder permissões a alguém em uma federação requer ser capaz de
identificar esse alguém (um endereço global). Como você mencionou owncloud I
acho que o owncloud usa "@" como identificador, mas não sei o que
protocolo que ele usa para isso. Implementação de Friendica/GNUSocial e outros OStatus
federações também podem usar "@" mapeando para outra coisa via
o padrão Webfinger (que é aberto para permitir a especificação de diferentes
protocolos). Outra comunidade (a IndieWeb, veja indieweb.org) usa
endereços da web para identificar pessoas, pois é usado com OpenID até a versão 2.0.
Novo OpenID (OpenID-Connect) usa novamente o Webfinger.

Acho que o padrão webfinger pode ser uma boa solução. Mas acho que também pode entrar em conflito com o git email de um usuário.

Onde está o conflito?

Em vez disso, o que eu não gosto no Webfinger é que ele precisa de controle de
a raiz do domínio (que você não tem com a URL OpenID).

Em relação a "qual padrão queremos escolher", quero apenas apontar para o ActivityPub , que está sendo finalizado pelo grupo de trabalho da Federação Social do W3C. Alguns projetos de implementação (ou atualmente trabalhando nisso) são pump.io, Mastodon e MediaGoblin.

Eles não usam o WebFinger, pois não gostam da ideia de um caminho fixo .bem conhecido, mas há ideias sobre interoperabilidade .

Esse recurso será realmente um divisor de águas; keybase.io recentemente saiu com o git criptografado do lado do cliente, isso também é interessante.

Só quero salientar que o ActivityPub está pronto.

Adicionar suporte para AP tornaria o Gitea compatível com um número crescente de servidores federados, como Mastodon, PeerTube, NextCloud e HubZilla, ampliando consideravelmente seu alcance, sem mencionar um diferencial de destaque em relação ao GitLab.
Ele também teria o potencial de destronar o GitHub como hospedagem para projetos de código aberto, já que a maioria está aqui para o fluxo de trabalho de solicitação de pull da comunidade que o AP permitiria de maneira descentralizada, aumentando a privacidade e eliminando um único ponto de falha para uma grande porcentagem da comunidade de software livre.

De qualquer forma, minha esperança é que isso seja implementado, tem potencial para ser revolucionário!

Como já foi dito no chat, o ActivityPub em go é um PITA porque é difícil fazer isso em uma linguagem estática como go.

@tboerger Interessante. A especificação ActivityPub é OO bastante pesada em herança, mas isso deve ser possível modelar em Go com incorporação de struct, no entanto, até onde eu sei, não há nada como serde em Rust (https://docs.serde. rs/serde_json/value/index.html), o que simplifica bastante as coisas, porém há algum esforço para implementar o ActivityPub em Go, o que pode ser um bom começo, pois não apenas já implementa a análise json-ld , mas também define o vocabulário principal para ActivityStreams.

Que aborrecimentos específicos você está pensando aqui?

@MatejLach Outro projeto https://github.com/go-fed/activity

Proposta relevante no repositório gogs:
https://github.com/gogs/gogs/issues/4437

No repositório do Gitlab:
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

Oi! Co-editor do ActivityPub aqui. Estou bastante ocupado no momento, mas gostaria de ver isso acontecer... se você precisar de perguntas, sinta-se à vontade para me enviar um ping ou perguntar em #social no irc.w3.org

Por favor, não hesite em entrar em contato comigo no Mastodon para quaisquer perguntas/preocupações/comentários sobre a https://github.com/go-fed/biblioteca de atividades que @jas99 mencionou. Obviamente, tenho interesse no resultado da decisão, mas ficaria feliz em fornecer informações sinceras sobre minhas experiências trabalhando na interseção go+ActivityPub. Concordo com @tboerger que implementar o ActivityPub em movimento é um penhasco íngreme.

Talvez pudéssemos criar um novo repositório chamado index e configurar o novo domínio index.gitea.io para fazer isso?

Por que precisamos de um servidor de indexação? @lunny

Seria incrível se pudéssemos ter projetos diferentes discutindo uma implementação comum do protocolo ActivityPub (ou seja, usando a mesma extensão para verbos, etc). Isso permitiria que os usuários do gitea, gogs e gitlab trabalhassem juntos perfeitamente, assim como os usuários de várias plataformas de mídia social que federam podem discutir sem problemas.

Poderia ser este o lugar? -> https://github.com/git-federation/gitpub

@jaywink ótima ideia!

Isso seria incrível! Acho que Nextcloud (/Owncloud) é o exemplo perfeito de como isso poderia funcionar com a implementação ideal, como sugeriu @JonasFranzDEV .

Com o Nextcloud, se eu quiser compartilhar uma pasta com um usuário em outra instância, posso fazer isso facilmente e configurar uma pasta compartilhada em ambas as instâncias.

Se eu pudesse fazer isso para um repositório hospedado na minha instância do Gitea, concedendo a um usuário em outra instância federada acesso ao repositório, com esse repositório aparecendo em sua interface do Gitea com total capacidade de interagir com problemas etc (com alguma denotação clara no UI que este repositório estava hospedado em outra instância), isso seria incrível.

O objetivo que está sendo discutido de adotar um padrão compartilhado entre Gitea e outros projetos auto-hospedados de código aberto (como GitLab CE) definitivamente faz sentido, e seria ótimo se isso fosse adotado permitindo a federação entre Gitea, Gogs, GitLab, etc. Migrar do GitHub para projetos privados é fácil, sem nada realmente perdido, mas para projetos públicos de código aberto, precisamos reconhecer que um grande benefício do GitHub é a comunidade. Eu descobri muitos projetos na verdade no GitHub. Se houvesse alguma maneira de federar projetos populares, o feed de atividades dos usuários (ou seja, poder seguir um amigo em outra instância e seguir sua atividade, projetos curtidos, com configurações de privacidade levadas em consideração etc.) seria excelente - se isso fosse possível.

As solicitações de pull federadas seriam um ótimo primeiro passo para isso (#184) e provavelmente o recurso ausente mais crucial no momento.

11 meses desde o último comentário aqui .. Eu estou querendo saber se ainda há planos em andamento?

Quando há algum tipo de padrão acordado do que sim

As discussões atuais estão acontecendo como parte do projeto forgefed, então acompanhe lá se quiser saber mais: https://github.com/forgefed/forgefed

Como @lafriks mencionou, uma vez que há um padrão acordado, vários projetos podem implementá-lo.

A URL correta para o projeto forgefed agora é https://notabug.org/peers/forgefed

Parece que isso deve ser de primordial importância agora, considerando que o github agora está removendo contas de ppl de países inteiros.

ForgeFed agora também tem um fórum de discussão . Seria ótimo ter alguém da Gitea envolvido.

+1 para isso. Trabalhar a partir de uma instância auto-hospedada local, mas não ficar isolado devido a essa escolha, seria realmente o melhor dos dois mundos.

O grupo de trabalho ForgeFed precisaria desesperadamente de desenvolvedores das forjas atuais para fazer comentários: https://talk.feneas.org/t/working-group-instructions/196

Eu gostaria apenas de acrescentar que antes da Microsoft inspirar uma migração em massa para longe do Github, isso não teria sido um recurso matador... AGORA é. Cada vez menos os repositórios para projetos de SO que estou pesquisando estão no Github agora (TALVEZ espelhado aqui).

Eu li que o histórico de commits do Github pode ser lido como um currículo e que uma das razões pelas quais o mundo do software é tão móvel para a carreira é que uma pessoa pode auto-ensinar habilidades valiosas, DEMONSTRÁ-las FACILMENTE (histórico público do github) e, portanto, qualificar para melhores ganhos/etc. Se o seu histórico de contribuições estiver espalhado por dezenas de servidores privados, é MUITO menos visível/útil.

Além disso, qualquer um desses servidores pode cair a qualquer momento e essa parte do seu histórico desapareceu. Uma implementação adequada de repositórios federados significaria que eu poderia participar de dezenas de projetos em dezenas de instâncias (da minha instância) e se TODOS eles caíssem, eu ainda teria meu 'perfil git federado'.

Link para o roteiro do ForgeFed (há financiamento para quem trabalhar nele):

https://notabug.org/peers/forgefed/issues/87

Talvez, para uma implementação simples, o gitea possa executar um nó ipfs em segundo plano hospedando arquivos de repositórios locais (usando ipns para apontar para as versões mais recentes dos repositórios). Poderíamos então ter uma implementação simples do protocolo gossip para encontrar outras instâncias do gitea e obter hashes ipns e dados preliminares (estrelas, nome).
O benefício de usar ipfs seria quando os usuários em uma instância quisessem visualizar ou bifurcar repositórios em outras instâncias, isso contribuiria para hospedar partes desse repositório e tornaria o acesso ao repositório mais rápido para a rede como um todo.

O uso de ipfs/ipns também pode ser usado para distribuir dados do usuário, como repositórios com estrela, solicitações pull, bio, etc. dados de perfil para usuários desconhecidos.

O ipfs já tem uma implementação go e, por exemplo, discovery, algo assim pode ser usado.

Não há necessidade de armazenamento ponto a ponto aqui, o que você descreve não parece necessário ou mesmo relacionado ao problema em questão. Não acho que haja interesse em se afastar do formato de armazenamento Git e do protocolo de transferência. Talvez você deva abrir um problema separado se vir um benefício aqui (certamente não vejo).

Não há necessidade de armazenamento ponto a ponto aqui

Eu acho que o gitea se beneficiaria muito do compartilhamento ponto a ponto de repositórios, de modo que os repositórios populares seriam redundantes no caso de instâncias ficarem inativas. Embora alguém possa apenas espelhar um repositório para sua própria instância, isso fragmentaria o desenvolvimento de um projeto se não houver um local central para se comprometer. Se o protocolo git estivesse em camadas no IPFS, ele permitiria a desduplicação ao bifurcar projetos em uma única instância (para que uma cópia inteira não precisasse ser armazenada).

o que você descreve não parece necessário ou mesmo relacionado ao problema em questão.

O motivo pelo qual a federação é tão útil (e por que as pessoas a desejam tanto) é que ela permite a colaboração entre instâncias. O InterPlanetary Name System (IPNS) tem comportamento idêntico ao OpenID porque pode ser usado para identificar um usuário que tem permissão para atualizar determinados dados (por exemplo, seus repositórios e perfil pessoal). Um endereço IPNS pode identificar exclusivamente um usuário de outra instância sem necessariamente ter que vincular esse usuário a uma instância específica. Vamos dar um exemplo:
Alice está hospedando uma instância do gitea em aliceland.net
Quando Alice cria uma nova conta, o gitea cria um perfil vazio, hospeda-o no IPFS e gera um endereço IPNS exclusivo que aponta para esse perfil. Sempre que Alice cria um novo repositório ou atualiza seu perfil de alguma forma, o gitea irá (nos bastidores) criar um novo registro IPFS, desafixar o antigo e reatribuir o endereço IPNS de Alice a ele.
Agora digamos que Bob deseja enviar uma solicitação de mesclagem de seu espelho do repositório em bobland.net para aliceland.net.
Quando Bob originalmente bifurcou o repositório de Alice para bobland.net, ele anotou o IPNS do repositório de Alice, bem como a localização IPFS do commit do qual ele bifurcou.
Quando Bob deseja abrir uma solicitação de mesclagem, ele escreve sua mensagem e, em seguida, bobland.net colocará as seguintes coisas em um bloco IPFS:

• Endereço de usuário IPNS de Bob
• O endereço IPFS dos commits que Bob deseja receber
• O endereço IPFS do commit no repositório de Alice que deve ser modificado
• Mensagem e título de Bob para a solicitação de mesclagem
• Assinatura de dados com a chave de perfil IPNS privada de Bob

Bobland.net enviará o endereço IPFS para aliceland.net, que poderá optar por ignorá-lo totalmente, OU analisar o endereço, verificar os commits, criar um endereço IPNS para o tópico de comentários (que aponta para todos os comentários) e notificar Alice que um cara chamado Bob na instância Bobland.net enviou uma solicitação de mesclagem para 3 commits sobre IPFS. Os comentários também seriam hospedados em IPFS e acessíveis por meio de um endereço IPNS.
Esse padrão de uso de IPNS para dados mutáveis ​​(como um thread de comentários) e IPFS para dados imutáveis ​​(como comentários e confirmações) pode ser aplicado à maioria das federações entre instâncias.

Não acho que haja interesse em se afastar do formato de armazenamento Git e do protocolo de transferência.

Essa abordagem de federação não precisaria se afastar do formato Git. O Git pode simplesmente ser colocado em camadas e armazenado em ifps (enquanto também aproveita a desduplicação). O sistema Merkle Tree do Git não precisa necessariamente ser integrado ao IPFS (embora isso seja legal) e o protocolo de transferência do git ainda seria o mesmo, o IPFS apenas moderaria a comunicação entre as instâncias.

Você pode simplesmente abrir um problema separado? Este é sobre algo específico, e o ForgeFed já está trabalhando em um protocolo. Melhor ainda, traga isso com eles.

Acumular problemas com comentários como "e quanto a ipfs/filecoin/blockchain" parece rude.

+1

O GitLab também está discutindo esse recurso: https://gitlab.com/gitlab-org/gitlab/-/issues/6468

Eu pingei na discórdia do gitea dev alguns dias atrás como um FYI, e tenho tentado proativamente entrar em contato com algumas das pessoas por trás do ForgeFed, já que com o go-fed v1 sendo feito e documentado, seria bom obter uma instância do gitea federado no ActivityPub, embora não seja um esforço pequeno. Acho que o pessoal do gitea está ocupado com outras prioridades. Infelizmente, não tive sucesso em entrar em contato com qualquer um do pessoal do ForgeFed. :(

Alguns de nós da comunidade ActivityPub, saindo do APConf2020, estão experimentando ter um processo de documentação leve e básico em uma instância do gitea e parece estranho não poder federar com ele ainda.

O Git já possui todos os recursos necessários para espelhamento descentralizado, a única funcionalidade que falta é o necessário para coordená-lo, que é exatamente o que o ForgeFed faz. O IPFS não precisa estar aqui e, considerando o quão desastroso foi o lançamento da rede principal, não tenho certeza se é seguro ficar profundamente vinculado a outros projetos do Protocol Labs.

Estou interessado em colaborar em qualquer uma das iniciativas existentes. Vamos tentar montar um grupo de trabalho. Pode sugerir este canal Matrix para uma discussão mais aprofundada #n oteworthy:tincan.community