Вот потенциально жизнеспособная идея для поддержки исходящей федерации в Discourse: Webmentions через Brid.gy.
Обзор процесса:
Тема создаётся с ссылкой в первом сообщении — изначально нужно определять либо одну ссылку в первом сообщении, либо URL, вставленный в заголовок.
Опционально: чтобы избежать тривиального спама, можно либо ждать первого ответа, либо включить соответствующую настройку сайта.
Проверить страницу на поддержку WebMention.
Отправить комментарий WebMention с текстом: «Эта страница обсуждается на =SITE_DOMAIN=: «=TITLE=» =TOPIC_LINK= =CATEGORY_AND_TAGS=» (с использованием default_locale сайта).
Сайт получает WebMention (возможно, делегируя обработку в fed.brid.gy, применяя анти-спам и т. д.) и в конечном итоге отображает это как комментарий.
Актор (автор комментария) будет использовать либо высококачественный логотип сайта, либо @system-аватар, а также короткое название форума.
Кстати: я не упоминал об этом в посте, но протокол поддерживает отправку лайков и репостов как полноправных объектов, аналогично ответам. Было бы здорово, если бы Discourse тоже это реализовал.
Pavilion подал заявку в NLnet на получение 40 000 евро для добавления поддержки федеративности в Discourse (см. ниже). Заявка была отклонена, и в итоге мы подали заявку и были приняты в программу DAPSI.
Обновление. Pavilion и CDCK (Discourse.org) обсуждают создание плагина ActivityPub для Discourse. После некоторых обсуждений мы остановились на следующей спецификации. Любые комментарии или предложения приветствуются до её окончательного утверждения. Обратите внимание, что:
Поддержка входящего контента (например, постов из Mastodon и других платформ, импортируемых в Discourse) намеренно исключена. Возможность её добавления будет рассмотрена в более поздних версиях.
Поддержка подписки на пользователей (в отличие от категорий) также намеренно исключена. Это также может быть реализовано в будущих версиях.
Значительная часть спецификации следует подходу, принятому в проекте Lemmy.
Pavilion займётся разработкой MVP-плагина (над ним буду работать я), а CDCK будет его владельцем и хостом (то есть это будет плагин CDCK, а не Pavilion).
Обзор
Плагин ActivityPub (AP) для Discourse.
Цель плагина — реализация MVP спецификаций ActivityPub, ActivityVocab и ActivityStreams в Discourse с одной продемонстрированной интеграцией функционала MVP для платформы, совместимой с AP, а именно Mastodon. Насколько это возможно, реализация будет построена с учётом поддержки дальнейших расширений протоколов.
Данная спецификация касается включения поддержки AP на уровне категорий, при этом федерации подлежит только первый пост в каждой теме в категории с включённой поддержкой AP («только первый пост»).
Пользователи
Использование плагина будет подробно задокументировано на meta в теме, посвящённой плагину.
Обычный пользователь
Подписывается (также «следит») на категорию с включённой федерацией (FDC) в Discourse через Mastodon (или любой другой сервис федивёрса), используя идентификатор категории, например, @announcements@meta.discourse.org.
Видит в своей ленте Mastodon отрывки первых постов всех тем FDC (опубликованных после подписки), каждый из которых содержит ссылку на соответствующую тему, например: «Обсудить на нашем форуме».
Любые действия, связанные с постом в Mastodon, не отображаются в Discourse.
Любые действия, связанные с постом в Discourse, не отображаются в Mastodon.
Отрывки федеративных постов могут контролироваться автором поста с помощью разметки, аналогичной той, что используется для управления отрывками тем, например: <div class="note">{text}</div>.
Администратор
Включает федерацию для каждой категории через настройку категории. Федерацию можно включить только для категорий, видимых «всем» на публичных инстансах.
Устанавливает федеративное имя пользователя категории через интерфейс настроек категории (изменить его нельзя).
Настраивает списки разрешённых и запрещённых доменов через настройки сайта, из которых активность автоматически принимается или отклоняется.
Устанавливает «список блокировок» федеративных имён пользователей, которые будут включены в объекты Block в исходящей очереди сервера.
Устанавливает максимальную длину текста федеративного сообщения через настройку сайта, например, activitypub_note_excerpt_maxlength.
Устанавливает текст, связанный со ссылкой, включаемой в первый пост федеративной темы Discourse, через раздел «Настроить > Текст».
Устанавливает, включается ли ссылка (и текст) обратно на форум в федеративные посты для каждой категории отдельно.
Добавляет пару ключей через настройки сайта для подписи федеративного контента.
Технические детали
Плагин будет включать комплексное тестирование (юнит-тесты, интеграционные тесты и JS-тесты).
Категория представляет собой автоматизированного актора ActivityPub внутри Discourse (как актор типа Group). Федеративное preferredUsername устанавливается администратором при включении федерации и сохраняется в пользовательском поле категории. Федеративное имя (также отображаемое имя) — это полное имя категории (full_name).
Пользователи являются акторами в контенте, федеративно распространяемом актором категории. Федеративный preferredUsername — это имя пользователя Discourse на момент федерации. preferredUsername пользователя сохраняется в пользовательском поле пользователя на случай изменения им своего имени в Discourse. Федеративное имя (также отображаемое имя) — это имя пользователя в Discourse.
В целом объекты ActivityPub будут ассоциированы с их эквивалентами в Discourse через пользовательские поля, где это уместно (например, идентификаторы объектов или акторов), а также через новые таблицы, где это необходимо (например, входящая и исходящая очереди).
Основной активностью ActivityPub для реализации является Follow, а также связанные с ней активности и модели, необходимые для её реализации, то есть входящая очередь, исходящая очередь и требуемые связанные действия и коллекции.
Посты Discourse будут федеративно распространяться как Notes в ActivityStream, с контентом в формате HTML.
Аутентификация будет осуществляться с использованием HTTP Signatures, см. здесь и здесь. Все остальные соображения безопасности в спецификации ActivityPub будут учтены по мере необходимости.
Эндпоинты федерации будут защищены в соответствии со спецификацией, то есть необходимо убедиться, что используется redirect_to_login_if_required в контроллерах, а также добавить guardian для проверки прав доступа к категории, видимой всем.
Я очень рад увидеть эту новость! Спасибо! Также рад, что вы начинаете с простой первоначальной реализации, вместо того чтобы пытаться съесть слона (это не завуалированная отсылка к Mastodon). Я колеблюсь предлагать что-то добавить, но раз вы просите suggestions, вот одна, которая, надеюсь, потребует лишь незначительно больше усилий:
Что вы думаете о возможности также публиковать отрывки ответов, используя inReplyTo для их связывания в цепочки? Мне кажется, это подчеркнёт диалог, происходящий в Discourse, и сделает его более привлекательным; вместе с кнопкой «Обсудить на нашем форуме» я полагаю, что возможность увидеть разговор с большей вероятностью привлечёт больше людей.
Проблема с федерацией ответов на данном этапе заключается в том, что это может создать ожидания вовлечённости, которые не будут реализованы до тех пор, пока не появится полноценная поддержка этой функции. Важно чётко обозначить ожидания пользователей. Хотя некоторые пользователи могут понимать ограничения, связанные с такими федерированными ответами, другие — нет. Ещё одна проблема — попытка сократить количество технических задач, которые нужно решать одновременно.
Тем не менее, мы уже рассматривали расширение «весь топик» к спецификации «только первый пост», которую вы видите выше. Ниже я привёл некоторые технические заметки, чтобы дать представление о возможном направлении развития. Хочу подчеркнуть, что расширение «весь топик» не входит в начальную спецификацию и пока является лишь возможностью.
Расширение «весь топик»
Входящие заметки будут публиковаться как новые темы или ответы (с использованием inReplyTo или Replies).
К входящим объектам по возможности будут применяться фильтры безопасности и спама Discourse, используя Accept / Reject objects.
Заметки будут атрибутированы к временному пользователю, связанному с идентификатором актора через пользовательское поле. Это потребует варианта концепции временного пользователя, не основанного на электронной почте, так как у пользователя не будет реальной почты (заполнитель может быть сгенерирован на основе идентификатора федерированного актора и preferredUsername).
Связывание временных пользователей ActivityPub со стандартными пользователями Discourse возможно, но в настоящее время не включено ни в одну часть этой спецификации. Это проблема «федерированной идентичности» и связанных с ней решений.
Федерированные посты не будут поддерживать федерированные @упоминания или что-либо подобное за пределами основных спецификаций ActivityPub/Stream. Поддержка таких функций может быть добавлена в более поздних версиях, например, с использованием Webfinger, following Mastodon.
Ключевая задача в этой первой версии — сосредоточиться на минимально жизнеспособной реализации. Как только этот фундамент будет заложен, полноценная (или более полная) поддержка федерации, возможно, в духе тех заметок «весь топик», станет более осуществимой. Однако хочу подчеркнуть, что направление развития плагина должно определяться CDCK. Всё, что я упоминаю здесь, — это лишь возможные пути развития базовой спецификации.
P.S. Также хочу отметить, что в ноябре прошлого года ко мне обратился Дэниэл Клабберс (Daniël Klabbers), основной разработчик Flarum, и сообщил, что они работают над расширением ActivityPub. Не знаю, какой сейчас статус, но было бы неплохо, если бы все проекты в сфере форумов объединили усилия, чтобы обеспечить максимальную совместимость в этой области.
Касательно этой совместимости хочу также упомянуть процесс предложений по улучшению Федериверса (FEP) на Codeberg:
Например, недавно Lemmy завершил работу над FEP для групп ActivityPub. Обсуждения проходят в SocialHub по адресу:
(Процесс FEP набирает обороты вместе с ростом Федериверса и в настоящее время является лучшим местом для стандартизации механизмов протокола)
Спасибо, @aschrijver, очень полезно! Лично я сосредоточусь на реализации MVP, описанной выше, работая в тесном сотрудничестве с CDCK. Как метко заметил @mcdanlj, критически важно, чтобы эта работа не пыталась «проглотить слона». Мы с интересом ждём конструктивной обратной связи по спецификации, особенно в технической части.
Хочу также добавить, что два других участника Pavilion — @nmeyne (ветеран сообщества SSI, особенно в области верифицируемых учётных данных) и @merefield — также работают в этой области, и их интересуют некоторые из более широких вопросов, которые вы подняли.
В качестве примера реальных недоразумений, возникающих из-за иллюзии точности, можно упомянуть одну из проблем, с которой мы столкнулись на Maker Forums, куда мы импортировали множество сообществ Google+, когда Google+ прекратил существование. Импорт был настолько высококачественным, что новички на сайте не осознают, что пытаются взаимодействовать с пользователями, которые ещё не перешли на наш сайт из Google+. Поэтому у нас есть шаблонный ответ, чтобы сообщить им, что человек, с которым они пытаются поговорить, пока не здесь и не сможет ответить им.
Спасибо за предоставление подробностей о концепции «расширения всей темы».
На случай, если эта функция будет добавлена в будущем… на мой взгляд, очень удачным является подход, который использовал плагин Pterotype для WordPress: любые федеративные комментарии сначала передаются на модерацию или групповое одобрение, и только после этого публикуются как ответ в исходной теме форума.
В случае с форумом эту задачу лучше поручать пользователям уровня TL4 / TL3, а не администраторам.
Лично я считаю, что такой подход особенно эффективен для предотвращения того, чтобы ответы в стиле социальных сетей или не по теме затмевали исходную дискуссию.
Да, использование очереди ревью для входящего контента — это то, что мы обсуждали. Как вы отметили, это стоит рассмотреть, если и когда мы дойдём до этого этапа (не в первой версии).
Просто для информации: административные вопросы, связанные с этой работой, уже решены, поэтому на следующей неделе я приступлю к работе над спецификацией. Любые дополнительные технические замечания или комментарии по спецификации приветствуются.
На реализацию этого потребуется несколько месяцев, так что немного подождите.
Если пост удалён в Discourse, может ли действие Delete быть отправлено подписчикам?
На Maker Forums у нас достаточно «очков Google», чтобы привлекать много спамеров, использующих SEO. У нас относительно свободные права для новых пользователей, так как типичный сценарий — это расстроенный человек, ищущий помощь, актуальную для сайта, и это помогает нам быстрее ему помочь. Однако это означает, что спамеры обычно успевают разместить спам-пост, который затем быстро помечается как спам, исключается из индекса и удаляется.
Мне бы очень хотелось, чтобы такие федерированные посты удалялись, а удаление публиковалось через Delete, чтобы мы могли очищать спам из федерированных кешей. Возможно ли это в рамках текущих планов?
В данном случае может быть полезно ввести задержку для федерации на несколько часов, чтобы дать возможность обработать спам до начала федерации. (Возможно, даже применять задержку только к первым сообщениям относительно новых пользователей?)
Я ожидаю, что мы реализуем это в MVP по причинам, которые вы упомянули. Обсудим это подробнее с командой Discourse в подходящее время.
Полезная рекомендация. Федерация определённо будет асинхронной. Как именно настраивать и обрабатывать задержку — вопрос, который нам нужно будет решить каким-то образом в рамках MVP.
Конкретные предложения такого рода для MVP, особенно основанные на предыдущих случаях использования или технической экспертизе в предметной области, крайне приветствуются.
Если это не потребует значительно больше работы на начальном этапе, было бы ценно также федерировать правки постов как активности Update. Если это одна из тех вещей, которые можно добавить после MVP, то было бы здорово иметь дизайн, который разумно предусматривает такую возможность в будущем.
На всякий случай, я бы установил задержку на своих экземплярах на низком уровне. Я не планировал бы использовать её для предотвращения федерации спам-постов, так как это, скорее всего, станет сигналом, который привлечёт модератора из его ленты фединтернета в наш Discourse для принятия мер. У меня параметр chat_integration_delay_seconds установлен на 20 секунд для быстрых исправлений опечаток, и я бы ожидал сделать что-то подобное здесь. По крайней мере, этот параметр уже задаёт прецедент для такой задержки.
Короткое обновление! Мы работаем над разработкой уже месяц и, в общих чертах, у нас теперь работает следующее:
Пользователи могут подписываться на категории с включённым ActivityPub
Первые сообщения тем в категориях с включённым ActivityPub распространяются среди подписчиков
Есть ещё несколько мелких задач, но на данном этапе подробно останавливаться на них не стоит. Перед началом внутреннего тестирования нам потребуется как минимум ещё один месяц разработки.
Нам нужна свобода в каждом аспекте, который мы можем реализовать с одобрения централизованных сервисов или без него.
Это unstoppable и доступно для каждого CEO, CTO или любого другого креативного лица, принимающего решения
И большое спасибо всем разработчикам, которые участвуют в проекте и достигли такого прогресса. Я протестирую, когда он станет публичным, и поделюсь своими мыслями.
