Gitea: Preparando para Federação: Usuários "Remotos" / ID Federado

Na verdade, realmente depende de quais são os casos de uso sobre o que o usuário federado / externo será capaz de fazer. Se eles não puderem hospedar repositórios, não há problema em ter a tabela de usuário federada e mover o nome de exibição, nome de usuário, etc. para ela. Por meio dele, seria necessária uma reescrita total em cada parte do código onde a tabela de usuário local é usada para agora usar a tabela de usuário federado que poderia ser um trabalho danado :)

Eu concordo totalmente @lafriks. Antes de começarmos a fazer isso, precisamos saber algumas perguntas:

1. Quem quer esse recurso? Usuário gitea pessoal / Empresas com website privado de hospedagem gitea / Git via gitea ou outros?
2. Por que eles precisam desse recurso?
3. Como eles querem usar esse recurso?

Se eles não puderem hospedar repositórios, não há problema em ter a tabela de usuário federada e mover o nome de exibição, nome de usuário, etc. para ela.

Os usuários federados podem ter repositórios, mas hospedados na instância do usuário.
Em outras palavras, você não tem apenas usuários federados, mas também projetos federados (incluindo repos, ocorrências, PRs, etc). Mas isso está fora do escopo deste problema.

1. Quem quer esse recurso? Usuário gitea pessoal / Empresas com website privado de hospedagem gitea / Git via gitea ou outros?

Pessoas como eu, que não gostam da ideia de o desenvolvimento de software livre e de código aberto ser centralizado em, bem, serviços centralizados e não livres. (GitHub)

1. Por que eles precisam desse recurso?

Embora existam alternativas gratuitas como Gitea e GitLab, suas instâncias são isoladas umas das outras e, portanto, têm desvantagens de uso. (E estão sujeitos a efeitos de rede.)
Mesmo que eu esteja motivado para fazer uma conta no, digamos, Debian GitLab, é limitado a essa instância.
No pior caso, cada projeto tem seu próprio exemplo e eu tenho tantas contas para verificar. (Sim, há notificações por e-mail, mas queremos algo da Web, caso contrário, Git + ML também seria o suficiente.)

1. Como eles querem usar esse recurso?

Para colaboração federada, quebrando o efeito de rede do GitHub.

Tenho 1 conta na minha instância inicial e posso colaborar com qualquer projeto que ofereça suporte à federação (ou seja, ForgeFed ).

https://github.com/go-gitea/gitea/blob/7217b703e95a3ab01b69f91879fb4d6532f0b2c5/models/user.go#L94 -L97

É correto que

• Name é o nome do usuário ( criztovyl ) e
• FullName é o nome de exibição ("Christoph Schulz")

?

Mas qual é o motivo de LowerName ? ( strings.ToLower(u.Name) )

Para não usar lower(Name) em consultas SQL.

Para não usar lower(Name) em consultas SQL.

Mas por quê? Não quero mudar, apenas entenda. :)

Comecei a brincar um pouco e mudei estupidamente alguns atributos de user.go (digite User ) para um novo user_identity.go (digite Identity ) e adicionei alguns códigos a AfterLoad que preenche os atributos antigos com valores da identidade.

Depois disso, tive problemas ao escrever uma migração que movesse os atributos de User para Identity . Analisarei melhor isso estudando as migrações existentes e documentos xorm, mas ficaria muito feliz com mais algumas dicas. :)

Vou compartilhar alguns commits na próxima vez.

Mas por quê? Não quero mudar, apenas entenda. :)

Como o nome de usuário não diferencia maiúsculas de minúsculas e quando um usuário envia solicitações como https://try.gitea.io/AxIFiVe ou https://try.gitea.io/Axifive, precisamos encontrar rapidamente o usuário único, então apenas chamamos strings.ToLower(username) e envia uma consulta SQL simples.
Converter campos em minúsculas para seleção é uma operação de banco de dados muito cara, é muito mais fácil adicionar um segundo campo.

Eu prometi código.

Acabei de enviar o código com o qual estou lutando, você pode encontrá-lo aqui: https://github.com/criztovyl/gitea/blob/master/models/migrations/v200.go (200 para facilitar a fusão / rebase)

A linha 30, a sincronização do modelo de identidade, funciona como esperado: a tabela é criada.
Mas a linha 35, a sincronização do modelo do usuário, parece não funcionar, a tabela ainda tem as colunas antigas depois disso.

Sync2 apenas adicionará colunas.

Se você deseja excluir colunas, você precisa usar:

https://github.com/go-gitea/gitea/blob/80bfd5145c7b159ebdad3746efe11378b282fa86/models/migrations/migrations.go#L348

Observe que as migrações não devem se referir a itens em modelos ou em outro lugar - eles podem ser alterados em migrações futuras. Eles precisam ser totalmente autocontidos - sem referências a outro código Gitea.

Então:

https://github.com/criztovyl/gitea/blob/2b4065f5ea0921090092b4a5ed61db3bdde2d725/models/migrations/v200.go#L30

Aqui, você realmente precisa ter uma cópia da identidade. Da mesma forma aqui:

https://github.com/criztovyl/gitea/blob/2b4065f5ea0921090092b4a5ed61db3bdde2d725/models/migrations/v200.go#L14

Provavelmente era xorm: "-" , caso em que provavelmente não seria necessário na migração.

Olhando para a tabela de identidade proposta, por que você não pode usar login_source para isso?

Obrigado pelas dicas :)

O problema com login_source, até onde eu analisei, é que ele ainda requer que os nomes de usuário sejam exclusivos por conta própria.

Para federação, os nomes de usuário não são exclusivos, apenas a identidade é (onde o identificador exclusivo para tais identidades é normalmente um URI / IRI); nomes de usuário são mais como um nome de exibição ainda mais limitado.

https://github.com/criztovyl/gitea/blob/2b4065f5ea0921090092b4a5ed61db3bdde2d725/models/migrations/v200.go#L14

Provavelmente era xorm: "-" , caso em que provavelmente não seria necessário na migração.

Entendo, mas como a identidade referenciada pelo IdentityId é preenchida? É automagicamente ou preciso adicioná-lo em algum lugar?

E se eu criar a tabela inicialmente, ainda preciso do modelo de Identidade, então não posso deixá-lo fora, certo?

E outra pergunta rápida; é possível executar a instância gitea que tem todos os testdata dos fixtures em seu banco de dados?

Às vezes sou do tipo visual. Por exemplo, gostaria de verificar se o perfil ainda é exibido corretamente, por exemplo, tem as atribuições de organização corretas.

Você pode dar uma olhada em https://github.com/go-gitea/gitea/blob/master/contrib/pr/checkout.go conforme ele carrega acessórios para nos ajudar a verificar os PRs.

Você poderia fazer uma versão modificada, talvez.

go run -tags "sqlite sqlite_unlock_notify" contrib/pr/checkout.go -run funciona perfeitamente :)

além de não ter atualização de código quente, mas acho que é um pouco mais complicado: D

Eu concordo totalmente @lafriks. Antes de começarmos a fazer isso, precisamos saber algumas perguntas:

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

2. Why they need this feature?

3. How they want to use this feature?

Pessoal

Uso pessoal, seria definitivamente um recurso muito bom. Eu tenho uma instância onde guardo meus repositórios, públicos e privados (não todos, mas muitos). Se alguém quiser colaborar com eles, eles precisam obter um usuário na minha instância e funciona da mesma forma, se eu vejo um projeto em algum lugar em uma instância Gitea e quero colaborar, como consertar algo ou resolver uma solicitação de recurso, eu tem que levar um usuário lá ou enviar um e-mail de solicitação de pull com links diff / ref.

Se eu puder convidar usuários de outras instâncias em um repositório privado ou eles simplesmente se juntarem a seus próprios usuários (se uma instância específica não estiver bloqueada / na lista negra), isso seria muito mais fácil.

Corporativo

Não sei se as empresas vão usar, mas posso ver oportunidades em potencial. No momento, a maioria das empresas está usando o GitHub porque todos têm usuários do GitHub e podem gerenciar permissões / equipes. Como empresa (hipotética), se eu puder hospedar meu próprio Gitea, onde posso convidar outros usuários com usuários Gitea de diferentes instâncias e colocá-los em equipes e dar-lhes permissões que poderiam dar início a uma nova era em que uma empresa pode dizer com segurança "Sim podemos usar Gitea porque todos podem ter um por conta própria "especialmente quando grupos maiores / guerreiros federados podem fornecer instâncias Gitea para usuários que não podem / não podem hospedar suas próprias, como Mastodon tem muitas instâncias e você pode escolher uma, use uma e alcance tudo que você deseja.

Por outro lado, vejo que seria muito trabalhoso e não tenho certeza se funcionaria e pode dividir os usuários em fragmentos menores com base em como eles desejam usá-lo.

Quem quer esse recurso? Usuário gitea pessoal / Empresas com website privado de hospedagem gitea / Git via gitea ou outros?

Como um usuário pessoal ...

Por que eles precisam desse recurso?

Não quero criar uma conta em mil e quinhentas instâncias,

Como eles querem usar esse recurso?

apenas para relatar um problema. É por isso que muitas vezes não o relato. Se eu pudesse fazer isso de uma instância na qual já tenho uma conta, independentemente de onde o repositório em questão esteja hospedado, as coisas seriam diferentes.

A propósito: o mesmo se aplica a "PRs / MRs mínimos" contendo correções únicas. Resumindo: se eu não planejo "realmente entrar" em um projeto, mas ainda assim contribuir com meus 2 centavos.

Eu concordo totalmente @lafriks. Antes de começarmos a fazer isso, precisamos saber algumas perguntas:

1. Quem quer esse recurso? Usuário gitea pessoal / Empresas com website privado de hospedagem gitea / Git via gitea ou outros?

Sou um usuário pessoal do Gitea que colabora com outras pessoas, como @ a1batross. Ambos temos nossas próprias instâncias Gitea, mas eu gostaria de poder facilmente contribuir com código para um de seus repositórios, como uma solicitação de pull de instância cruzada.

1. Por que eles precisam desse recurso?

Muito mais fácil do que fazer uma conta em outra instância - e dessa forma você não precisa ter registros abertos para aceitar o código de outras pessoas. Não quero um milhão de contas Gitea.

1. Como eles querem usar esse recurso?

Principalmente solicitações e problemas de pull entre instâncias. Eu também gostaria de fazer com que as organizações incluíssem usuários remotos (para que eles pudessem enviar diretamente).

1. Quem quer esse recurso? Usuário gitea pessoal / Empresas com website privado de hospedagem gitea / Git via gitea ou outros?

Pessoal porque acho que ajudará principalmente a reduzir o número de contas ativas para eles.

O Git hospeda sites porque reduzirá o efeito de rede e não será necessário armazenar os detalhes das contas de cada pessoa que vier relatar um problema ao mesmo tempo.

1. Por que eles precisam desse recurso?

Para tornar a contribuição em projetos estrangeiros mais fácil, você não precisa criar uma conta para relatar um problema de fazer uma correção rápida.

1. Como eles querem usar esse recurso?

Eu gostaria de usá-lo para ter apenas uma identidade git e não uma tonelada de contas em repositórios Git associados a locais diferentes.

Eu gostaria de poder fazer tudo o que faço atualmente no Gittea, GitHub e GitLab em um único lugar. Ou seja, problemas, solicitações de pull / mesclagem, organizações.

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

Privado. Executar meu próprio servidor Git faz meus projetos parecerem menos disponíveis devido à infraestrutura menor. Ter descentralização e interoperabilidade com Github / GitLab torna meus Projetos tão acessíveis e mais disponíveis como se estivessem nessas Plataformas. Não há necessidade de que todos tenham contas no meu servidor, o que o torna mais atraente para os contribuidores.

2. Why they need this feature?

Integração perfeita. Use a interface que você deseja colaborar nos projetos que você gosta.

3. How they want to use this feature?

Autoridade central em meus servidores e ter CI ou outros serviços em nuvem interagindo com qualquer software de hospedagem que me forneça os melhores recursos que desejo. Não há necessidade de que todos sejam compatíveis com todas as diferentes APIs do GitLab / GitHub / Gitea e todas as menores.

Copiando feedback do fediverse de fr33domlover (equipe ForgeFed) :

A situação atual é que para interagir com um repo hospedado em uma forja como Gitea ou GitLab ou githu8 etc. você precisa ter uma conta lá. Cada site da forja é uma ilha separada.

Se você hospedar sua própria forja, poderá fazer as regras, etc., mas estará isolado. É mais difícil encontrar você. Muitas pessoas temem que receberiam menos contribuições se deixassem o githu8. Também exigiria que os contribuintes criassem uma conta em cada forja.

E o githu8 é proprietário e centralizado e não é um projeto comunitário feito pelas pessoas para as pessoas.

A ideia é que a visibilidade do seu projeto e o acesso a ele não dependam se a conta do usuário está na sua forja ou em alguma outra forja. Você pode criar uma conta e participar de qualquer lugar. Pesquisa de projeto, descoberta, recomendações, etc. encontre coisas de toda a rede. Nenhuma forja tem mais poder sobre os usuários do que outra.

Exemplos:

• Organizações / equipes / grupos podem incluir usuários de diferentes forjas
• Você pode enviar commits para repositórios em diferentes forjas
• Você pode abrir questões, abrir solicitações de mesclagem, comentar, enviar revisão de código, etc. entre forjas
• Repos, servidores CI, wikis, rastreadores de problemas, etc. podem estar em servidores diferentes e ainda assim trabalhar perfeitamente em conjunto

1. Como eles querem usar esse recurso?

Além do que outros já mencionaram: Enquanto navego na web, encontro muitos projetos interessantes que existem em sua própria instância gitea / gitlab. Muitas vezes, eu só quero estrelar esses repositórios, mas o atrito aqui (inscrever-se) é muito alto. Em vez disso, eu os adiciono aos favoritos em meu navegador e quase sempre me esqueço de verificá-los mais tarde (muitos favoritos).

No github, eu uso estrelas tanto como um meio de marcar como um sinal de agradecimento pelo projeto. Eu observo projetos de interesse particular, então tenho meu painel de notificações como uma maneira fácil de rastrear atividades.

Estrelas podem ser abusadas, mas se um repositório github tem, digamos, 14 mil estrelas, então ele diz algo sobre sua popularidade e posso estar razoavelmente certo de que o projeto é útil e de boa qualidade. No gitea / gitlab, as estrelas não me dizem muito atualmente.

Idealmente, no futuro, eu tenho um - o meu próprio - local conectado ao fediverse, onde tenho uma visão geral de todas as minhas atividades de codificação, independentemente de onde as executei.

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

Sou um usuário pessoal do Gitea
Tenho duas instâncias do Gitea, uma para meu coletivo de arte (onde mantemos o código para nossos projetos) e outra para mim (onde faço meu trabalho pessoal e contratado, e também alguns projetos com meus alunos)

2. Why they need this feature?

Principalmente porque não quero usar o GitHub ou seus concorrentes.
Este tópico de perguntas é um bom exemplo, todos nós precisamos de contas GitHub para poder fazer parte de uma conversa, enquanto com federação, poderíamos usar nossas contas federadas

3. How they want to use this feature?

Se Gitea e outros serviços fossem todos federados, usando um protocolo comum (ActivityPub), isso não só abriria a possibilidade de interação entre os serviços VCS federados, mas para o fediverse em geral, você seria capaz de comentar e assinar o projeto atualizações do Mastodon, por exemplo.

Ecoando o que muitos outros usuários estão dizendo, gostaria de poder permitir que as pessoas contribuam facilmente com meus projetos, mesmo simplesmente criando problemas, sem ter que abrir registros no meu servidor, e gostaria de ser capaz de criar problemas ou fornecer pequenas contribuições sem o incômodo de criar mais contas
Em um mundo ideal, eu não teria mais uma conta GitHub

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

Eu sou todos os 3.

1. Sou um usuário pessoal do gitea (ligado e desligado, principalmente desligado, consulte a resposta à parte 2).
2. Meu dayjob tem (várias!) Instâncias internas / privadas do gitea.
3. Eu consideraria fornecer um site de hospedagem git privado (ou seja, somente para convidados) via gitea (que eu também usaria pessoalmente) se forgefed fosse uma opção.

2. Why they need this feature?

Como um usuário particular:
A escolha entre hospedar seus dados no github, gitlab e "outro lugar" é grave.
Se eu escolher github / gitlab, ficarei à mercê de suas decisões como plataforma e não tenho controle sobre meus dados.
Se eu escolher outra coisa (por exemplo, minha própria instância do gitea), é difícil descobrir o projeto [1] e as contribuições exigem ter uma conta própria (agora sou um hospedeiro de site? Isso não é bom) ou enviar o e-mail rota (que é restritiva, nem todo mundo gosta desse fluxo de trabalho).
Com a federação (mesmo que não necessariamente forjada, mas idealmente interoperável entre vários serviços), eu obtenho o melhor dos dois mundos - um pode contribuir de qualquer instância usando suas próprias contas e descobrir qualquer um dos meus projetos hospedados localmente, enquanto eu chego a manter o controle sobre meus dados e plataforma.

Como anfitrião corporativo:
Como mencionei, temos várias instâncias do gitea, por vários motivos.
Estaríamos interessados ​​na federação de lista branca (ou seja, onde a federação só é ativada contra outros servidores específicos) para facilitar as trocas entre nossos nós internos e aqueles de parceiros de software arbitrários, sem necessariamente precisar dar-lhes acesso interno em qualquer caso.

Como um host de site:
Considere tudo, desde a parte do usuário particular - agora este é o argumento de venda para os usuários em potencial.
Você não precisa confiar apenas em "bem, X é mau e eu não" como seu único argumento.
Além disso, os custos de pessoas que migram para o seu serviço tornam-se muito menores (se não insignificantes).

3. How they want to use this feature?

Como um resumo / para reiterar:

Como um usuário privado (e host de site por ter usuários que são efetivamente apenas isso):

• descubra facilmente projetos externos por meio de pesquisa (e deixe o seu ser descoberto)
• permitir a contribuição (incluindo problemas de relatório, comentários, etc.) para um determinado projeto sem ter uma conta em sua instância

Como um usuário corporativo:

• federação de lista de permissões:
  
  
  
  • permitir a comunicação interna entre nós de propósito diferente
  
  
  • permitir comunicação de confiança zero e privilégio zero entre nossos nós e os de vários parceiros de software
  
  

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

Sim, tanto para minha gitea pessoal quanto para a que usamos no trabalho.

2. Why they need this feature?

Para colaborar em projetos em outras instâncias forjadas. Não deve haver necessidade de criar uma conta de usuário em cada sistema. No caso da minha instância privada, não gostaria de dar acesso aleatório a pessoas. E para a instância da empresa, obviamente, os não funcionários não podem ter acesso.

3. How they want to use this feature?

Eu o usaria para colaborar em projetos, tanto de código aberto quanto proprietários.

1. Quem quer esse recurso? Usuário gitea pessoal / Empresas com website privado de hospedagem gitea / Git via gitea ou outros?

Definitivamente, usuário pessoal.

1. Por que eles precisam desse recurso?

O código aberto tem tudo a ver com colaboração. O GitHub tornou o código aberto popular ao tornar o trabalho no código uma coisa social e tornando trivial relatar problemas e contribuir com projetos. Embora descentralizar o espaço em que o GitHub está seja uma coisa boa por um lado, estamos retrocedendo em termos de facilidade de envio de problemas ou patches.

1. Como eles querem usar esse recurso?

A federação resolve o problema mencionado acima, pois não importa em qual instância ou plataforma o usuário está, ele pode simplesmente puxar um projeto remoto e contribuir para ele de sua própria instância, usando sua própria conta local.

De alguma forma, o GitHub não me enviou nenhum e-mail de notificação sobre os novos comentários aqui, eu os perdi completamente.

De qualquer forma, continuo a brincar em segundo plano, agora estou lutando com o xorm e ansioso para carregar.

Eu tenho:

type Identity struct {
  ID          int64 `xorm:"pk autoincr"`
  UserName    string
  DisplayName string
}

type User struct {
  ID          int64 `xorm:"pk autoincr"`
  Slug        string // LowerName
  IdentityId  int64 `xorm:"NOT NULL DEFAULT 0"`
  Identity    Identity `xorm:"-"`
}

Como faço para e.Get(&User{Slug: slug}) carregar automaticamente (?) O Identity dado por IdentityId ?

Eu não acho que isso vai funcionar. Acho que o xorm só pode fazer o contrário, ou seja, se Identity tivesse uma coluna UserID , o xorm poderia preencher uma fatia de Identities em User .

Se xorm for suficientemente igual a gorm, você deve ser capaz de pré-carregar a coluna Identidades para que isso aconteça. Em SQL normal, isso seria um JOIN, então http://gobook.io/read/gitea.com/xorm/manual-en-US/chapter-05/5.join.html deve ajudar.

Algo como a amostra

engine.Table("user").Alias("u").
    Join("INNER", []string{"group", "g"}, "g.id = u.group_id").
    Join("INNER", "type", "type.id = u.type_id").
    Where("u.name like ?", "%"+name+"%").Find(&users, &User{Name:name})

Deve fazer o truque de acordo com os documentos.

Hmm, para o meu problema ter uma lista de identidades não ajuda.
E, infelizmente, o Join-Approach também não funciona.

Olhei em volta um pouco mais na base de código e descobri que Repository tem um Owner *User que parece carregado manualmente usando uma função GetOwner , apliquei o mesmo padrão ao meu código agora. :)

Então eu limpei meu repositório local, enviei e enviei uma versão de rascunho da divisão de usuário / identidade que funciona para exibir um perfil de usuário local, por exemplo, localhost: 8080 / user1. :) Veja https://github.com/criztovyl/gitea/commit/d0f24f7919d15ee481f5eae7ec6131ff369eaa66
Por enquanto, só funciona para usuários, as organizações ainda não funcionam.
Não é muito, mas é alguma coisa. :)

Com o corte de toda a carne que as organizações têm, a página de perfil da organização também funciona agora. Consulte https://github.com/criztovyl/gitea/compare/d0f24f7...3901206bc.

Meu código é bastante explorador, não é nada definitivo. :)

Por que não adicionar duas colunas à tabela de usuários, is_local e remote_url (talvez domain também, embora nem todas as instâncias do gitea estejam hospedadas na pasta principal de um domínio específico, por isso Eu fui com romain_url )? Dessa forma, uma mesa extra e junções não são necessárias.

Não é a primeira vez que alguém sugere isso, pensei nisso também.
Mas temo (ed) que isso poderia facilmente levar à comparação acidental de um usuário apenas pelo nome de usuário, o que é inválido porque você deve (neste caso específico) comparar todos os três is_local , remote_url e username (pode ser otimizado apenas comparando remote_url e username quando remote_url = "" significa is_local ).
Outra preocupação seria aumentar a tabela de usuários e com ela, por exemplo, o índice de lower_name , que agora precisa ser um índice combinado de remote_url e lower_name . (Por outro lado, também se pode definir lower_name apenas para usuários locais ... hmm.)

Eu prefiro o authn / identity-split porque acho que é mais limpo de implementar. (Como Identidade é um conceito novo, não deveria acontecer apenas comparar apenas nomes de usuário.)
Mas acho que devo me decidir novamente, agora que posso ver como é complexo introduzir a divisão. :)
Eu às vezes sou um pouco ingênuo. ^^

@criztovyl há casos em que remote_url ou domain (sub domain) muda, pode mudar também

• https://mydownmain.com/gitea <--- inicialmente
• https://gitea.mydownmain.com <--- movido para subdomínio
• https://source.mydownmain.com <--- queria um nome genérico
• https://git.mydownmain.com <--- simplicidade finalmente desejada

como você sabe nomear as coisas é difícil

Tentando também entender o seguinte

• E se eu perder meu domínio, por exemplo? ou o nome precisa ser alterado por motivos legais, ou acabei de vender meu domínio. Isso significa que não poderei contribuir para os projetos em que estava trabalhando antes?
• Ele suportará o uso de username & email ?
• Como você sabe, também tenho a flexibilidade de alterar meu nome de usuário ou usar e-mail para fazer login em vez de um nome de usuário, como isso se encaixa no que você está propondo

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

Todos se opõem ao racismo, por exemplo - desde 2019, github, bitbucket e gitlab têm bloqueado usuários com base na localização geográfica percebida - https://archive.today/U1R2L . Com a enorme onda de demonstrações de BLM, não é um bom momento na história para apoiar o racismo na comunidade de software. Estou falando apenas em meu próprio nome, como usuário do gitea em https://codeberg.org . Isso está postado como https://codeberg.org/Codeberg/Community/issues/142 , embora eu ache que deve se tornar um problema independente no Codeberg. A discussão ali sugere _alguns_ interesse no Codeberg.

2. Why they need this feature?

Por causa da tirania da conveniência (Keye 2009) (Wu 2018) . As funções de rede social online do github / bitbucket / gitlab são extremamente poderosas. Digite '@' e alguns caracteres, e provavelmente você será solicitado a fornecer o ID de usuário da pessoa que deseja entre uma grande fração da comunidade de software livre. É eficiente, público (por padrão), e a pessoa que recebeu o ping pode responder ou ignorar o problema sem ter que limpar sua caixa de e-mail.

Mas https://codeberg.org e outros servidores de repositório git não racistas ainda não têm federação do tipo ActivityPub. Esta é uma razão pela qual os usuários do github são dissuadidos de mudar para servidores baseados na comunidade: a _tirania da conveniência_ é que as conexões sociais fáceis na comunidade mundial não - _ainda_ - existem em servidores de pequenas comunidades.

Em outras palavras, o recurso é necessário para armazenar efêmeras acadêmicas em servidores que são independentes dos servidores corporativos centralizados, secretos e racistas (em 2019/2020, veja acima).

3. How they want to use this feature?

Para redes sociais focadas especificamente no desenvolvimento de software entre a comunidade aberta de desenvolvedores de software (principalmente software livre).

Bloqueando este tópico, pois agora recebemos uma grande quantidade de feedback para as perguntas acima e agora quem continuar a trabalhar nisso terá essa informação que pode analisar.