Ах, приятно слышать! Да, наверное, вы правы насчёт подписки на тех, кто публикует в форуме, но могла бы быть функция публикации в феди-вселенной, а не в форуме. Например, NodeBB помещает весь контент из феди-вселенной вне сообществ в категорию «Без категории», так что если вы публикуете там, это во многом похоже на публикацию в Mastodon. Mbin тоже делает что-то подобное: они начинали как агрегатор ссылок, а затем добавили вкладку «Микроблогинг». Понимаю, что на данный момент это не входит в сферу задач Discourse, спасибо за разъяснение!
Есть безумцы (как я), которые хотят использовать Discourse как свой основной дом в Фидиверсе. Я хочу публиковаться в Фидиверс исключительно через Discourse.
Разве мы не должны поддержать тех, кто использует Discourse как решение для «работы на виду» или «чего-то лучшего, чем блог»?
Поскольку реализация пожеланий пользователей не приносит прибыли, рассматривали ли вы возможность голосования за функции с помощью денег?
Голосование за деньги поддерживается. Вы можете финансировать разработку после того, как убедитесь, что новые функции соответствуют тегу pr-welcome.
С другой стороны, именно так Facebook работает с группами и контактами, и это одна из причин, почему пользователи так привязаны к этой платформе. Поскольку вы всё равно будете взаимодействовать со своими контактами, это «переносит» посты из групп/сообществ в это пространство.
Я легко могу представить, что такая функция была бы чрезвычайно ценной для моего сообщества. Сообщества объединяют людей, и они захотят сохранить эту связь «вне» самого сообщества. Если инструмент сообщества позволяет перенести это дополнительное взаимодействие в то же пространство/приложение, это предотвратит исход людей, построивших прочные отношения внутри сообщества, в другие социальные платформы.
Я понимаю, что мы не пытаемся здесь «скопировать Facebook», но стоит задуматься, почему он так хорошо работает для определённых задач.
Мне бы очень хотелось иметь возможность сказать моим участникам, уходящим из Facebook: «Смотрите, вы можете создать аккаунт в фединверсе и связаться с интересными вам людьми в неформальном общении».
Возможно, это следует рассматривать как способ предоставить участникам сообщества пространство для неформального общения, которое более «открыто».
С моей точки зрения, это имело бы полный смысл. Отсутствие интеграции между «социальными сетями» (аккаунты в фединверсе), блогами (хотя связь их с фединверсом уже налаживается) и сообществами мешает таким открытым инструментам, как Mastodon, Discourse или WordPress, стать эффективной альтернативой Facebook.
Что ж — Mastodon и WordPress уже делают всё это. Discourse лишь отчасти, и его направление в основном внешнее, но это не платформа социальных сетей.
При попытке подписаться на @announcements@meta.discourse.org мы получаем следующее сообщение об ошибке:
В логах есть два предупреждения:
Не удалось обработать https://meta.discourse.org/ap/actor/68efb2d756abf76171ed302b7ffd3c58: не удалось найти актора
GET-запрос к https://meta.discourse.org/ap/actor/68efb2d756abf76171ed302b7ffd3c58 не удался:
Мы можем подписываться на акторов в Mastodon, однако.
Я что-то упускаю или как можно продолжить расследование?
Могу подтвердить идентичное поведение; вот логи:
Started POST "/webfinger/handle/validate" for 172.17.0.1 at 2026-03-15 16:10:39 +0000
Processing by DiscourseActivityPub::Webfinger::HandleController#validate as JSON
Parameters: {"handle" => "@announcements@meta.discourse.org"}
Completed 200 OK in 36ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 11.8ms)
Started GET "/ap/local/actor/57934/find-by-handle?handle=%40announcements%40meta.discourse.org" for 172.17.0.1 at 2026-03-15 16:10:40 +0000
Processing by DiscourseActivityPub::ActorController#find_by_handle as JSON
Parameters: {"handle" => "@announcements@meta.discourse.org", "actor_id" => "57934"}
Started POST "/webfinger/handle/validate" for 172.17.0.1 at 2026-03-15 16:10:43 +0000
Processing by DiscourseActivityPub::Webfinger::HandleController#validate as JSON
Parameters: {"handle" => "@announcements@meta.discourse.org"}
Completed 200 OK in 32ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.8ms)
Started GET "/ap/local/actor/57934/find-by-handle?handle=%40announcements%40meta.discourse.org" for 172.17.0.1 at 2026-03-15 16:10:43 +0000
Processing by DiscourseActivityPub::ActorController#find_by_handle as JSON
Parameters: {"handle" => "@announcements@meta.discourse.org", "actor_id" => "57934"}
Started POST "/webfinger/handle/validate" for 172.17.0.1 at 2026-03-15 16:10:43 +0000
Processing by DiscourseActivityPub::Webfinger::HandleController#validate as JSON
Parameters: {"handle" => "@announcements@meta.discourse.org"}
Completed 200 OK in 30ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.0ms)
Started GET "/ap/local/actor/57934/find-by-handle?handle=%40announcements%40meta.discourse.org" for 172.17.0.1 at 2026-03-15 16:10:43 +0000
Processing by DiscourseActivityPub::ActorController#find_by_handle as JSON
Parameters: {"handle" => "@announcements@meta.discourse.org", "actor_id" => "57934"}
Started POST "/webfinger/handle/validate" for 172.17.0.1 at 2026-03-15 16:10:44 +0000
Processing by DiscourseActivityPub::Webfinger::HandleController#validate as JSON
Parameters: {"handle" => "@announcements@meta.discourse.org"}
Completed 200 OK in 26ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.3ms)
Started GET "/ap/local/actor/57934/find-by-handle?handle=%40announcements%40meta.discourse.org" for 172.17.0.1 at 2026-03-15 16:10:44 +0000
Processing by DiscourseActivityPub::ActorController#find_by_handle as JSON
Parameters: {"handle" => "@announcements@meta.discourse.org", "actor_id" => "57934"}
Started POST "/webfinger/handle/validate" for 172.17.0.1 at 2026-03-15 16:10:44 +0000
Processing by DiscourseActivityPub::Webfinger::HandleController#validate as JSON
Parameters: {"handle" => "@announcements@meta.discourse.org"}
Completed 200 OK in 24ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.3ms)
Started GET "/ap/local/actor/57934/find-by-handle?handle=%40announcements%40meta.discourse.org" for 172.17.0.1 at 2026-03-15 16:10:44 +0000
Processing by DiscourseActivityPub::ActorController#find_by_handle as JSON
Parameters: {"handle" => "@announcements@meta.discourse.org", "actor_id" => "57934"}
Мы находимся на версии 2026.1.2 (808b2ac23d) с версией плагина (d99071e0)
Просто добавлю здесь. На версии 2026.5.0-latest с в остальном работающим актором категории наблюдается та же проблема. Я могу подписываться на акторов Mastodon, но не на акторов Discourse.
Спасибо за отчет, мы скоро займемся этим.
Короткое уведомление: мы отключили плагин ActivityPub на нашем метасайте. Плагин находится в режиме поддержки, но мы продолжим обеспечивать его безопасность, производительность и исправление ошибок. В связи с этим сегодня мы объединили несколько исправлений безопасности в репозитории плагина. Рекомендуем всем пользователям плагина обновиться до последней версии.
На метасайте, к сожалению, категории с поддержкой ActivityPub использовались лишь несколькими пользователями, и у нас были отзывы от пользователей, не использующих ActivityPub, которые были запутаны в терминологии. Поэтому мы решили упростить ситуацию и прекратить интеграцию ActivityPub на метасайте.
Одна из причин, почему там так мало подписчиков, заключается в том, что пользователям, не использующим Discourse, нужно понимать, на кого подписываться. Эта система не предназначена для простого подписывания, как в социальных сетях, а скорее для распространения контента с форума в Fediverse с надеждой на то, что кто-то там тоже делится им (и даже тогда пользователь Mastodon или любой другой платформы не может подписаться на участника Discourse).
Вы знаете количество подписчиков, но не имеете представления о том, сколько людей просматривает ваши посты. Но, конечно, meta-форум — это особый случай, потому что здесь, вероятно, присутствуют администраторы, а обычные пользователи не интересуются техническими аспектами Discourse. С этой точки зрения я понимаю это решение.
Привет! Я пытаюсь сообщить об ошибке в плагине AP, связанной с тем, что дата и время в поле published указаны неверно для постов, которые вручную «публикуются» через кнопку «Опубликовать все посты».
Пример
https://browser.pub/https://socialhub.activitypub.rocks/ap/object/a8d6c23e6c428313efb9bf20efeb020c
Ожидаемое поведение
published указывает на дату и время первоначальной публикации поста, то есть на дату, отображаемую локально в Discourse (2018).
Фактическое поведение
published указывает на дату создания AP-ресурса, то есть на дату и время, когда была нажата кнопка «Опубликовать» локально в Discourse (2026).
В последнее время изображения в моих федеративных постах, отправленных с моего Discourse-сайта, дублируются в Mastodon. Это особенность ActivityPub, особенность Mastodon или неправильная конфигурация с моей стороны? Я не уверен, как это исправить. Вот два примера. Mastodon, похоже, пытается создать сеточный вид, хотя в оригинале его не было.
Создан отчёт об ошибке в обмене с ask.discourse.com ( bfa925d )
Сборка завершается ошибкой во время ./launcher rebuild с сообщением NameError: uninitialized constant PrettyText::PrecompiledBundle, когда включён discourse-activity-pub
Окружение
- Самостоятельно хостингуемый Discourse, установка через Docker с использованием лаунчера
discourse_docker, многоконтейнерная конфигурация (Web + Sidekiq) - Ruby 3.4.0, Rails 8.0.5.1
- Ветка:
latest(корневая причина также воспроизведена на текущем коде)
Ошибка
Во время начальной настройки, на шаге rake db:migrate:
rake aborted!
NameError: uninitialized constant PrettyText::PrecompiledBundle (NameError)
PrecompiledBundle.new(
^^^^^^^^^^^^^^^^^
/var/www/discourse/lib/pretty_text.rb:56:in '<module:PrettyText>'
Корневая причина (анализ агентов)
В файле lib/pretty_text.rb:56, внутри module PrettyText, константа PrecompiledBundle используется без верхнеуровневого скоупа ::. В результате Ruby интерпретирует её как PrettyText::PrecompiledBundle (файл lib/pretty_text/precompiled_bundle.rb), которого не существует. Фактический класс находится в /var/www/discourse/lib/precompiled_bundle.rb (на верхнем уровне). Без плагина порядок загрузки случайно позволяет определить его вовремя; однако при включённом discourse-activity-pub порядок загрузки меняется, и константа не доступна в момент загрузки pretty_text.rb.
Доказательства
- Сборка проходит без ошибок при отключённых всех плагинах.
- Бинарный поиск по списку плагинов: сборка завершается ошибкой при включённом discourse-activity-pub и проходит успешно при его удалении/отключении.
- Ни один другой плагин не вызывает эту проблему.
Ожидаемое поведение
Чистая сборка, не зависящая от того, какие плагины включены, или, по крайней мере, определённая константа/require в lib/pretty_text.rb (например, ::PrecompiledBundle или явный require).
Вопрос
Является ли это известным взаимодействием? Есть ли планы по исправлению порядка загрузки, или есть ли рекомендуемый пин/обходной путь на данный момент?
Я не думаю, что это имеет какое-либо отношение к плагину ActivityPub…
Не могли бы вы привести полный текст ошибки? Миграции запускаются, а затем возникает эта проблема, или есть конкретная миграция, которая завершается с ошибкой?
Я думаю, что эта часть нарушает порядок загрузки, так как она находится вне after_initialize
О, спасибо, что поправили. Возможно, вот исправление: FIX: Do not modify global plugin loading behaviour - Pull Request #338 - discourse/discourse-activity-pub - GitHub. Пожалуйста, проверьте его @thoka и дайте знать, как всё прошло.






