Gitea: Federación para organización, repositorios y usuarios

Probablemente sería suficiente para admitir repositorios federados

@kolaente La función de federación tiene sentido explícitamente para los usuarios. Si desea compartir repositorios, debe usar la función de espejo. Pero sería muy conveniente para el administrador del proyecto agregar usuarios de otras instancias de git.

Ver también #184 (¿es esto un duplicado de eso?)

@strk algo así, pero creo que este va más allá

@strk Algo así . Pero este problema incluye una integración completa de la función de federación para la organización, no solo para las solicitudes de extracción.

¿Te refieres a la autorización de usuarios remotos?
Como creo que es útil dividir la "federación" en muchos pequeños
cosas que implementar, o un solo ticket sería demasiado grande.

@strk Estoy de acuerdo con la idea de dividir esto en muchos boletos. Este ticket podría ser el ticket de la federación de usuarios, ¿no es así? Pero no quiero autenticación para usuarios de otras plataformas. Quiero la posibilidad de agregar otros usuarios. El usuario recibirá una invitación de la instancia de Gitea del usuario. Accederá al repositorio u organización desde su instancia.

Otorgar permisos a alguien en una federación requiere poder
identificar a ese alguien (una dirección global). Como mencionaste owncloud yo
creo que owncloud usa "@" como identificador, pero no sé qué
protocolo que utiliza para eso. Friendica/GNUSocial y otras implementaciones de OStatus
las federaciones también pueden usar "@" asignación a otra cosa a través de
el estándar Webfinger (que está abierto para permitir especificar diferentes
protocolos). Otra comunidad (la de IndieWeb, véase indieweb.org) utiliza
direcciones web para identificar personas, ya que se usa con OpenID hasta la versión 2.0.
El nuevo OpenID (OpenID-Connect) utiliza de nuevo Webfinger.

Creo que el estándar webfinger podría ser una buena solución. Pero creo que también podría entrar en conflicto con el correo electrónico de git de un usuario.

¿Dónde está el conflicto?

Más bien, lo que no me gusta de Webfinger es que necesita el control de
la raíz del dominio (que no tiene con la URL de OpenID).

Con respecto a "qué estándar queremos elegir", solo quiero señalarte ActivityPub , que actualmente está siendo terminado por el grupo de trabajo de la Federación Social del W3C. Algunos proyectos que lo implementan (o están trabajando actualmente en eso) son pump.io, Mastodon y MediaGoblin.

Sin embargo, no usan WebFinger porque no les gusta la idea de una ruta fija .bien conocida, pero hay ideas sobre la interoperabilidad .

Esta característica será un verdadero cambio de juego; keybase.io salió recientemente con git cifrado del lado del cliente, eso también es interesante.

Solo quiero señalar que ActivityPub ya está listo.

Agregar soporte para AP haría que Gitea fuera compatible con un número creciente de servidores federados, como Mastodon, PeerTube, NextCloud y HubZilla, ampliando considerablemente su alcance, sin mencionar un diferenciador destacado frente a GitLab.
También tendría el potencial de destronar a GitHub como el alojamiento de referencia para proyectos de código abierto, ya que la mayoría está aquí para el flujo de trabajo de solicitud de extracción de la comunidad que AP permitiría de manera descentralizada, aumentando la privacidad y eliminando un punto único de falla para un gran porcentaje de la comunidad de software libre.

De todos modos, mi esperanza es que esto se implemente, ¡tiene el potencial de ser revolucionario!

Como ya se indicó en el chat, ActivityPub in go es un PITA porque es difícil de hacer en un lenguaje estático como go.

@tboerger Interesante. La especificación de ActivityPub es bastante herencia OO, pero eso debería ser posible de modelar en Go con la incorporación de estructuras, sin embargo, que yo sepa, no hay nada como serde en Rust (https://docs.serde. rs/serde_json/value/index.html), que simplifica bastante las cosas, sin embargo, hay un esfuerzo para implementar ActivityPub en Go, lo que puede ser un buen comienzo ya que no solo implementa el análisis json-ld , sino que también define el vocabulario básico de ActivityStreams.

¿En qué molestias específicas estás pensando aquí?

@MatejLach Otro proyecto https://github.com/go-fed/activity

Propuesta relevante en el repositorio de gogs:
https://github.com/gogs/gogs/issues/4437

En el repositorio de Gitlab:
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

¡Hola! Coeditor de ActivityPub aquí. Estoy bastante ocupado en este momento, pero me gustaría ver que esto suceda... si necesita preguntas, no dude en enviarme un ping o preguntar en #social en irc.w3.org

No dude en comunicarse conmigo en Mastodon si tiene alguna pregunta, inquietud o comentario sobre la biblioteca https://github.com/go-fed/activity que mencionó @jas99 . Obviamente, tengo un interés personal en el resultado de la decisión, pero me encantaría brindar información sincera sobre mis experiencias trabajando en la intersección go+ActivityPub. Estoy de acuerdo con @tboerger en que implementar ActivityPub en go es un precipicio.

¿Tal vez podríamos crear un nuevo repositorio llamado index y configurar el nuevo dominio index.gitea.io para hacer eso?

¿Por qué necesitamos un servidor de índices? @lunny

Sería increíble si pudiéramos tener diferentes proyectos discutiendo una implementación común del protocolo ActivityPub (es decir, usando la misma extensión para verbos, etc.). Esto permitiría a los usuarios de gitea, gogs y gitlab trabajar juntos sin problemas, al igual que los usuarios de varias plataformas de redes sociales que se federan pueden discutir sin problemas.

¿Podría ser este el lugar? -> https://github.com/git-federation/gitpub

@jaywink gran idea!

¡Esto sería increíble! Creo que Nextcloud (/Owncloud) es el ejemplo perfecto de cómo podría funcionar esto con la implementación ideal, como sugirió @JonasFranzDEV .

Con Nextcloud, si quiero compartir una carpeta con un usuario en otra instancia, puedo hacerlo fácilmente y configurar una carpeta compartida en ambas instancias.

Si pudiera hacer eso para un repositorio alojado en mi instancia de Gitea, otorgar a un usuario en otra instancia federada acceso al repositorio, con ese repositorio apareciendo en su interfaz de Gitea con capacidad total para interactuar con problemas, etc. (con alguna indicación clara en el UI que este repositorio estaba alojado en otra instancia), eso sería bastante sorprendente.

El objetivo que se discute de adoptar un estándar compartido entre Gitea y otros proyectos autohospedados de código abierto (como GitLab CE) definitivamente tiene sentido, y sería genial si se adoptara permitiendo la federación entre Gitea, Gogs, GitLab, etc. Migrar desde GitHub para proyectos privados es fácil y no se pierde nada, pero para los proyectos públicos de código abierto debemos reconocer que un gran beneficio de GitHub es la comunidad. He descubierto muchos proyectos en realidad en GitHub. Si hubiera alguna forma de federar proyectos populares, el feed de actividad de los usuarios (es decir, poder seguir a un amigo en otra instancia y seguir su actividad, proyectos que le gustan, teniendo en cuenta la configuración de privacidad, etc.) sería excelente, si eso fuera posible.

Las solicitudes de incorporación de cambios federadas serían un gran primer paso hacia esto (n.° 184) y, probablemente, la característica faltante más crucial en este momento.

11 meses desde el último comentario aquí... Me pregunto si todavía hay planes en marcha.

Cuando hay algún tipo de estándar acordado que sí

Las discusiones actuales están ocurriendo como parte del proyecto forgefed, así que síguelas si quieres saber más: https://github.com/forgefed/forgefed

Como mencionó @lafriks , una vez que hay un estándar acordado, varios proyectos pueden implementarlo.

La URL correcta para el proyecto falsificado ahora es https://notabug.org/peers/forgefed

Parece que esto debería ser de suma importancia ahora, considerando que github ahora está eliminando cuentas de personas de países enteros.

ForgeFed ahora también tiene un foro de discusión . Sería genial involucrar a alguien de Gitea.

+1 por esto. Trabajar desde una instancia autohospedada local pero no estar aislado debido a esa elección sería realmente lo mejor de ambos mundos.

El grupo de trabajo de ForgeFed necesitaría desesperadamente que los desarrolladores de las forjas actuales hicieran comentarios: https://talk.feneas.org/t/working-group-instructions/196

Solo me gustaría agregar que antes de que Microsoft inspirara una migración masiva fuera de Github, esta no habría sido una función excelente... AHORA lo es. Cada vez menos repositorios para proyectos de SO que estoy investigando están en Github ahora (PUEDE reflejarse aquí).

He leído que el historial de confirmación de Github puede leerse como un currículum vitae y que una de las razones por las que el mundo del software es tan móvil profesional es que una persona puede autoenseñar habilidades valiosas, DEMOSTRARLAS FÁCILMENTE (historial público de github) y, por lo tanto, calificar para mejores ganancias/etc. Si su historial de contribuciones se distribuye en docenas de servidores privados, es MUCHO menos visible/útil.

Además, cualquiera de esos servidores podría dejar de funcionar en cualquier momento y esa parte de su historial ya no está. Una implementación adecuada de los repositorios federados significaría que podría participar en docenas de proyectos en docenas de instancias (desde mi instancia) y si TODAS fallaran, todavía tendría mi 'perfil de git federado'.

Enlace a la hoja de ruta de ForgeFed (hay financiación para aquellos que trabajarán en ella):

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

Quizás, para una implementación simple, gitea podría ejecutar un nodo ipfs en segundo plano alojando archivos de repositorios locales (usando ipns para apuntar a las últimas versiones de los repositorios). Entonces podríamos tener una implementación de protocolo de chismes simple para encontrar otras instancias de gitea y obtener hashes de ipns y datos preliminares (estrellas, nombre).
El beneficio de usar ipfs sería que cuando los usuarios de una instancia deseen ver o bifurcar repositorios en otras instancias, contribuiría a alojar partes de ese repositorio y agilizaría el acceso al repositorio para la red en su conjunto.

El uso de ipfs/ipns también podría usarse para distribuir datos de usuario, como repositorios destacados, solicitudes de extracción, biografía, etc. Cada nodo solo almacenaría nombres y hashes de ipns para usuarios en otras redes que le interesan a la instancia y sería trivial solicitarlo. datos de perfil para usuarios desconocidos.

ipfs ya tiene una implementación de go y, por ejemplo, se podría usar el descubrimiento de algo como esto .

No hay ningún requisito para el almacenamiento punto a punto aquí, lo que describe no parece necesario ni relacionado con el problema en cuestión. No creo que haya interés en alejarse del formato de almacenamiento y protocolo de transferencia de Git. Tal vez debería abrir un problema separado si ve un beneficio aquí (ciertamente no lo veo).

No hay ningún requisito para el almacenamiento punto a punto aquí

Creo que gitea se beneficiaría enormemente del intercambio de repositorios entre pares, de modo que los repositorios populares serían redundantes en el caso de que las instancias se caigan. Si bien alguien puede simplemente duplicar un repositorio en su propia instancia, fragmentaría el desarrollo de un proyecto si no hay un lugar central para comprometerse. Si el protocolo git estuviera en capas en IPFS, permitiría la deduplicación al bifurcar proyectos en una sola instancia (por lo que no sería necesario almacenar una copia completa).

lo que describe no parece necesario ni relacionado con el problema en cuestión.

La razón por la que la federación es tan útil (y por la que la gente la quiere tanto) es que permite la colaboración entre instancias. El Sistema de nombres interplanetarios (IPNS) tiene un comportamiento idéntico al de OpenID porque se puede usar para identificar a un usuario que tiene permiso para actualizar ciertos datos (por ejemplo, sus repositorios y su perfil personal). Una dirección IPNS podría identificar de manera única a un usuario de otra instancia sin tener que vincular necesariamente a ese usuario a una instancia específica. Pongamos un ejemplo:
Alice es autohospedadora de una instancia de gitea en aliceland.net
Cuando Alice crea una nueva cuenta, gitea crea un perfil vacío, lo aloja en IPFS y luego genera una dirección IPNS única que apunta a ese perfil. Siempre que Alice cree un nuevo repositorio o actualice su perfil de alguna manera, gitea (detrás de escena) creará un nuevo registro IPFS, quitará el antiguo y le reasignará la dirección IPNS de Alice.
Ahora digamos que Bob quiere enviar una solicitud de fusión desde su espejo del repositorio en bobland.net a aliceland.net.
Cuando Bob originalmente bifurcó el repositorio de Alice a bobland.net, anotó el IPNS del repositorio de Alice, así como la ubicación IPFS de la confirmación desde la que se bifurcó.
Cuando Bob quiere abrir una solicitud de fusión, escribe su mensaje y luego bobland.net pondrá las siguientes cosas en un bloque IPFS:

• Dirección de usuario IPNS de Bob
• La dirección IPFS de las confirmaciones que Bob quiere obtener
• La dirección IPFS de la confirmación en el repositorio de Alice que debe modificarse
• Mensaje y título de Bob para la solicitud de fusión
• Firma de datos con clave de perfil IPNS privada de Bob

Bobland.net luego enviará la dirección IPFS a aliceland.net, que luego puede optar por ignorarla por completo, O analizar la dirección, verificar las confirmaciones, crear una dirección IPNS para el hilo de comentarios (que apunta a todos los comentarios) y luego notificar Alice que un tipo llamado Bob en la instancia Bobland.net ha enviado una solicitud de fusión para 3 confirmaciones sobre IPFS. Los comentarios también estarían alojados en IPFS y accesibles a través de una dirección IPNS.
Este patrón de uso de IPNS para datos mutables (como un hilo de comentarios) e IPFS para datos inmutables (como comentarios y confirmaciones) se puede aplicar para la mayoría de las federaciones entre instancias.

No creo que haya interés en alejarse del formato de almacenamiento y protocolo de transferencia de Git.

Este enfoque de la federación no tendría que alejarse del formato Git. Git simplemente se puede colocar en capas y almacenar en ifps (al mismo tiempo que se aprovecha la deduplicación). El sistema Merkle Tree de Git no necesariamente tiene que estar integrado con IPFS (aunque eso sería genial) y el protocolo de transferencia de git seguiría siendo el mismo, IPFS simplemente moderaría la comunicación entre instancias.

¿Puedes abrir un problema aparte? Este se trata de algo específico, y ForgeFed ya está trabajando en un protocolo. Mejor aún, plantéelo con ellos.

Acumular problemas con comentarios como "¿qué pasa con ipfs/filecoin/blockchain" simplemente parece grosero.

+1

GitLab también está discutiendo esta función: https://gitlab.com/gitlab-org/gitlab/-/issues/6468

Hice ping en la discordia de gitea dev hace unos días como información y he estado tratando de comunicarme de manera proactiva con algunas de las personas detrás de ForgeFed, ya que con go-fed v1 está hecho y documentado, sería bueno obtener una instancia. de gitea federada en ActivityPub aunque no es un esfuerzo menor. Creo que la gente de Gitea está ocupada con otras prioridades atm. Desafortunadamente, no he tenido éxito en comunicarme con ninguna de las personas de ForgeFed. :(

Algunos de nosotros en la comunidad de ActivityPub, que salimos de APConf2020, estamos experimentando con un proceso de documentación ligero de base en una instancia de gitea y se siente extraño no poder federarse con él todavía.

Git ya tiene todas las funciones necesarias para la duplicación descentralizada, la única funcionalidad que falta es la necesaria para coordinarlo, que es exactamente lo que hace ForgeFed. IPFS no tiene necesidad de estar aquí, y dado lo desastroso que fue el lanzamiento de su red principal, no estoy seguro de que sea seguro vincularse profundamente con otros proyectos de Protocol Labs.

Estoy interesado en colaborar en alguna de las iniciativas existentes. Intentemos armar un grupo de trabajo. Puede sugerir este canal de Matrix para una mayor discusión #notable:tincan.community