Поддержка ActivityPub: RFC этапа 1

Понятно.
Довольно раздражает.

Друзья перешли на Discourse из-за предстоящего ActivityPub.
Теперь они снова поливают Discourse грязью…

Кроме того, официальный форум ActivityPub переехал на Discourse, и теперь нам
нужно обсуждать, что делать…

Разработчики, стоящие за Lemmy, проделывают отличную работу в области адаптации ActivityPub для использования в программном обеспечении сообществ:

https://github.com/LemmyNet/lemmy-docs/blob/main/src/en/federation/overview.md

Однако им пришлось расширить его, поэтому другое программное обеспечение не реализует их активности.

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

Я думаю, что если Lemmy сможет обеспечить совместимость с Mastodon, мы сможем реализовать тот же API, который использует Lemmy, сопоставляя:

Discourse Lemmy ActivityPub
Категория Сообщество
Подписка Подписка
Тема Пост
Пост Комментарий
Нравится Нравится
19 лайков

В терминологии ActivityPub это, таким образом, будет Page, что имеет большой смысл, если учесть функцию публикации Page: первая часть объявляется как Page, а любой ответ — как Note.

Я не уверен насчет Category → Community. Поскольку поддержка AP и SSO делают это более гибким. У меня, как правило, более одного экземпляра Discourse для одного сообщества.

5 лайков

Просто хочу сказать, что следующие экземпляры Discourse начали обмениваться как пользователями, так и темами, и поддержка ActivityPub в Discourse была бы очень полезна для всех нас:

https://love.public.cat/t/what-is-at-stake-with-interoperability/96

7 лайков

Интересно, стоит отметить, что Mobilizon также использует ActivityPub для планирования мероприятий. Проект разработан Framasoft — теми же людьми, которые создали Peertube.

1 лайк

Жаль, что Discourse не движется в сторону внедрения ActivityPub. Мне кажется, здесь упущен огромный потенциал, учитывая, что существует так много сообществ, которые уже используют Discourse и выиграли бы от этого с первого дня… Даже если они пока этого не осознают! :sweat_smile:

3 лайка

Привет, @rishabh, @riking, @codinghorror,

(Да, ниже есть краткое содержание TL;DR)

Некоторое время назад я понял от @sl007 и @hellekin, что вы не будете реализовывать эту Фазу 1 в ближайшем будущем, даже при наличии финансирования NGI0. Как единомышленник, продвигающий интероперабельность на основе ActivityPub, я, конечно, тоже считаю это жаль. Однако с точки зрения Discourse — ведущего и самого популярного программного обеспечения для форумов — существует множество факторов и других приоритетов, которые необходимо учитывать, и в этом свете данное бизнес-решение, вероятно, имеет много смысла:

Решение: Данный RFC в предложенном виде просто не был достаточно привлекательным, чтобы получить приоритет и быть включённым в дорожную карту.

В RFC был использован подход MVP с предложением @Falco: «Начнём с создания агрегированной ленты контента, похожей на Facebook, для форумов». Это лишь одна из множества функций, которые могут появиться благодаря наличию нативной поддержки ActivityPub в той или иной форме. Можно утверждать, что такой сценарий развития несколько отклоняется от того, что обычно встречается в форумах, и мне не кажется, что это действительно ключевая функция. Скорее, это дополнение, поэтому оно относится к категории «желательно, но не обязательно».

Другой подход

Поскольку необходимость быстрого создания MVP для поддержки ActivityPub отпала, возможно, мы могли бы пойти противоположным путём:

Идеация: Мозговой штурм по сценариям интероперабельности и оценка их жизнеспособности с точки зрения бизнес-выгоды и уникальных торговых преимуществ (УТП).

То есть, какие функции действительно были бы привлекательными для Discourse? Или даже: Где Discourse может упустить возможности, если не будет в курсе того, что возможно?

В своём последнем посте выше @Falco упоминает Lemmy, который создан с нуля на основе специализированной онтологии связанных данных, соответствующей их предметной области. У них уже готов MVP, который работает в продакшене, и теперь они рассматривают расширение функционала поверх своей собственной области. Это может включать федерацию с другой доменной областью микроблогинга, где Mastodon, Pleroma и другие очень успешны.

Подход к идеации может быть следующим:

Упражнение: Давайте представим, как мог бы выглядеть Discourse, если бы изначально был основан на собственной бизнес-доменной области на основе ActivityPub (определённой как онтология связанных данных).

Давайте разгуляемся в этой сессии мозгового штурма и дадим волю нашему творчеству.

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

ActivityPub против Fediverse

Я заметил, что существует широкое заблуждение относительно того, что означает наличие поддержки ActivityPub в приложении. Многие люди думают, что цель этого — стать «частью Fediverse». И здесь мысль сразу же уходит к федерации с экземплярами Mastodon, то есть к реализации интероперабельности с (то есть присоединению к) федеративной доменной области микроблогинга.

Да, это очень привлекательная возможность, как только появится поддержка ActivityPub, и многие другие приложения, такие как PixelFed (альтернатива Instagram), PeerTube (альтернатива YouTube), а также Lemmy (альтернатива Reddit), стремятся к этому. Они делают Fediverse более привлекательным для участия, и множество инноваций принимает форму, что делает будущее Fediverse по-настоящему захватывающим.

НО…

Можно утверждать, что организации, ориентированные на большие пользовательские базы, такие как Discourse, могут задавать вопросы: «Зачем мне интегрироваться с Fediverse, где всего около 4 миллионов пользователей?» или «Зачем мне интегрировать микроблогинг в своё программное обеспечение, которое работает в совершенно другой доменной области?». И они будут правы, заявляя об этом, и могут отказаться от реализации ActivityPub на этом основании.

ОДНАКО…

Реализации ActivityPub касаются гораздо большего, чем просто вхождение в (часть микроблогинга) Fediverse. Имеет смысл реализовать онтологию связанных данных, уникально разработанную для вашей собственной бизнес-доменной области, и чтобы ваши собственные экземпляры продукта федерировались друг с другом. Или все экземпляры вашего продукта и продукты конкурентов в вашей отрасли, которые также принимают ту же онтологию, если на то пошло.

Одним из примеров здесь является проект ForgeFed, который стремится определить стандарты интероперабельности для систем управления кодом (GitHub, GitLab, Gitea, Sourcehut и т. д.). Это имеет огромный смысл, особенно для небольших проектов систем управления кодом, чтобы предоставить привлекательную альтернативу GitHub (который стал слишком доминирующим как централизованная, всё более закрытая платформа). Если это будет широко принято, разработчикам больше не придётся управлять множеством учётных записей на разбросанных по всему интернету серверах, чтобы участвовать в интересных проектах, создавать задачи, комментировать и отправлять PR.

(Обратите внимание, что — как указано выше — та же проблема, с которой люди сталкиваются из-за существования независимых систем управления кодом повсюду, испытываю я и другие при участии в множестве сообществ Discourse.)

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

В вашей отрасли есть несколько растущих конкурентов, которые новаторски подходят к делу, используют свежие подходы и быстро добавляют новые функции (вы в Discourse знаете их лучше всех :slight_smile: ). По моему мнению, Discourse по полноте функций всё ещё значительно превосходит то, что могут предложить их продукты. И у вас есть сообщество, как никакое другое, которое поможет вам развивать продукт.

Но возможность интероперабельности, которая существует сейчас, может также стать угрозой. Либо конкуренты первыми воспользуются этой возможностью, либо — возможно, под давлением Закона ЕС о цифровых рынках — платформы Big Tech создадут что-то с пересечением в доменной области программного обеспечения для форумов. В обоих случаях Discourse будет сложнее согласоваться с этим стандартом и иметь самый авторитетный голос при проектировании его спецификации.

TL;DR

Это получилось более длинным постом, чем я планировал. Извините за это :blush:

Вкратце, я утверждаю, что, учитывая текущую позицию относительно поддержки ActivityPub, может быть разумно перейти от краткосрочного фокуса на MVP к более широкой оценке того, что интероперабельность ActivityPub может принести Discourse с точки зрения УТП и позиционирования в долгосрочной перспективе. То есть разработать бизнес-кейс внедрения ActivityPub, начиная с фазы идеации.

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

11 лайков

К вашему сведению: Dansup, ведущий разработчик Pixelfed, только что объявил о своём намерении добавить поддержку федеративных форумов:

https://mastodon.social/@dansup/105425592966902917

5 лайков

Арнольд, что мешает вам заказать это как плагин, если у вас есть доступ к финансированию?

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

Хороший пример — плагин Topic List Previews. Предварительные просмотр миниатюр изначально были полностью добавлены «сверху». В результате доказанной популярности теперь ядро Discourse поддерживает миниатюры нативно.

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

Такой подход снижает риски и помогает преодолеть практические ограничения перед включением в дорожную карту ядра.

Просто мысль…

9 лайков

На рынке уже существовало предложение о финансировании, которое подхватил кто-то из команды Discourse, но затем принятое предложение было отклонено. Предложение всё ещё открыто, но требует, чтобы его подхватил европейский субъект. Это может быть европейский член The Pavilion. Я с радостью помогу с предложением, так как адаптация существующего определённо ускорит его путь к успешному финансированию.

5 лайков

Мы определенно можем обсудить это офлайн, как это можно будет решить.

4 лайка

Ваша ссылка на Dansup напоминает мне о плагинах ActivityPub для WordPress, которые доступны уже последние пару лет. Подобно этому человеку, я использую их на своём WordPress с момента их появления: плагин ActivityPub и сейчас уже довольно малоактивный Pterotype.

Ваш сайт становится аккаунтом (актором) в федеративной сети, например @latest@meta.discourse.org. Вы можете добавить описание для своего аккаунта, а иконка вашего сайта будет отображаться как аватар вашего федеративного профиля. Публикации будут появляться в федеративной ленте для других пользователей, а их комментарии будут отображаться на нашем сайте с иконкой и именем их федеративного профиля.

Пример ответа:

@doug@mastodoon.social:
Мне очень нравится следить за этой темой о федерации! Так держать!

Это действительно удобно, так как в WordPress это отображается как обычный комментарий, но при этом является настоящим федеративным комментарием благодаря ActivityPub.

edit: Обратите внимание на Prismo — федеративную вариацию Lemmy/Reddit, созданную на Ruby / PostgreSQL, которая может быть ближе к дизайну Discourse.

3 лайка

Привет, @merefield,

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

Я сам работаю преимущественно над различными аспектами этого Fediverse. Мой ответ исходит как от преданного поклонника и пропагандиста Discourse, так и от защитника Fediverse, который — со всеми его инновациями — я вижу как главную возможность стать социальной средой нового поколения, управляемой людьми и более человечной.

Однако в моём предыдущем посте я хотел подчеркнуть, что существует сценарий использования интероперабельности, полностью независимый от интеграции с Fediverse, — непосредственно между различными сообществами Discourse. P.S. Я обратился в форум SocialHub, чтобы привлечь внимание к этому аспекту поддержки ActivityPub: Positioning ActivityPub: De-Emphasize "Being Part of the Fediverse" as primary USP - Fediverse Futures - SocialHub

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

:sparkling_heart:

Да, мне это очень нравится. Эти проекты могут послужить прекрасным источником вдохновения для того, что может быть реализовано в том типе Discourse, о котором говорит @merefield, при фокусировке на поддержке Fediverse.

4 лайка

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

4 лайка

Отличные замечания! Если цель заключается в синхронизации поста на одном форуме с постом на другом форуме Discourse, вы уже можете использовать matterbabble с matterbridge.

1 лайк

Нет, вы правы. Именно это я и предлагал сделать (в своей краткой выжимке с формулировкой «разработать бизнес-обоснование внедрения ActivityPub, начиная с этапа генерации идей»).

Поскольку это предложение для мозгового штурма выходит далеко за рамки темы этой ветки, а также не касается какой-либо отдельной функции или RFC, а скорее представляет собой видение, я создал отдельную тему в категории #community:

5 лайков

Пожалуйста, ознакомьтесь с предложением по проработке бизнес-кейса, который мог бы стать отправной точкой для убеждения @riking в целесообразности внедрения поддержки ActivityPub в Discourse :slight_smile: @merefield, не хотите ли вы присоединиться к обсуждению там? – Конечно, если бы поддержка AP была реализована, это было бы гораздо проще!

4 лайка

Извините, если я не прав, но почему бы не конвертировать RSS-ленты в ActivityPub с помощью feed2toot? Я вижу, что он поддерживает Mastodon и Pleroma. Discourse по умолчанию генерирует RSS-ленты для категорий и групп. Поддержка RSS также встроена в Hubzilla и Friendica.

Разве это не будет работать только в «одну сторону»? «Наружу» из Discourse к экземплярам ActivityPub, но не наоборот.

@hellekin Извините, но я не совсем понимаю, в чём здесь «сценарий использования». То есть зачем это нужно, в чём преимущества и так далее.

Повторно перечитав тему и после того, как я перешёл по ссылке Community has no boundary: Discourse-as-a-Fabric - ideation & brainstorm и начал снова обдумывать вопрос на Shaping Up a Business Use-Case for ActivityPub in Discourse - Fediverse Futures - SocialHub, я понял, что никто не попросил подробно изложить причины здесь. Это, наверное, упущение с моей стороны и со стороны других сторонников ActivityPub. Приношу извинения.

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

3 лайка