이 질문에 대한 답은 알고 있습니다. 아니요, 불가능합니다. 우리는 마스토돈, 픽스펠드 등에서도 그것을 사용할 수조차 없습니다. 그리고 실제 답은 이 플러그인, 혹은 ActivityPub 전체가 로그인과는 아무런 관련이 없다는 것입니다.
하지만 그럴 수 있다면 좋겠습니다. 하지만 다른 한편으로 — ActivityPub의 아이디어는 다른 서비스에서 로그인할 필요성을 제거하는 것입니다.
1개의 좋아요
알고리즘이 없는 시스템의 아름다움이 바로 이것입니다 
. 네, 그렇게 해야 하지만, 이는 하나의 인스턴스 내에서만 작동합니다. 여전히 팔로워가 필요합니다.
이메일 작동 방식에 대한 널리 쓰이는 비유는 여기서도 성립합니다. 누군가 이메일을 보내야 하지, 그렇지 않으면 스팸으로 간주됩니다.
저는 메타(Meta)와 작별 인사를 했기 때문에 마스토돈에서 꽤 활발하게 활동하고 있습니다. 실제로 세 개의 서로 다른 인스턴스에 계정을 가지고 있습니다. 제 메인 계정은 제 카테고리를 팔로우하고, 다른 두 계정은 제 메인 인스턴스 계정을 팔로우합니다. 이렇게 하면 가시성을 극대화할 수 있고, 나머지는 다른 사용자의 자선에 맡겨야 합니다.
참고로 — 마스토돈이 마크다운과 HTML을 처리하지 못하는 점이 다른 사람들에게 약간 불편함을 주고 있다는 것을 알아차렸습니다.
번역을 위해 Crowdin에 포함해 달라고 요청하기엔 아직 이른 건가요?
좋은 질문입니다.
이 플러그인이 #experimental에서 #official로 승격되어 괜찮은지 평가해 봐야 할 것 같습니다. 괜찮다면 Crowdin에 추가할 수 있습니다.
궁금한 점이 있는데, 어떤 언어를 생각하고 계신가요?
5개의 좋아요
체코어입니다. 이유는 완전한 현지화를 마무리하기 위해 다양한 체코어 포럼을 돌아다니며 번역이 어떻게 작동하는지 확인해 보기 때문입니다. (데이터 조합 때문에 자신의 포럼에서는 볼 수 없는 다른 요소들을 발견할 수 있습니다. 예를 들어, 다른 복수형 사용법이나 다른 플러그인 등입니다.)
그리고 마침 사용자 설정에서 ActivityPub가 표시되는 포럼 하나를 발견했습니다. 사용자 설정이 완전히 현지화되었으면 좋겠어요 
4개의 좋아요
수동으로 번역하는 것은 항상 선택지입니다. 그리고 지금은 유일한 선택지이기도 하죠. 제 경우엔 최대 10분 정도밖에 걸리지 않았습니다. 하지만 물론, 자동으로 이루어지면 관리자에게는 더 쉬울 겁니다.
네, Crowdin에 이 내용을 추가할 수 있을 것 같아요. 그렇게 처리할게요.
6개의 좋아요
토픽은 태그 없이 큰 세상(연동된 네트워크)으로 나갑니다. Discourse에서 어떤 방식으로든 태그를 추가할 수 있을까요?
게시물에 사용된 태그를 추가해야 하지만, 이는 Mastodon 방향으로만 적용되어야 하며, 이것이 실제로 가능한지, 혹은 정말 필요한지 모르겠습니다. 하지만 태그는 Mastodon(또는 연동된 세계 전체에서)에서 매우 중요한 역할을 하므로 필요하다고 생각합니다.
물론 그냥 #태그를 추가할 수도 있지만, Discourse에는 태그를 사용하는 자체적인 멋진 방식이 있기 때문에 그렇게 하는 것은 다소 어색합니다.
2개의 좋아요
https://caneandable.social/@WeirdWriter/113933429408828411
@Angus 이 방법도 가능할지 궁금합니다. Discourse 플러그인을 통해 생성된 액터(actors)에는 fediverse에서 검색할 수 있는 공통 식별자(예: source: Discourse 형태의 메타데이터)가 있을까요? 아니면 게시물을 식별하는 식별자가 있을까요?
1개의 좋아요
네, 가능합니다. 언급하신 것처럼, 태그는 Discourse와 다른 플랫폼에서 약간 다른 역할을 하므로 몇 가지 질문이 제기될 것입니다. 신중한 고려가 필요합니다.
이것은 태그 문제와 관련이 있지만, 그 범위를 넘어섭니다. 여기에는 여러 가지 계층이 있습니다. 우리는 발견(discovery)을 개선하기 위한 Mastodon 전용 접근 방식을 구현할 수 있습니다. 또한 발견을 위한 “규범화된” ActivityPub 접근 방식을 구현할 수도 있습니다. 후자의 경우 다음을 참조하십시오.
하지만 네, 단기, 중기, 장기 제품 목표를 더 논의할 수 있으며, 이러한 다양한 계층을 고려하여 구현 전략을 개발할 수 있습니다. 관련 ActivityPub 담당자들과 이 문제를 이미 공유했습니다:
3개의 좋아요
Fediverse에서 Discourse의 행위자(actors)를 어떻게, 그리고 가능하게 참조할 수 있는지에 대한 여러분의 생각을 듣고 싶습니다.
이 질문은 Discourse를 디지털 가든(digital garden)으로 보았을 때, 이것이 Fediverse와 어떻게 연결될 수 있을지를 고민하다가 떠올랐습니다.
Fediverse 어딘가에서 무언가를 읽게 되면, 이를 TAG@my.garden 또는 CATEGORY@my.garden으로 전달할 수 있기를 바랍니다.
이렇게 전달된 콘텐츠는 어떻게 처리되어야 하며, 또는 Discourse 내부의 어떤 위치에 이러한 메시지가 도착해야 할까요?
누구나 전달이 가능해야 한다면, 어떤 형태의 검토 프로세스가 이루어져야 할 것입니다.
만약 외부 Fediverse 계정을 자신의 계정에 연결할 수 있는 가능성이 있다면, 전달된 콘텐츠는 초안(draft) 형태로 도착하여 가든에 추가로 통합되도록 준비될 수 있을 것입니다.
현재 태그 또는 카테고리 액터가 팔로우하는 액터는 해당 태그나 카테고리에 새 토픽을 게시할 수 있습니다.
Discourse에 'fediverse’라는 카테고리가 있고, fediverse@yourforum.com이 Mastodon의 계정, 예를 들어 fediverse@mastodon.com을 팔로우하고 있다면, fediverse@mastodon.com이 다른 트윗에 대한 답글이 아닌 새로운 트윗을 생성할 때마다 해당 트윗은 ‘fediverse’ 카테고리의 새 토픽이 되며, 그 트윗에 대한 답글들은 해당 토픽의 답글이 됩니다.
이를 당신의 상황에 적용하면, 해당 문장의 'I’가 TAG@my.garden 또는 CATEGORY@my.garden이 팔로우하는 Fediverse 계정이라면, 당신이 새로운 트윗을 생성하거나 트윗을 부스트(또는 ‘announce’)할 때, 해당 내용은 TAG 또는 CATEGORY에 새 토픽으로 생성됩니다.
태그 또는 카테고리 액터가 팔로우하지 않는 외부 액터가 태그 또는 카테고리 액터로 전송한 콘텐츠를 검토 큐로 푸시할 수 있는 기능을 추가할 수 있습니다. 구현 측면에서는 비교적 간단하지만, 필터링은 상당한 문제가 될 것입니다. 들어오는 모든 콘텐츠를 검토하는 것은 많은 경우 실현 불가능합니다.
예를 들어 socialhub.activitypub.rocks에는 12개의 Discourse ActivityPub 액터(태그 및 카테고리)가 있습니다. 이 곳은 (실제로) 매 분마다 수백 건의 수신 POST를 받습니다. 거기에 그러한 검토 시스템을 배포하면 검토 큐가 즉시 폭주하여 사용할 수 없게 될 것입니다.
이 아이디어에는 잠재력이 있습니다. 일부는 이미 이렇게 할 수 있기 때문입니다. 프로필에서 'ActivityPub’를 확인해 보면, 외부 Discourse나 Mastodon의 액터를 자신의 Discourse 사용자 계정과 연결할 수 있음을 알 수 있습니다. 따라서 팔로우하지 않는 액터의 유입 콘텐츠를 필터링하는 한 가지 방법은 포럼에서 충분한 신뢰를 가진 사용자와 연결된 액터의 콘텐츠를 허용하는 것입니다.
3개의 좋아요
그리고 완료: https://discourse.crowdin.com/activity-pub, 이제 번역가들이 ActivityPub 플러그인의 번역에 기여할 수 있습니다.
4개의 좋아요
카테고리가 팔로우할 수 있는 액터에 제한이 있나요? 제 것은 팔로우할 수 있지만, 이상한 것들은 찾을 수 없네요.
수정
제 카테고리가 일부는 찾을 수 있고 일부 계정은 찾을 수 없어요. 인스턴스의 어떤 설정에서 비롯된 걸까요 
카테고리가 마스토돈 계정을 팔로우하고 있습니다. 팔로우 중인 액터가 작성하거나 부스트한 게시물에 이미지가 포함되어 있으면, 해당 이미지가 항상 표시되지 않습니다. 이는 마스토돈이 데이터를 전송하는 방식, ActivityPub의 동작 방식, 또는 Discourse가 이러한 콘텐츠를 처리하는 방식 중 어디에 기술적인 문제가 있는 것인가요?
Mastodon의 Authorized Fetch와의 통합에 여전히 몇 가지 문제가 남아 있을 수 있으며, 이를 해결해야 합니다. 이로 인해 일부 Mastodon 인스턴스에서 계정의 검색 가능성이 영향을 받을 수 있습니다. 도움이 될 수 있도록 예시를 알려주시면 감사하겠습니다.
곧 이미지 지원 기능을 개선할 예정입니다.
1개의 좋아요
mastodon.social은 매번 실패합니다 — 여기서 계정을 약 6회 정도 시도해 봤다는 뜻입니다. 그래서 이것이 인스턴스의 설정 때문에 발생하는 것인지 궁금했습니다.
계정 중 하나는 @ScienceScholar@mastodon.social입니다. 다른 예시로는 @GetCarter@mastodonapp.uk가 있습니다.
나중에 실현될 또 하나의 꿈일 뿐일지도 
만약 카테고리에서 마스토돈의 (해시)태그를 따라갈 수 있다면… 그건 정말 게임 체인저가 될 거예요 — 물론, 마스토돈 인스턴스가 디스커스와 동작 방식이 아주 다르기 때문에 기술적으로 그런 게 가능한지 솔직히 전혀 감이 잡히지 않지만, 정말 멋진 기능이 될 거예요.
1개의 좋아요
다음은 무엇인가요:
discourseactivitypub::AP::Handlers::Warning
메시지 (3765건 보고됨)
[Discourse Activity Pub] DiscourseActivityPub::AP::Handlers::Warning
백트레이스
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/logger.rb:26:in log’
/var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/logger.rb:63:in warn' /var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/ap/activity.rb:42:in rescue in block in perform_transactions’
/var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/ap/activity.rb:35:in block in perform_transactions' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/transaction.rb:616:in block in within_new_transaction’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/concurrency/null_lock.rb:9:in synchronize' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/transaction.rb:613:in within_new_transaction’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:361:in transaction' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/transactions.rb:234:in block in transaction’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:421:in with_connection' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_handling.rb:296:in with_connection’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/transactions.rb:233:in transaction' /var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/ap/activity.rb:34:in perform_transactions’
/var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/ap/activity.rb:26:in process' /var/www/discourse/plugins/discourse-activity-pub/app/jobs/discourse_activity_pub_process.rb:12:in execute’
/var/www/discourse/app/jobs/base.rb:316:in block (2 levels) in perform' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in with_connection’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in with_connection' /var/www/discourse/app/jobs/base.rb:303:in block in perform’
/var/www/discourse/app/jobs/base.rb:299:in each' /var/www/discourse/app/jobs/base.rb:299:in perform’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in execute_job' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in block (2 levels) in process’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in block in invoke' /var/www/discourse/lib/sidekiq/pausable.rb:132:in call’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in block in invoke' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in invoke’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in block in process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in block (6 levels) in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in local' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in block (5 levels) in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in block in <module:Sidekiq>' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in block (4 levels) in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in stats' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in block (3 levels) in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in block (2 levels) in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in global' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in prepare' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in process_one’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in run' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in watchdog’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread’
로그를 확인했는데, 이해할 수 없었던 두 가지 일이 발생했기 때문입니다. 하지만 이 오류/경고와 관련이 있는지 확실하지는 않습니다.
다음과 같은 설정이 있는 하위 카테고리가 있었습니다.
- 게시물 객체 유형 = note
- 게시 유형 = 전체 주제
- (가시성 = 공개; 전체 주제이므로 회색으로 표시됨)
해당 카테고리는 제 마스토ドン(mastodon) 계정을 팔로우하고 있습니다. 이 아이디어는 해당 카테고리에 제 마스토ドン 메시지를 표시하는 것입니다.
따라서 마스토ドン에서 온 원래 주제/메시지에 댓글이 달리면, 그것들이 마스토ドン으로 답장으로 전송될 것이라고 생각했습니다. (테스트 및 시연을 위해) 시도해 보았고, 제 답장에는 초록색 ActivityPub 화살표가 표시되어 뭔가 일어난 것 같습니다. 하지만 마스토ドン 어디에서도 찾을 수 없고, 원래 마스토ドン 메시지에 대한 답장으로 표시되지도 않습니다.
주제에 답장한 후, 다음으로 게시물에 답장을 시도해 보았습니다. 같은 상황이었습니다. AP 아이콘은 초록색이지만 마스토ドン에서 찾을 수 없습니다.
제 마스토ドン 계정은 카테고리 액터를 팔로우하지 않지만, 그것은 필요하지 않아야 합니다.
수정. 원래 마스토ドン 게시물에 마스토ドン에서 온 댓글이 달렸고, 그것이 주제에 표시되었습니다. 따라서 그 방향은 정상적으로 작동합니다.
수정2. 아니면 제가 이걸 완전히 잘못 이해하고 있는 걸까요? 카테고리가 마스토ドン 액터를 팔로우할 때, 실제로는 단순히 팔로우만 하는 것입니다. 그것은 양방향 시스템이 아닙니다. 플러그인은 해당 카테고리에서 발생하는 모든 것을 전송하지만, 그것은 카테고리 액터를 팔로우하는 사람들에게만 표시됩니다. 기본적으로 두 개의 독립적인 단방향 트래픽이 있는 것입니다: 해당 카테고리가 팔로우하는 것과, 해당 카테고리를 팔로우하는 사람들을 위한 것.
그리고 플러그인과 전혀 관련이 없다고 생각하는 또 다른 문제가 있습니다. Mona-app은 해당 카테고리 액터를 찾으려 할 때 404 오류를 반환합니다. 원래 웹 버전은 바로 찾습니다.
아니었네요, 사용자 실수였습니다. 검색에서 엔터를 누르면 사용자가 아닌 콘텐츠 검색을 시도했습니다.
문장의 이상한 구조와 완전히 잘못된 전치사 사용에 대해 죄송합니다. AI-교정은 오류 500을 반환하는데, 아마도 details 블록 때문일 것입니다.