Привет, @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 знаете их лучше всех 
). По моему мнению, Discourse по полноте функций всё ещё значительно превосходит то, что могут предложить их продукты. И у вас есть сообщество, как никакое другое, которое поможет вам развивать продукт.
Но возможность интероперабельности, которая существует сейчас, может также стать угрозой. Либо конкуренты первыми воспользуются этой возможностью, либо — возможно, под давлением Закона ЕС о цифровых рынках — платформы Big Tech создадут что-то с пересечением в доменной области программного обеспечения для форумов. В обоих случаях Discourse будет сложнее согласоваться с этим стандартом и иметь самый авторитетный голос при проектировании его спецификации.
TL;DR
Это получилось более длинным постом, чем я планировал. Извините за это 
Вкратце, я утверждаю, что, учитывая текущую позицию относительно поддержки ActivityPub, может быть разумно перейти от краткосрочного фокуса на MVP к более широкой оценке того, что интероперабельность ActivityPub может принести Discourse с точки зрения УТП и позиционирования в долгосрочной перспективе. То есть разработать бизнес-кейс внедрения ActivityPub, начиная с фазы идеации.
(Как лучше всего это организовать — если вам это интересно — я оставляю на ваше усмотрение, но это может начаться просто с создания новой темы AP, где сверху будет размещена сводная вики со собранными сценариями использования, а люди будут обсуждать идеи сценариев в теме.)