Gitea: Федерация для организации, репозиториев и пользователей

Вероятно, этого будет достаточно для поддержки федеративных репозиториев.

@kolaente Функция федерации имеет смысл для пользователей. Если вы хотите поделиться репозиториями, вы должны использовать функцию зеркала. Но менеджеру проекта было бы очень удобно добавлять пользователей из других экземпляров git.

См. также #184 (это дубликат?)

@strk вроде как, но я думаю, что это идет дальше

@strk Вроде . Но эта проблема включает в себя полную интеграцию функции федерации для организации не только запросов на вытягивание.

Вы имеете в виду для авторизации удаленных пользователей?
Поскольку я считаю полезным разделить «федерацию» на множество различных мелких
вещи, которые нужно реализовать, иначе один билет станет слишком большим.

@strk Я согласен с идеей разделить эту вещь на множество билетов. Этот билет может быть билетом федерации пользователей, не так ли? Но я не хочу аутентификации для пользователей других платформ. Я хочу иметь возможность добавлять других пользователей. Пользователь получит приглашение от экземпляра Gitea пользователя. Он получит доступ к репозиторию или организации из своего экземпляра.

Предоставление разрешений кому-либо в федерации требует возможности
идентифицировать этого человека (глобальный адрес). Как вы упомянули owncloud I
думаю, что owncloud использует "@" в качестве идентификатора, но я не знаю, что
протокол, который он использует для этого. Friendica/GNUSocial и другие реализации OStatus
федерации также могут использовать "@"сопоставление с чем-то другим через
стандарт Webfinger (который открыт для указания различных
протоколы). Другое сообщество (IndieWeb, см. indieweb.org) использует
веб-адреса для идентификации людей, как это используется с OpenID до версии 2.0.
Новый OpenID (OpenID-Connect) снова использует Webfinger.

Я думаю, что стандарт webfinger может быть хорошим решением. Но я думаю, что это также может конфликтовать с электронной почтой git пользователя.

Где конфликт?

Скорее, что мне не нравится в Webfinger, так это то, что ему нужно контролировать
корень домена (которого у вас нет с URL-адресом OpenID).

Что касается того, «какой стандарт мы хотим выбрать», я просто хочу указать вам на ActivityPub , который в настоящее время дорабатывается рабочей группой Social Federation W3C. Некоторые проекты, реализующие его (или в настоящее время работающие над этим), — это pump.io, Mastodon и MediaGoblin.

Они не используют WebFinger, так как им не нравится идея фиксированного .хорошо известного пути, но есть идеи о совместимости .

Эта функция действительно изменит правила игры; keybase.io недавно выпустил зашифрованный git на стороне клиента, это тоже интересно.

Просто хочу отметить, что ActivityPub теперь готов.

Добавление поддержки AP сделает Gitea совместимой с растущим числом федеративных серверов, таких как Mastodon, PeerTube, NextCloud и HubZilla, значительно расширив охват, не говоря уже о выдающемся отличии от GitLab.
У него также есть потенциал свергнуть GitHub в качестве хостинга для проектов с открытым исходным кодом, поскольку большинство из них здесь для рабочего процесса запросов на вытягивание сообщества, который AP разрешил бы децентрализованным образом, повысив конфиденциальность и устранив единую точку отказа для большой процент сообщества свободного программного обеспечения.

В любом случае, я надеюсь, что это будет реализовано, это может стать революционным!

Как уже говорилось в чате, ActivityPub in go — это PITA, потому что это сложно сделать на статическом языке, таком как go.

@tboerger Интересно. Спецификация ActivityPub — объектно-ориентированный объект с большим количеством наследования, но его можно моделировать в Go с встраиванием структур, однако, насколько мне известно, в Rust нет ничего похожего на serde (https://docs.serde. rs/serde_json/value/index.html), что значительно упрощает работу, однако есть некоторые усилия по реализации ActivityPub в Go, что может быть хорошим началом, поскольку он не только уже реализует синтаксический анализ json-ld , но и определяет основной словарь для ActivityStreams.

О каких конкретно неприятностях вы здесь думаете?

@MatejLach Другой проект https://github.com/go-fed/activity

Соответствующее предложение в репозитории gogs:
https://github.com/gogs/gogs/issues/4437

В репозитории Gitlab:
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

Привет! Соредактор ActivityPub здесь. В данный момент я довольно занят, но я хотел бы, чтобы это произошло... если вам нужны вопросы, не стесняйтесь пинговать меня или задавать в #social на irc.w3.org

Пожалуйста, не стесняйтесь обращаться ко мне на Mastodon с любыми вопросами/проблемами/комментариями, связанными с библиотекой https://github.com/go-fed/activity , которую упомянул @jas99 . Я, очевидно, заинтересован в исходе решения, но был бы рад предоставить откровенную информацию о моем опыте работы на перекрестке go+ActivityPub. Я согласен с @tboerger в том, что внедрение ActivityPub в Go — это крутой обрыв.

Может быть, мы могли бы создать новый репозиторий с именем index и настроить для этого новый домен index.gitea.io?

Зачем нам индексный сервер? @лунни

Было бы здорово, если бы у нас были разные проекты, обсуждающие общую реализацию протокола ActivityPub (т. е. использование одного и того же расширения для глаголов и т. д.). Это позволит пользователям gitea, gogs и gitlab беспрепятственно работать вместе так же, как пользователи различных платформ социальных сетей, которые могут беспрепятственно обсуждать.

Может это место? -> https://github.com/git-federation/gitpub

@jaywink отличная идея!

Это было бы потрясающе! Я думаю, что Nextcloud (/Owncloud) — прекрасный пример того, как это может работать с идеальной реализацией, как предложил @JonasFranzDEV .

С Nextcloud, если я хочу поделиться папкой с пользователем в другом экземпляре, я могу легко это сделать и настроить общую папку для обоих экземпляров.

Если бы я мог сделать это для репозитория, размещенного на моем экземпляре Gitea, предоставив пользователю другого федеративного экземпляра доступ к репозиторию, при этом этот репозиторий затем появился бы в их интерфейсе Gitea с полной возможностью взаимодействовать с проблемами и т. д. (с некоторым четким обозначением в пользовательского интерфейса, что это репо было размещено в другом экземпляре), это было бы довольно удивительно.

Обсуждаемая цель принять общий стандарт между Gitea и другими самостоятельными проектами с открытым исходным кодом (такими как GitLab CE) определенно имеет смысл, и было бы здорово, если бы это было принято, разрешая федерацию между Gitea, Gogs, GitLab и т. д. Миграция с GitHub для частных проектов проста и ничего не теряется, но для общедоступных проектов с открытым исходным кодом мы должны признать большое преимущество GitHub — это сообщество. На самом деле я обнаружил много проектов на GitHub. Если бы существовал какой-то способ объединения популярных проектов, лента активности пользователей (т. е. возможность подписаться на друга в другом экземпляре и следить за его активностью, понравившимися проектами, с учетом настроек конфиденциальности и т. д.) была бы превосходной — если бы это было возможно.

Федеративные запросы на вытягивание могли бы стать отличным первым шагом к этому (#184) и, вероятно, самой важной отсутствующей функцией на данный момент.

11 месяцев с момента последнего комментария здесь .. Мне интересно, есть ли еще планы?

Когда есть какой-то согласованный стандарт, чем да

Текущие обсуждения происходят в рамках проекта forgefed, поэтому следите за ними, если хотите узнать больше: https://github.com/forgefed/forgefed .

Как упомянул @lafriks , когда есть согласованный стандарт, его могут реализовать различные проекты.

Правильный URL-адрес для проекта forgefed теперь https://notabug.org/peers/forgefed .

Похоже, что сейчас это должно иметь первостепенное значение, учитывая, что github теперь удаляет учетные записи людей из целых стран.

ForgeFed также теперь имеет дискуссионный форум . Было бы здорово привлечь кого-нибудь из Gitea.

+1 за это. Работа из локального экземпляра, размещенного самостоятельно, но не изолированного из-за этого выбора, действительно была бы лучшим из обоих миров.

Рабочая группа ForgeFed отчаянно нуждается в комментариях разработчиков из текущих кузниц: https://talk.feneas.org/t/working-group-instructions/196 .

Я просто хотел бы добавить, что до того, как Microsoft вдохновила массовую миграцию с Github, это не было бы убийственной функцией ... ТЕПЕРЬ это так. Все меньше и меньше репозиториев для проектов ОС, которые я изучаю, сейчас находятся на Github (МОЖЕТ быть отражено здесь).

Я читал, что история коммитов Github может читаться как резюме, и что одна из причин того, что мир программного обеспечения настолько мобильен в карьере, заключается в том, что человек может самообучаться ценным навыкам, ЛЕГКО ДЕМОНСТРАТИРОВАТЬ их (общедоступная история github) и, таким образом, претендовать на более высокий заработок/и т. д. Если ваша история вкладов разбросана по десяткам частных серверов, она НАМНОГО менее заметна/полезна.

Кроме того, любой из этих серверов может выйти из строя в любое время, и эта часть вашей истории исчезла. Правильная реализация федеративных репозиториев означала бы, что я мог бы участвовать в десятках проектов на десятках экземпляров (из моего экземпляра), и если бы они ВСЕ вышли из строя, у меня все еще был бы мой «федеративный профиль git».

Ссылка на дорожную карту ForgeFed (есть финансирование для тех, кто будет над ней работать):

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

Возможно, для простой реализации gitea может запустить узел ipfs в фоновом режиме, на котором размещены файлы локального репозитория (используя ipns для указания на последние версии репозиториев). Затем у нас может быть простая реализация протокола сплетен , чтобы найти другие экземпляры gitea и получить хэши ipns и предварительные данные (звезды, имя).
Преимущество использования ipfs заключается в том, что когда пользователи в одном экземпляре хотят просматривать или разветвлять репозитории в других экземплярах, это будет способствовать размещению частей этого репозитория и ускорит доступ к репозиторию для сети в целом.

Использование ipfs/ipns также можно использовать для распространения пользовательских данных, таких как помеченные репозитории, запросы на вытягивание, биографии и т. д. Каждый узел будет хранить только имена и хэши ipns для пользователей в других сетях, о которых заботится экземпляр, и запрос будет тривиальным. данные профиля для неизвестных пользователей.

У ipfs уже есть готовая реализация , и, например, можно использовать обнаружение чего-то подобного .

Здесь нет требований к одноранговому хранилищу, то, что вы описываете, не кажется необходимым или даже не связано с рассматриваемой проблемой. Я не думаю, что есть интерес к отказу от формата хранения Git и протокола передачи. Может быть, вам стоит открыть отдельную тему, если вы видите здесь выгоду (я, конечно, не вижу).

Здесь нет требований к одноранговому хранилищу.

Я думаю, что gitea сильно выиграет от однорангового обмена репозиториями, чтобы популярные репозитории были избыточными в случае выхода экземпляров из строя. Хотя кто-то может просто отразить репозиторий в своем собственном экземпляре, это приведет к фрагментации разработки проекта, если нет центрального места для фиксации. Если бы протокол git был наложен на IPFS, это позволяло бы выполнять дедупликацию при разветвлении проектов на одном экземпляре (поэтому не нужно было бы хранить всю копию).

то, что вы описываете, не кажется необходимым или даже не связано с рассматриваемой проблемой.

Причина, по которой федерация так полезна (и почему люди так этого хотят), заключается в том, что она позволяет осуществлять совместную работу между экземплярами. Межпланетная система имен (IPNS) ведет себя так же, как OpenID, поскольку ее можно использовать для идентификации пользователя, имеющего разрешение на обновление определенных данных (например, их репозиториев и личного профиля). Адрес IPNS может однозначно идентифицировать пользователя из другого экземпляра без обязательной привязки этого пользователя к конкретному экземпляру. Приведем пример:
Алиса самостоятельно размещает экземпляр gitea на aliceland.net.
Когда Алиса создает новую учетную запись, gitea создает пустой профиль, размещает его в IPFS, а затем генерирует уникальный IPNS-адрес, указывающий на этот профиль. Всякий раз, когда Алиса создает новый репозиторий или каким-либо образом обновляет свой профиль, gitea (за кулисами) создает новую запись IPFS, открепляет старую и переназначает ей IPNS-адрес Алисы.
Теперь предположим, что Боб хочет отправить запрос на слияние со своего зеркала репозитория на bobland.net на aliceland.net.
Когда Боб первоначально разветвлял репозиторий Алисы на bobland.net, он записал IPNS репозитория Алисы, а также местоположение IPFS коммита, из которого он разветвился.
Когда Боб хочет открыть мерж-реквест, он пишет свое сообщение, а затем bobland.net помещает в блок IPFS следующие вещи:

• Адрес пользователя IPNS Боба
• IPFS-адрес коммитов, которые Боб хочет получить
• IPFS-адрес коммита в репозитории Алисы, который следует изменить.
• Сообщение и заголовок Боба для запроса на слияние
• Подпись данных с закрытым ключом профиля IPNS Боба

Затем Bobland.net отправит IPFS-адрес на aliceland.net, который затем может полностью игнорировать его, ИЛИ проанализировать адрес, проверить коммиты, создать IPNS-адрес для потока комментариев (который указывает на все комментарии), а затем уведомить Алиса, что какой-то парень по имени Боб на экземпляре Bobland.net отправил запрос на слияние для 3 коммитов через IPFS. Комментарии также будут размещены в IPFS и доступны через адрес IPNS.
Этот шаблон использования IPNS для изменяемых данных (таких как цепочка комментариев) и IPFS для неизменяемых данных (таких как комментарии и фиксации) может применяться для большинства федераций между экземплярами.

Я не думаю, что есть интерес к отказу от формата хранения Git и протокола передачи.

Такой подход к федерации не должен отходить от формата Git. Git можно просто разделить на слои и хранить на ifps (при этом также используя преимущества дедупликации). Система Git Merkle Tree не обязательно должна быть интегрирована с IPFS (хотя это было бы круто), и протокол передачи git останется прежним, IPFS просто модерирует связь между экземплярами.

Может просто отдельную тему открыть? Это о чем-то конкретном, и ForgeFed уже работает над протоколом. А еще лучше, поднимите его вместе с ними.

Нагромождение вопросов с комментариями типа «а как насчет ipfs/filecoin/blockchain» просто кажется грубым.

+1

GitLab также обсуждает эту функцию: https://gitlab.com/gitlab-org/gitlab/-/issues/6468 .

Несколько дней назад я пинговал дискорд разработчиков gitea в качестве информации для вашего сведения и активно пытался связаться с некоторыми из людей, стоящих за ForgeFed, так как с готовой и документированной версией go-fed v1 было бы неплохо получить экземпляр gitea интегрирована в ActivityPub, хотя это немалые усилия. Я думаю, что ребята из gitea заняты другими приоритетами. К сожалению, мне не удалось связаться с кем-либо из сотрудников ForgeFed. :(

Некоторые из нас в сообществе ActivityPub, вышедшие из APConf2020, экспериментируют с упрощенным процессом документирования на экземпляре gitea, и кажется странным, что пока нет возможности федерировать его.

Git уже имеет все функции, необходимые для децентрализованного зеркалирования, единственная недостающая функциональность — это то, что необходимо для его координации, что и делает ForgeFed. IPFS не нужно быть здесь, и, учитывая, как катастрофически прошел их запуск основной сети, я не уверен, что безопасно глубоко связываться с другими проектами Protocol Labs.

Я заинтересован в сотрудничестве по любой из существующих инициатив. Давайте попробуем собрать рабочую группу. Могу предложить этот канал Матрицы для дальнейшего обсуждения #незаслуживающий внимания:tincan.community