Gitea: Подготовка к федерации: «Удаленные» пользователи / Federated ID

На самом деле это действительно зависит от того, что будет делать федеративный / внешний пользователь. Если они не могут размещать репозитории, то можно иметь объединенную таблицу пользователей и перемещать в нее отображаемое имя, имя пользователя и т. Д. Через это потребовалось бы полностью переписать каждую часть кода, где теперь используется таблица локальных пользователей, чтобы теперь использовать объединенную таблицу пользователей, что может быть адской работой :)

Я полностью согласен с @lafriks. Прежде чем мы начнем это делать, нам нужно знать несколько вопросов:

1. Кому нужна эта функция? Личный пользователь gitea / компании с частным gitea / веб-сайт хостинга Git через gitea или другие?
2. Зачем им эта функция?
3. Как они хотят использовать эту функцию?

Если они не могут размещать репозитории, то можно иметь объединенную таблицу пользователей и перемещать в нее отображаемое имя, имя пользователя и т. Д.

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

1. Кому нужна эта функция? Личный пользователь gitea / компании с частным gitea / веб-сайт хостинга Git через gitea или другие?

Людям вроде меня, которым не нравится идея разработки бесплатного программного обеспечения с открытым исходным кодом, централизованного, ну, централизованных, платных сервисов. (GitHub)

1. Зачем им эта функция?

Хотя существуют бесплатные альтернативы, такие как Gitea и GitLab, их экземпляры изолированы друг от друга и поэтому имеют недостатки использования. (И подвержены сетевым эффектам.)
Даже если у меня есть мотивация создать учетную запись, скажем, в Debian GitLab, она ограничена этим экземпляром.
В худшем случае у каждого проекта есть собственный экземпляр, и мне нужно проверить так много учетных записей. (Да, есть уведомления по электронной почте, но нам нужно что-то в Интернете, иначе Git + ML тоже будет достаточно.)

1. Как они хотят использовать эту функцию?

Для федеративного сотрудничества нарушение сетевого эффекта GitHub.

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

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

Это правильно, что

• Name - это имя пользователя ( criztovyl ) и
• FullName - отображаемое имя ("Кристоф Шульц")

?

Но в чем причина LowerName ? ( strings.ToLower(u.Name) )

Чтобы не использовать lower(Name) в SQL-запросах.

Чтобы не использовать lower(Name) в SQL-запросах.

Но зачем вообще? Не хочу менять, просто пойми. :)

Я начал немного играть и тупо переместил некоторые атрибуты из user.go (тип User ) в новый user_identity.go (тип Identity ) и добавил код в AfterLoad который заполняет старые атрибуты значениями из идентификатора.

Впоследствии я столкнулся с проблемами при написании миграции, которая перемещает атрибуты с User на Identity . Я подробнее рассмотрю это, изучив существующие миграции и документацию xorm, но был бы очень рад дальнейшим подсказкам. :)

Я поделюсь некоторыми коммитами в следующий раз.

Но зачем вообще? Не хочу менять, просто пойми. :)

Поскольку имя пользователя не чувствительно к регистру, и когда пользователь отправляет такие запросы, как https://try.gitea.io/AxIFiVe или https://try.gitea.io/Axifive, необходимо быстро найти уникального пользователя, поэтому мы просто вызываем strings.ToLower(username) и отправляет простой SQL-запрос.
Преобразование полей в нижний регистр для выбора - очень дорогая операция БД, гораздо проще добавить второе поле.

Я обещал код.

Я просто вставил код, с которым борюсь, вы можете найти его здесь: https://github.com/criztovyl/gitea/blob/master/models/migrations/v200.go (200, чтобы упростить слияние / ребазинг)

Строка 30, синхронизация модели Identity, работает должным образом: таблица создана.
Но строка 35, синхронизация модели User, похоже, не работает, таблица все еще имеет старые столбцы после этого.

Sync2 добавит только столбцы.

Если вы хотите удалить столбцы, вам необходимо использовать:

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

Обратите внимание, что миграции не должны относиться к вещам в моделях или где-либо еще - они могут быть изменены в будущих миграциях. Они должны быть полностью автономными - никаких ссылок на другой код Gitea.

Так:

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

Здесь вам действительно нужно иметь копию удостоверения личности. Аналогично здесь:

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

Вероятно, это должно было быть xorm: "-" в этом случае он, вероятно, не нужен при миграции.

Глядя на предложенную вами таблицу идентификаторов, почему вы не можете использовать для этого login_source?

Спасибо за подсказки :)

Проблема с login_source, насколько я ее проанализировал, заключается в том, что она по-прежнему требует, чтобы имена пользователей были уникальными.

Для федерации имена пользователей не уникальны, а только Identity (где уникальным идентификатором для таких идентификаторов обычно является URI / IRI); имена пользователей больше похожи на ограниченное отображаемое имя.

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

Вероятно, это должно было быть xorm: "-" в этом случае он, вероятно, не нужен при миграции.

Понятно, но как заполнить Identity, на которую ссылается IdentityId? Это автоматически или мне нужно куда-то добавить?

И если я создам таблицу изначально, мне все равно понадобится модель Identity, поэтому я не могу ее оставить, верно?

И еще один быстрый вопрос; Можно ли запустить экземпляр gitea, у которого есть все тестовые данные из фикстур в его базе данных?

Иногда я отношусь к визуальному типу. Например, я хотел бы убедиться, что профиль по-прежнему отображается правильно, например, имеет правильные организационные назначения.

Вы можете взглянуть на https://github.com/go-gitea/gitea/blob/master/contrib/pr/checkout.go, поскольку он загружает приспособления, чтобы помочь нам проверять PR.

Возможно, вы могли бы сделать модифицированную версию.

go run -tags "sqlite sqlite_unlock_notify" contrib/pr/checkout.go -run работает как шарм :)

кроме того, что у меня нет горячей перезагрузки кода, но я думаю, что это немного сложнее: D

Я полностью согласен с @lafriks. Прежде чем мы начнем это делать, нам нужно знать несколько вопросов:

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?

Личное

Личное использование, это определенно очень хорошая функция. У меня есть экземпляр, в котором я храню свои репозитории, общедоступные и частные (не все, а много). Если кто-то хочет сотрудничать над ними, он должен получить пользователя на моем экземпляре, и в остальном он работает так же, если я вижу проект где-то в экземпляре Gitea и хочу сотрудничать, например, исправить что-то или разрешить запрос функции, я нужно получить там пользователя или отправить электронное письмо с запросом на перенос со ссылками на diff / ref.

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

Корпоративный

Я не знаю, будут ли компании использовать это, но я вижу потенциальные возможности. Прямо сейчас большинство компаний используют GitHub, потому что у всех есть пользователь GitHub, и они могут управлять разрешениями / командами. Как (гипотетическая) компания, если я могу разместить свою собственную Gitea, где я могу приглашать других пользователей с пользователем Gitea из разных экземпляров, объединять их в команды и давать им разрешения, которые потенциально могут начать новую эру, когда компания может безопасно сказать «Да» мы можем использовать Gitea, потому что каждый может получить один самостоятельно ", особенно когда большие группы / воины с федерацией могут предоставить экземпляры Gitea для пользователей, которые не могут размещать свои собственные, например, Mastodon имеет много экземпляров, и вы можете выбрать один, используйте один и достигните всего, что хотите.

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

Кому нужна эта функция? Личный пользователь gitea / компании с частным gitea / веб-сайт хостинга Git через gitea или другие?

Как личный пользователь…

Зачем им эта функция?

Я не хочу создавать учетную запись в бесчисленных тысячах случаев,

Как они хотят использовать эту функцию?

просто чтобы сообщить о проблеме. Вот почему я часто не сообщаю об этом. Могу ли я сделать это из экземпляра, в котором у меня уже есть учетная запись, независимо от того, где размещен рассматриваемый репозиторий, все будет выглядеть по-другому.

Кстати: то же самое относится к «минимальным PR / MR», содержащим одноразовые исправления. Короче говоря: если я не планирую «по-настоящему присоединиться» к проекту, но все же внесу свои 2 цента.

Я полностью согласен с @lafriks. Прежде чем мы начнем это делать, нам нужно знать несколько вопросов:

1. Кому нужна эта функция? Личный пользователь gitea / компании с частным gitea / веб-сайт хостинга Git через gitea или другие?

Я личный пользователь Gitea, который сотрудничает с другими людьми, такими как @ a1batross. У нас обоих есть собственные экземпляры Gitea, но я хотел бы легко иметь возможность добавлять код в один из его репозиториев, например, с помощью запроса на перенос между экземплярами.

1. Зачем им эта функция?

Намного проще, чем создать учетную запись в другом экземпляре - и таким образом вам не нужно иметь открытую регистрацию, чтобы принимать код от других. Мне не нужен миллион аккаунтов Gitea.

1. Как они хотят использовать эту функцию?

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

1. Кому нужна эта функция? Личный пользователь gitea / компании с частным gitea / веб-сайт хостинга Git через gitea или другие?

Личный, потому что я думаю, что это в основном поможет уменьшить количество активных учетных записей для них.

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

1. Зачем им эта функция?

Чтобы легче было вносить вклад в зарубежные проекты, вам не нужно создавать учетную запись, чтобы сообщить о проблеме, связанной с быстрым исправлением.

1. Как они хотят использовать эту функцию?

Я бы хотел использовать его, чтобы иметь только один идентификатор git, а не тонну учетных записей в репозиториях Git, связанных с разными местами.

Я хотел бы иметь возможность делать все, что я сейчас делаю на Gittea, GitHub и GitLab, в одном месте. Это проблемы, запросы на извлечение / слияние, организации.

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

Частный. Запуск моего собственного сервера Git делает мои проекты менее доступными из-за меньшей инфраструктуры. Децентрализация и взаимодействие с Github / GitLab делает мои проекты такими же доступными и доступными, как если бы они были на этих платформах. Нет необходимости в том, чтобы у всех были учетные записи на моем сервере, что делает его более привлекательным для участников.

2. Why they need this feature?

Полная интеграция. Используйте интерфейс, с которым хотите совместно работать над понравившимися проектами.

3. How they want to use this feature?

Централизованный контроль на моих серверах и взаимодействие CI или других облачных сервисов с любым программным обеспечением для хостинга дает мне лучшие функции, которые я хочу. Нет необходимости, чтобы все были совместимы со всеми различными API GitLab / GitHub / Gitea и всеми более мелкими.

Копирование отзывов fediverse от fr33domlover (команда ForgeFed) :

Текущая ситуация такова, что для взаимодействия с репо, размещенным на кузнице, такой как Gitea, GitLab или githu8 и т. Д., Вам необходимо иметь там учетную запись. Каждый сайт кузницы - это отдельный остров.

Если у вас есть собственная кузница, вы можете устанавливать правила и т. Д., Но вы изолированы. Тебя труднее найти. Многие люди опасаются, что они получат меньше взносов, если покинут githu8. Также от участников потребуется создать учетную запись в каждой кузнице.

А githu8 является проприетарным и централизованным и не является проектом сообщества людей для людей.

Идея состоит в том, что видимость вашего проекта и доступ к нему не будут зависеть от того, находится ли учетная запись пользователя в вашей кузнице или какой-либо другой. Вы можете создать одну учетную запись и участвовать везде. Поиск по проектам, открытие, рекомендации и т. Д. Находите материалы по всей сети. Ни одна кузница не имеет большей власти над пользователями, чем любая другая.

Примеры:

• Организации / команды / группы могут включать пользователей из разных кузниц
• Вы можете отправлять коммиты в репозиторий на разных кузницах
• Вы можете открывать проблемы, открывать запросы на слияние, комментировать, отправлять обзор кода и т. Д. Через кузницы.
• Репозиторий, серверы CI, вики, системы отслеживания проблем и т. Д. Могут находиться на разных серверах и при этом без проблем работать вместе.

1. Как они хотят использовать эту функцию?

В дополнение к тому, что уже упоминалось другими: во время серфинга в Интернете я сталкиваюсь с множеством интересных проектов, которые существуют в отдельном экземпляре экземпляра gitea / gitlab. Я часто просто хочу отметить эти репо, но трение здесь (регистрация) слишком велико. Вместо этого я добавляю их в закладки в своем браузере и чаще всего забываю проверить их позже (слишком много закладок).

На github я использую звезды как для создания закладок, так и в знак признательности проекту. Я наблюдаю за проектами, представляющими особый интерес, поэтому у меня есть панель уведомлений как простой способ отслеживать активность.

Звезды можно злоупотреблять, но если репозиторий github имеет, скажем, 14 тысяч звезд, это говорит о его популярности, и я могу быть достаточно уверен, что проект полезен и хорошего качества. На gitea / gitlab звезды пока мало что говорят мне.

В идеале в будущем у меня будет одно - мое собственное - всесторонне связанное место, где у меня будет обзор всех моих действий по кодированию, независимо от того, где я их выполнял.

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

Я личный пользователь Gitea
У меня есть два экземпляра Gitea, один для моего арт-коллектива (где мы храним код для наших проектов), а другой для меня (где я выполняю свою личную и контрактную работу, а также некоторые проекты с моими учениками)

2. Why they need this feature?

В основном потому, что я не хочу использовать GitHub или его конкурентов.
Эта цепочка вопросов является хорошим примером, всем нам нужны учетные записи GitHub, чтобы иметь возможность участвовать в беседе, тогда как с федерацией мы могли бы использовать наши федеративные учетные записи.

3. How they want to use this feature?

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

Повторяя то, что говорят многие другие пользователи, я хотел бы иметь возможность позволить людям легко вносить свой вклад в мои проекты, даже просто создавая проблемы, без необходимости открывать регистрации на моем сервере, и я хотел бы быть возможность создавать проблемы или вносить крошечные вклады без хлопот по созданию дополнительных учетных записей
В идеальном мире у меня больше не было бы аккаунта GitHub

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

Я все 3.

1. Я личный пользователь gitea (время от времени, в основном выключено, см. Ответ на часть 2).
2. В моем дневном задании есть (несколько!) Внутренних / частных экземпляров gitea.
3. Я бы подумал о предоставлении частного (т.е. доступного только для приглашения) веб-сайта git-хостинга через gitea (который я бы также использовал лично), если бы был вариант forgefed.

2. Why they need this feature?

Как частный пользователь:
Выбор между размещением ваших данных на github, gitlab и «где-нибудь еще» очень серьезен.
Если я выберу github / gitlab, я буду зависеть от их решений как платформы и не могу контролировать свои данные.
Если я выберу что-то еще (например, свой собственный экземпляр gitea), мне будет сложно обнаружить проект [1], а для внесения взносов потребуется либо собственная учетная запись (так что теперь я являюсь хозяином веб-сайта? Это нехорошо), либо отправка электронной почты маршрут (который носит ограничительный характер, не всем нравится этот рабочий процесс).
Благодаря федерации (даже если она не обязательно подделана, но в идеале может взаимодействовать между различными службами), я получаю лучшее из обоих миров - можно вносить вклад из любого экземпляра, используя свои собственные учетные записи, и открывать для себя любой из моих локально размещенных проектов, пока я получаю держать под контролем мои данные и платформу.

В качестве корпоративного хоста:
Как я уже упоминал, у нас есть несколько экземпляров gitea по разным причинам.
Мы были бы заинтересованы в объединении в белый список (то есть в котором объединение разрешено только против определенных других серверов), чтобы облегчить обмены между нашими внутренними узлами и узлами произвольных программных партнеров, без необходимости предоставлять им внутренний доступ в любом случае.

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

3. How they want to use this feature?

В заключение / повторить:

Как частный пользователь (и хост веб-сайта, имея фактически таких пользователей):

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

Как корпоративный пользователь:

• белый список федерации:
  
  
  
  • разрешить внутреннюю связь между узлами различного назначения
  
  
  • разрешить связь с нулевым доверием и нулевыми привилегиями между нашими узлами и узлами различных партнеров по программному обеспечению
  
  

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

Да, как для моей личной gitea, так и для той, которую мы используем на работе.

2. Why they need this feature?

Для совместной работы над проектами на других подделанных экземплярах. Нет необходимости создавать учетную запись пользователя в каждой системе. В случае моего частного экземпляра я бы не хотел предоставлять доступ случайным людям. А в случае компании, очевидно, не сотрудники не могут получить доступ.

3. How they want to use this feature?

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

1. Кому нужна эта функция? Личный пользователь gitea / компании с частным gitea / веб-сайт хостинга Git через gitea или другие?

Личный пользователь определенно.

1. Зачем им эта функция?

Открытый исходный код - это все о сотрудничестве. GitHub сделал открытый исходный код мейнстримом, сделав работу над кодом социальной вещью и упростив сообщение о проблемах и внесение вклада в проекты. Хотя децентрализация пространства, в котором находится GitHub, - это хорошо, с одной стороны, мы идем в обратном направлении с точки зрения упрощения отправки проблем или исправлений.

1. Как они хотят использовать эту функцию?

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

Как-то GitHub не присылал мне никаких уведомлений о новых комментариях здесь, я их полностью пропустил.

В любом случае, я продолжаю играть в фоновом режиме, сейчас я борюсь с xorm и нетерпеливой загрузкой.

У меня есть:

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:"-"`
}

Как мне сделать e.Get(&User{Slug: slug}) автозагрузкой (?) Identity заданного IdentityId ?

Я не думаю, что это сработает. Я думаю, что xorm может сделать только наоборот, т.е. если Identity имел столбец UserID , xorm мог бы заполнить срез Identities в User .

Если xorm достаточно равен gorm, вы должны просто иметь возможность предварительно загрузить столбец Identities, чтобы это произошло. В обычном SQL это будет JOIN, поэтому http://gobook.io/read/gitea.com/xorm/manual-en-US/chapter-05/5.join.html должно помочь.

Что-то вроде образца

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})

Должен сделать трюк в соответствии с документами.

Хм, для моей проблемы наличие списка идентификаторов не помогает.
И, к сожалению, подход Join-Approach тоже не работает.

Я еще немного посмотрел в кодовой базе и обнаружил, что Repository имеет Owner *User который кажется загруженным вручную с помощью функции GetOwner , я применил тот же шаблон к своему коду Теперь. :)

Итак, я очистил свой локальный репозиторий, зафиксировал и опубликовал черновую версию разделения пользователей и идентификаторов, которая работает для отображения профиля локальных пользователей, например localhost: 8080 / user1. :) См. Https://github.com/criztovyl/gitea/commit/d0f24f7919d15ee481f5eae7ec6131ff369eaa66
Пока это работает только для пользователей, организации пока не работают.
Это немного, но это что-то. :)

После того, как убрали все мясо, которое есть у организаций, страница профиля организации теперь тоже работает. См. Https://github.com/criztovyl/gitea/compare/d0f24f7...3901206bc.

Мой код скорее эксплуататорский, в нем нет ничего окончательного. :)

Почему бы не добавить два столбца в таблицу пользователей: is_local и remote_url (возможно, domain тоже, хотя не все экземпляры gitea размещаются в основной папке определенного домена, поэтому почему Я пошел с romain_url )? Таким образом, дополнительная таблица и объединения не нужны.

Это не первый раз, когда кто-то это предлагает, я тоже об этом подумал.
Но я боюсь (ред.), Что это может легко привести к случайному сравнению пользователя только по имени пользователя, что недопустимо, потому что вы должны (в этом конкретном случае) сравнить все три is_local , remote_url и username (можно оптимизировать до простого сравнения remote_url и username когда remote_url = "" означает is_local ).
Еще одна проблема - увеличение таблицы пользователей и, например, индекса для lower_name , который теперь должен быть объединенным индексом remote_url и lower_name . (С другой стороны, можно также установить lower_name только для локальных пользователей ... хм.)

Я предпочитаю разделение authn / identity-split, потому что думаю, что его проще реализовать. (Поскольку идентификация - это новая концепция, не следует сравнивать только имена пользователей.)
Но я думаю, мне следует снова принять решение, теперь, когда я вижу, насколько сложно ввести разделение. :)
Иногда я немного наивен. ^^

@criztovyl есть случаи, когда remote_url или domain (sub domain) изменяются, тоже могут измениться

• https://mydownmain.com/gitea <--- изначально
• https://gitea.mydownmain.com <--- перемещен в субдомен
• https://source.mydownmain.com <--- хотел общее имя
• https://git.mydownmain.com <--- наконец-то захотелось простоты

как вы знаете, называть вещи сложно

Также пытаюсь понять следующее

• Что, если я, например, потерял свой домен? или имя должно быть изменено по юридическим причинам, или я только что продал свой домен, означает ли это, что я не смогу участвовать в проектах, над которыми я работал раньше?
• Будет ли он поддерживать использование username & email ?
• Как вы знаете, у меня также есть возможность изменить свое имя пользователя или использовать электронную почту для входа в систему, а не имя пользователя, как это соответствует тому, что вы предлагаете

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

Например, все выступают против расизма - с 2019 года github, bitbucket и gitlab блокируют пользователей на основе предполагаемого географического местоположения - https://archive.today/U1R2L . Учитывая огромную волну демонстраций BLM, сейчас не лучший момент для поддержки расизма в сообществе разработчиков программного обеспечения. Я говорю только от своего имени, как пользователь gitea на https://codeberg.org . Это опубликовано как https://codeberg.org/Codeberg/Community/issues/142 , хотя я думаю, что это должно стать независимым вопросом в Codeberg. Обсуждение там предполагает некоторый интерес к Codeberg.

2. Why they need this feature?

Из-за тирании удобства (Keye 2009) (Wu 2018) . Функции онлайн-социальных сетей github / bitbucket / gitlab чрезвычайно эффективны. Введите «@» и несколько символов, и, скорее всего, вам будет предложено ввести идентификатор пользователя того человека, которого вы хотите, среди огромной части сообщества свободного программного обеспечения. Он эффективен, общедоступен (по умолчанию), и проверенный человек может ответить или проигнорировать проблему, не очищая свой почтовый ящик.

Но https://codeberg.org и другие нерасистские серверы репозиториев git еще не имеют федерации типа ActivityPub. Это одна из причин, по которой пользователей github отговаривают переходить на серверы, основанные на сообществе: «Тирания удобства» в том, что простые социальные связи в мировом сообществе - пока еще - не существуют на серверах небольших сообществ.

Другими словами, эта функция необходима для хранения научной эфемерной информации на серверах, которые не зависят от централизованных, секретных, расистских (по состоянию на 2019/2020 гг., См. Выше) корпоративных серверов.

3. How they want to use this feature?

Социальные сети сосредоточены именно на разработке программного обеспечения в открытом сообществе разработчиков программного обеспечения (в основном свободного).

Блокировка этой темы, так как мы получили большое количество отзывов на приведенные выше вопросы, и теперь любой, кто продолжит работу над этим, будет иметь эту информацию, которую они могут проанализировать.