ActivityPub 플러그인

아, 그 소식이 반갑네요! 네, 포럼에서 게시하는 사람을 팔로우하는 것에 대해 말씀하신 부분이 맞는 것 같습니다. 하지만 포럼이 아닌 페디버스(Fediverse)에 게시할 수 있는 기능이 있을 수도 있겠죠. 예를 들어 NodeBB는 커뮤니티 밖의 페디 콘텐츠를 “분류되지 않음” 카테고리에 모아두는데, 그곳에 게시하면 사실상 마스토돈에 게시하는 것과 비슷합니다. Mbin도 비슷한 방식을 취하고 있어요. 링크 집계 서비스로 시작해서 “마이크로블로깅” 탭을 추가했거든요. 당분간 디스커스(Discourse)에서는 범위를 벗어나는 일이라는 점을 이해했습니다. 명확히 설명해 주셔서 감사합니다!

2개의 좋아요

Fediverse에서 Discourse를 주요 거처로 사용하려는 미친 사람들(나 같은)이 있습니다. 저는 Discourse를 통해만 Fediverse에 게시물을 올리고 싶습니다.

사람들이 Discourse를 "공개적으로 작업하기"나 "블로그보다 나은 것"이라는 용도로 사용할 수 있도록 지원하지 않는 게 맞을까요?

사용자들의 요구 사항을 구현하는 데는 비용이 들기 때문에, 기능 도입에 대한 투표를 돈으로 하는 방식을 고려해 본 적이 있나요?

4개의 좋아요

돈으로 투표하는 방식은 지원됩니다. 새로운 기능이 pr-welcome 상태임을 확인한 후 개발을 후원할 수 있습니다.

1개의 좋아요

반대로, 페이스북은 그룹과 연락처를 통해 정확히 이런 방식을 취하고 있으며, 이것이 그곳이 매우 강력한 사용자 락인(sticky)을 가지는 이유 중 하나입니다. 결국 사용자는 자신의 연락처와 연결되기를 원하며, 이 기능은 그룹/커뮤니티 게시물을 그 공간으로 가져옵니다.

제 커뮤니티에서 그런 기능이 매우 소중할 수 있다고 충분히 상상해 볼 수 있습니다. 커뮤니티는 사람들을 하나로 모으고, 그들은 커뮤니티 '외부’에서도 그 연결을 유지하기를 원합니다. 커뮤니티 도구가 이러한 추가적인 연결을 같은 공간/앱으로 가져올 수 있게 해준다면, 커뮤니티 내에서 강한 관계를 형성한 사람들이 다른 소셜 공간으로 이탈하는 것을 방지할 수 있습니다.

여기서 '페이스북을 복제’하려는 것은 아니라는 것을 알고 있지만, 왜 특정 측면에서 그것이 그렇게 잘 작동하는지 생각해 볼 가치가 있습니다.

페이스북에서 이주하는 회원들에게 "보라, 페디버스(Fediverse) 계정을 만들고 주제와 무관한 사람들과도 연결할 수 있다"고 말하고 싶습니다.

아마도 커뮤니티 회원들에게 더 ‘개방된’ 오프톱িক(off-topic) 공간을 제공하기 위한 방법으로 고려해 볼 만합니다.

제 관점에서 보면 이는 완전히 합리적입니다. ‘소셜’(페디버스 계정), 블로그(페디버스와의 연결은 진행 중), 커뮤니티 간의 통합 부족이 마스토ドン(Mastodon)이나 디스코스(Discourse), 워드프레스(Wordpress) 같은 오픈 도구가 페이스북의 효과적인 대안이 되는 것을 가로막고 있는 것입니다.

1개의 좋아요

글쎄요 — 마스토Don과 워드프레스는 이미 그런 역할을 하고 있습니다. 디스커스는 부분적으로만 해당되고, 방향성도 주로 아웃바운드(outbound)에 치우쳐 있지만, 이는 소셜 미디어 플랫폼이 아니에요.

1개의 좋아요

@announcements@meta.discourse.org를 팔로우하려고 할 때 다음 오류 메시지가 표시됩니다:

로그에는 두 개의 경고가 있습니다:

https://meta.discourse.org/ap/actor/68efb2d756abf76171ed302b7ffd3c58 처리 실패: 액터를 해석할 수 없음

https://meta.discourse.org/ap/actor/68efb2d756abf76171ed302b7ffd3c58에 대한 GET 요청 실패:

다만, 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"}
2개의 좋아요

사용 중인 Discourse 버전은 무엇입니까? 다른 Discourse 인스턴스에서는 해당 액터를 찾을 수 있습니다:

1개의 좋아요

최신 버전 2026.3.0-latest를 사용 중입니다

현재 버전은 2026.1.2(808b2ac23d)이며, 플러그인 버전은 (d99071e0)입니다.

여기서 한 가지를 덧붙입니다. 2026.5.0-latest 버전을 사용 중이며, 다른 부분에서는 정상적으로 작동하는 Category Actor를 가지고 있는데 동일한 현상을 겪고 있습니다. Mastodon 액터는 팔로우할 수 있지만, 다른 Discourse 액터는 팔로우할 수 없습니다.

3개의 좋아요

리포트 감사합니다. 곧 확인하겠습니다.

3개의 좋아요

여기서 간단히 안내드립니다. 메타(meta)에서 ActivityPub 플러그인을 비활성화했습니다. 해당 플러그인은 유지보수 모드에 남아있었으며, 앞으로도 보안, 성능 및 버그 수정에 대한 지원은 계속됩니다. 이와 관련하여 오늘 플러그인 저장소에 여러 보안 수정 사항을 병합했으며, 플러그인 사용자는 최신 버전으로 업데이트하는 것을 권장합니다.

메타에서는 불행히도 ActivityPub가 활성화된 카테고리를 사용하는 사용자가 소수에 불과했으며, ActivityPub를 사용하지 않는 사용자들로부터 용어에 대한 혼란을 유발한다는 피드백을 받아, 메타에서는 ActivityPub 통합을 중단하고 프로세스를 단순화하기로 결정했습니다.

4개의 좋아요

여기서 팔로워 수가 적은 이유 중 하나는 비(非)디스코스 사용자가 팔로우할 대상을 알아야 하기 때문입니다. 이 시스템은 현재 소셜 미디어처럼 쉽게 팔로우하는 방식이 아니라, 포럼의 콘텐츠를 페디버스(Fediverse)로 공유하고, 거기서 누군가가 그것을 공유해주길 바라는 구조입니다. (그리고 설령 공유가 이루어진다 해도, 마스토돈(Mastodon)이나 기타 플랫폼의 사용자는 디스코스의 어떤 사용자도 팔로우할 수 없습니다.)

팔로워 수는 알 수 있지만, 실제로 얼마나 많은 사람이 그곳에서 게시물을 보고 있는지 전혀 알 수 없습니다. 물론 메타(Meta)는 일종의 특수한 사례일 수 있습니다. 관리자는 여기 있지만, 일반 사용자는 디스코스의 기술적인 측면에 관심이 없으니까요. 따라서 그 관점에서 보면 그 결정은 이해할 수 있습니다.

2개의 좋아요

안녕하세요, AP 플러그인에서 게시물이 “모든 게시물 게시” 버튼을 통해 수동으로 "게시"되었을 때 published 날짜시간 값이 잘못 표시되는 문제를 보고하려고 합니다.

예시

https://browser.pub/https://socialhub.activitypub.rocks/ap/object/a8d6c23e6c428313efb9bf20efeb020c

기대 동작

published는 게시물이 원래 게시된 날짜시간, 즉 Discourse에서 로컬로 보이는 날짜시간(2018년)을 나타내야 합니다.

실제 동작

published는 AP 리소스가 생성된 날짜, 즉 Discourse에서 로컬로 “게시” 버튼이 클릭된 날짜시간(2026년)을 나타냅니다.

1개의 좋아요

최근 내 Discourse 사이트에서 시작된 연동(페더레이션) 게시물들의 이미지가 Mastodon에서 여러 번 표시되고 있습니다. 이것이 ActivityPub의 문제인지, Mastodon의 문제인지, 아니면 제 설정 오류인지 알 수 없습니다. 어떻게 해결해야 할지 모르겠습니다. 아래는 두 가지 예시입니다. Mastodon이 원래 그리드 뷰가 없던 게시물을 그리드 뷰로 만들려고 하는 것 같습니다.

1개의 좋아요

ask.discourse.com와의 교환으로 버그 리포트 생성됨 ( bfa925d )

discourse-activity-pub이 활성화된 상태에서 ./launcher rebuild 실행 시 NameError: uninitialized constant PrettyText::PrecompiledBundle 오류로 빌드 실패

환경

  • 자체 호스팅 Discourse, discourse_docker 런처를 통한 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 활성화 시 빌드 실패, 제거/비활성화 시 통과.
  • 다른 플러그인은 이 문제를 유발하지 않습니다.

기대되는 동작
활성화된 플러그인에 관계없이 깨끗한 빌드가 이루어지거나, 최소한 lib/pretty_text.rb 내에 정의된 상수/요구(require)가 있어야 합니다 (예: ::PrecompiledBundle 또는 명시적인 require).

질문
이것이 알려진 상호작용 문제인가요? 로드 순서를 수정할 계획이 있는지, 아니면 그 동안 권장되는 고정(pin)/우회책이 있는지 문의드립니다.

1개의 좋아요

이것이 ActivityPub 플러그인과는 아무 관련이 없다고 생각합니다…

여기 보고된 오류를 좀 더 자세히 설명해 주실 수 있을까요? 마이그레이션이 시작되고 나서 이 문제가 발생하는 건지, 아니면 특정 마이그레이션이 실패하는 건가요?

이 부분은 after_initialize 밖에 있기 때문에 로드 순서에 영향을 주는 것 같습니다.

2개의 좋아요

아, 지적해 주셔서 감사합니다. 이렇게 수정해 보겠습니다: FIX: Do not modify global plugin loading behaviour - Pull Request #338 - discourse/discourse-activity-pub - GitHub @thoka 님, 시도해 보시고 결과를 알려주세요.

1개의 좋아요