현재 이 단계에 있음을 안내드립니다
5개의 좋아요
정말 멋진 결과네요!
최근에 Mastodon 서버를 운영하는 CoSocial Co-op을 위해 Discourse 서버를 구축했습니다. OAuth2 플러그인을 설정하여 우리 Mastodon 서버 → https://members.cosocial.ca (꽤나 단순한 신규 설치로, 그저 "OAuth 검증용"입니다)로부터의 로그인만 허용하도록 했습니다.
제 질문이자 기능 요청은 다음과 같습니다. Mastodon의 액터(actors)를 Discourse 계정으로 병합/연결할 수 있도록 해 주세요. 이렇게 하면 Mastodon에서 계정으로 답글을 달 때, 해당 Discourse 계정과 연결되거나 소유 관계가 될 수 있습니다.
Lemmy가 이걸 어떻게 하지 않는지
Lemmy가 이걸 하지 않는 방식을 문서화했습니다 – Mastodon을 통해 상호작용할 수 있고, 해당 Mastodon 계정에 대해 Lemmy에서 계정이 생성되지만, 실제로 로그인하여 Mastodon 계정으로 Lemmy의 1급(first class) 기능을 사용할 수는 없습니다.
4개의 좋아요
해당 안건은 의제에 올라 있습니다…
이미 검토 대기열에 올라 있습니다.
3개의 좋아요
좋아요. 내 Discourse OAuth 플러그인 사용자들이 이 AP 플러그인과 상호 운용성을 위해 "다시 확인"을 해야 하는 것 같습니다.
현재 단계에서는 전혀 문제가 되지 않는다고 생각합니다. 다만 충돌이 없다면 OAuth 서버를 또 하나의 관점으로 짚어 두고 싶을 뿐입니다. "있으면 좋은 것"은 "Mastodon 서버와 OAuth를 사용하는 경우, AP 액터 ID를 자동으로 연결해 주는 것"이겠죠. 완전히 미래적인 아이디어이고, 이런 환경에서는 정말 독특한 점이기도 합니다!
(그 부분을 보기 위해 페이지를 열지 않은 점 죄송합니다! 좋습니다!)
1개의 좋아요
이 기능 집합을 추가하는 PR이 이제 병합되었습니다.
Angus가 위에서 언급했듯이, 다음 단계는 OAuth 토큰을 통한 사용자 인증입니다.
2개의 좋아요
방금 확인했던 원시 마크다운이 그대로 출력되는 문제는 메타(meta)에도 영향을 미치는 것 같습니다. 저는 @feature@meta.discourse.org를 팔로우하고 있었는데, 몇 시간 전에 해당 액터(Actor)에서 연동(federated)된 게시글이 생성되었습니다:
이 게시글은 제 Mastodon에서 다음과 같이 깨져서 표시되었습니다:
Elk에서는 다음과 같이 표시됩니다. 조금은 낫긴 합니다:
방금 제 순수 Mastodon 계정에서 이 문제를 테스트하기 위해 @feature@meta.discourse.org를 팔로우하기 시작했지만, 물론 이 특정 게시글을 거기서 확인하기에는 너무 늦었습니다. 
따라서 제 인스톨레이션에서 방금 확인했던 임베디드 마크다운 문제는 잘못된 데이터베이스 때문이 아니었습니다. 혹은 데이터베이스 문제였다면, 그것은 메타와 공유되는 데이터베이스 문제였을 것이며, 따라서 제 테스트와 관련이 없을 가능성이 큽니다.
2개의 좋아요
네, 재현할 수 있어요. 마스토돈 인스턴스와 Ivory(iOS 앱)에서도 비슷한 출력을 확인했습니다.
2개의 좋아요
이것이 제대로 작동하는지 확실하지 않습니다. 플러그인은 활성화되어 있고 ActivityPub가 활성화된 카테고리에서 주제를 만들었지만, 게시물 옆에 배지가 보이지 않습니다. (또한 해당 카테고리의 ActivityPub 액터를 팔로우하려는 시도가 실패한 것 같습니다. 사용자가 수동으로 팔로우를 승인해야 하는 서버처럼 작동하고 있기 때문입니다.)
방금 메타의 #contribute:feature에서도 같은 문제가 발생한 것 같다는 걸 알게 되었습니다.
1개의 좋아요
제한 사항에 대한 최종 목표를, 중간 상태에 대한 걱정 없이 이해할 수 있으면 좋겠습니다.
예를 들어, 어떤 PR에서 플러그인이 활성화된 경우 게시물의 소유자를 변경하는 것이 차단된다는 언급을 본 것 같습니다. 관리자로써, 저는 이 기능을 드문 경우에 사용해야 합니다(예: 카테고리版主를 변경할 때, 새로운 주요 카테고리版主를 해당 카테고리의 고정 게시물 소유자로 설정하는 경우). 결국에는 소유권 변경이 차단되는 대신 삭제 후 재게시 또는 단순히 무시되는 방식으로 처리되기를 희망합니다.
또한 카테고리 간 게시물 이동에 대해서도 궁금합니다. 특히 새 사용자가 잘못된 카테고리에 게시물을 올리는 경우가 많아서, 저는 이 작업을 비교적 자주 수행해야 합니다. 당연히, 이는 한 카테고리 액터가 부스트를 제거하고 새로운 카테고리 액터가 부스트를 추가하는 결과로 이어져야 하며, 기본 게시물 자체는 삭제되지 않아야 합니다. 이렇게 하면 다른 사용자가 게시물을 보고 부스트를 했더라도, 카테고리 액터의 부스트가 사라진다는 이유만으로 그들의 부스트가 사라지지 않을 것입니다.
일반적으로, 현재 지정된 기능 개발이 완료된 후 이 플러그인이 추가되었을 때 어떤 것이 허용되지 않을 것으로 기대하는지, 현재 적용된 제한 사항과 관계없이 아는 것이 정말로 도움이 될 것입니다.
1개의 좋아요
2개의 좋아요
추가로 보고해 주셔서 감사합니다. 이 문제를 조사하고 있습니다.
보고해 주셔서 감사합니다. 이 문제를 조사하고 있습니다.
말씀하신 뜻을 이해하고 있지만,
- 플러그인이 적극적으로 개발 중인 단계에서 이러한 방식으로 설명을 드리면 생산적이지 않을 수 있습니다. 설명 내용이 언제든 변경될 수 있기 때문입니다.
- 플러그인이 이미 처리하는 다양한 시나리오와 엣지 케이스가 많습니다. 이 시점에서 모든 것을 서술적으로 설명하려면 너무 많은 시간이 걸릴 것입니다(즉, 이 긴 게시글을 여러 번 작성하는 것과 같습니다). 현재 플러그인에는 이미 400개 이상의 스펙이 존재합니다.
- 그럼에도 불구하고, 제한 사항에 대한 서술적 설명은 PR과 커밋의 코멘트에서 자주 다루어지고 있으며, 여러분도 이미 그 내용을 읽고 계실 것입니다.
이 문제는 PR에서 깊이 있게 논의되었습니다.
AP(AktivityPub) 토픽에서 관리자 포함하여 게시물 소유자 변경 및 게시물 위키 설정을 제한했습니다. 이는 원격 AP 게시물이 원본과의 충실도를 유지해야 하며, 두 동작 모두 해당 충실도를 깨뜨릴 가능성이 있기 때문입니다.
위키 및 게시물 소유자 변경과 연동(federation)이 작동하도록 하는 방법이 있을 수 있지만, 이는 여러 플랫폼으로 연동되는 객체와 연관된 액터를 복제하거나 변경해야 하므로 향후 PR에서 "기능"으로 추가하는 것을 제안합니다. 저는 가져온 AP 게시물(노트)의 소유자 변경을 허용하는 것은 영원히 불가능할 것이라 생각합니다. 왜냐하면 액터/객체 연관관계는 Discourse가 소유하는 것이 아니라, 콘텐츠가 작성된 장소를 소유하기 때문입니다. 예를 들어, 가져온 노트와 연관된 게시물의 삭제는 엄밀한 의미의 "삭제"라기보다는 노트를 표시하지 않기로 선택한 것에 가깝습니다.
게시물 이동에 관여하는 시나리오는 꽤 다양합니다. 현재로서는 여러분이 언급한 특정 경우, 즉 ActivityPub가 활성화된 두 다른 카테고리 사이에서 게시물을 이동하는 경우를 처리하겠습니다.
게시물이 카테고리 간 이동되는 시점이 게시물이 처음 잘못된 카테고리에 게시된 직후에 이동이 발생하는 경우뿐이라고 가정하고 계십니다. 만약 게시물이 작성된 지 4개월 후에, 특정 게시물 집합을 다른 카테고리의 새 토픽으로 통합하고 싶어서 해당 게시물을 다른 카테고리로 이동한다면 어떻게 될까요? 그 시나리오에서 원래 부스트에 대한 "Undo"를 보내는 것이 합리적일까요?
이는 ‘First Post’(첫 게시물) 구성인지 ‘Full Topic’(전체 토픽) 구성인지에 따라 다릅니다. 전자(First Post)의 경우, 카테고리 이동 시나리오를 처리하기 위해 첫 게시물을 수동으로 게시할 수 있는 버튼을 추가할 것입니다. 후자(Full Topic)의 경우, 자동으로 부스트를 추가하는 것이 합리적일 수 있으며, 이 부분은 더 생각해 보겠습니다.
말씀하신 뜻을 이해하고 있지만, 위 Phase 2 스펙에서 이미 최종 상태에 대한 상당한 세부 정보를 공유했습니다. 그 스펙을 넘어, 가능한 한 부드럽게 말씀드리자면, 제가 여러분과, 그리고 Discourse.org 팀과 동시에 모든 사용 사례와 시나리오를 깊이 있게 논의하면서 작업하기에는 그 수가 너무 많습니다. 
Phase 2가 완료되면 예상 동작에 대한 일반 개요를 OP(원본 게시글)에 업데이트하겠습니다.
1개의 좋아요
이 문제를 재현할 수 없습니다. 테스트용 Mastodon 계정으로 feature@meta.discourse.org를 팔로우했는데, 오류가 표시되지 않았습니다 (Mastodon과 Discourse 모두에서).
1개의 좋아요
제가 따랐던 인스턴스와 관련이 있을 수도 있는데, 이 인스턴스가 특별한 행동을 하나요?
아, 죄송합니다. 명확한 질문을 하려다 보니 많은 작업을 요청하는 것처럼 들렸나 봅니다. 전달에 문제가 있었네요. 세심한 답변에 감사드립니다.
제가 요청하고자 했던 것은 바로 이것이었지, 이 스레드에서 지속적인 상세 업데이트를 원한 것이 아닙니다. "현재 지정된 기능 개발이 완료된 이후(after the currently-specified feature development is complete)"라는 문구에서 '이후’라고 한 것은 명확한 정보가 가치 있을 시점을 의미한 것이지, 지금부터 미래의 상태를 설명해 달라는 뜻이 아니었습니다. 제 질문이 모호하게 표현되었네요. 죄송합니다!
제가 진정으로 이해하고 싶었던 것은 바로 이 부분입니다: 대략적으로 말하자면, 최종 목표가 Discourse를 정통 ActivityPub가 지원하는 기능으로만 제한하는 것인지, 아니면 제한이 없는 네이티브 Discourse 경험을 기반으로 페더레이션(federate)을 최선의 노력(best-effort)으로 Fediverse에 연결하는 것인가요? 이전에 Discourse 통합 관련 경험을 바탕으로 저는 최선의 노력 방식일 것으로 예상했습니다. 하지만 이제 개발 과정의 일시적 조치가 아니라, Discourse 기능에 대한 비용을 감수하더라도 정합성을 추구하는 것이 여러분의 계획임을 이해했습니다.
저는 그렇게 가정하지 않습니다. 왜 4개월이라는 시간이 여기서 차이를 만들까요? 이제야 페더레이션이 되는 카테고리에 들어온 것이므로, 페더레이션 카테고리가 이를 부스트하지 않는 이유가 무엇인가요? 저는 적어도 무심코 그렇게 일어날 것이라고 예상했습니다. 저는 종종 몇 달 된 포스트를 부스트하는 사람들을 자주 보므로, 이것이 다른 이유가 될 만한 특별한 사유를 알지 못합니다.
그리고 네, 원래의 부스트에 대해 Undo를 보내는 것이 합리적이라고 생각합니다. 그것은 일반적인做法입니다. (실제로, 부스트에 대한 Undo를 한 후 새로운 부스트를 하는 것은 콘텐츠를 "bump"하는 전형적인 메커니즘입니다. 이 목적과는 무관하지만, 부스트에 대한 Undo가 일반적으로 사용된다는 것을 보여줌으로써 다른 ActivityPub 구현체에게 문제를 일으키지 않아야 함을 시사합니다.)
지금 feature@meta.discourse.org에 대해 mastodon.cloud에서 같은 현상을 보고 있습니다. 여기서는 순수한 바닐라 Mastodon을 실행하고 있다고 생각합니다.
1개의 좋아요
개인적으로는 어느 쪽이든 그렇게까지 깊이 생각하지 않습니다. Discourse.org가 여기서 전반적인 방향을 설정하겠지만, 넓은 의미로 결정은 어떻게 작동하는지와 실용성에 기반하여 이루어집니다. 출처(provenance)와 관계없이 모든 게시물에서 작성자 변경을 허용할 수 있는 합리적이고 지속 가능한 방법이 있다면 그것은 좋은 일이겠죠.
원래 부스트의 취소(undo)에만 초점을 맞추면, 그 특정 Undo는 목적을 달성하는 것 같지 않습니다. 또한 제 예시가 보여주려 했던 것처럼, 일부 시나리오에서는 다소 의외일 수도 있습니다. 카테고리 이동의 의도는 콘텐츠의 원래 "발견 가능성(discoverability)"을 되돌리는(Undo) 것이 아닐 수 있습니다. 나중에 다른 이유로 콘텐츠의 구성을 변경하려는 것일 수 있습니다.
다른 방식으로 말하자면, Discourse에서 카테고리 변경 시 원래의 Announce에 대한 자동 되돌리기를 적용하는 것은 일부 시나리오에서는 작동하지만 다른 시나리오에서는 그렇지 않습니다. 그리고 더 합리적인 것으로 보이는 시나리오에서도, 원래의 Announce는 실제로 해를 끼치지 않습니다. 따라서 최소 해(minimum harm)와 최소 의외성(minimum surprise) 원칙을 추구한다면, 원래의 Announce를 그대로 두는 것이 더 합리적이라고 느껴집니다. 제가 무언가를 놓치고 있다면 죄송합니다.
다른 관점에서 생각해보면, 카테고리 액터(Category Actor)의 Announce 활동이 카테고리 자체의 분류학적(taxonomic) 역할과 동일시하는 것은 적절하지 않다고 생각합니다. Announce는 카테고리 액터가 팔로워에게 콘텐츠를 공유하는 방식이지만, 그 자체로는 분류학(taxonomy)이 아닙니다. 그것은 Fediverse 내에서 콘텐츠가 발견되는 하나의 방식일 뿐입니다. 카테고리와 카테고리 액터의 Announce 활동 사이에 1:1 관계가 반드시 필요하다고 생각하지 않습니다.
3개의 좋아요
아. 그렇다면 정말로 팀에게 물어볼 문제네요. 
그것도 합리적입니다. 동의합니다. 부스트(강화)를 되돌릴 큰 가치는 없으니까요.
즉, 이것은 엣지 트리거(edge-triggered) 신호입니다. "포스트가 작성되었거나 카테고리로 이동됨으로써 이 카테고리에 방금 들어왔다"는 의미입니다. 개념적으로는 간단합니다.
그렇다면 포스트의 작성자 변경도 비슷한 방식으로 생각할 수 있을 것입니다. 새로운 행위자(actor)가 새로운 작성자의 포스트에 대해 새로운 활동을 생성하는 것이며, 이전 작성자의 이름으로 생성된 이전 활동에 대해 특별히 무언가를 할 필요는 없습니다. 이전 작성자는 더 이상 편집을 작성하지 않을 것이기 때문이고, 새로운 변경 사항에 대한 공로를 인정받아야 할 이유도 없기 때문입니다. 그들은 실제로 Discourse에서 자신의 포스트를 삭제한 것이 아니므로, 원래 작성자의 활동을 삭제하는 것은 반드시 근본적인 진실을 반영하는 것은 아닙니다. 하지만 이전 작성자의 행위자가 이전에 게시한 내용은 그들이 작성한 것이므로, 그 포스트들을 삭제할 이유는 없습니다. 그리고 누군가가 Discourse로 돌아가는 링크를 따라가면, (충분한 권한이 주어질 경우) 편집 이력 보기와 함께 현재 내용과 작성자를 볼 수 있을 것입니다.
위키에도 동일한 논리가 적용됩니다. 위키는 Discourse에서 단일 작성자로 표시되지만 다른 사용자의 집필을 허용합니다. 다른 작성자에 의한 업데이트는 광범위하게 귀속되지 않습니다(이력을 읽을 충분한 권한이 있는 경우를 제외하고). 실제로 그 귀속이 Discourse 내 웹 뷰에서 아바타로 표시되는지, 아니면 활동과 관련된 ActivityPub 행위자인지는 별로 중요하지 않습니다. 최종 결과는 다른 렌더링 파이프라인의 끝에서 인간 독자에게 제시되는 귀속 정보이므로요.
1개의 좋아요
음, 동의하기 어렵습니다. 이렇게 되면 Fediverse에서 서로 다른 행위자가 작성한 동일한 두 개의 노트(Note)가 생성될 것입니다. 그리고 이 둘 다 여러 플랫폼에서 여전히 표시될 것입니다. 해당 콘텐츠에 처음 방문하는 새로운 사용자는 서로 다른 사람이 작성한 동일한 콘텐츠를 보게 될 것입니다. 반면, Discourse에서 작성자를 변경하는 것은 본질적으로 역사를 다시 쓰는 것과 같습니다. 콘텐츠에 처음 방문하는 새로운 사용자에게는 단순히 새로운 작성자만 보이기 때문입니다. 여기에는 차이가 있다고 생각하지 않나요?
전부 이해가 되지는 않습니다. 혹시 위키 게시물에 대한 모든 편집이, 누가 하든, 원래의 행위자(즉, 그 게시물을 올린 사람)에게 귀속되는 표준 업데이트 활동으로 처리되어야 한다는 말씀이신가요?
이것이 이 PR의 주제이며, 설명 노트가 함께 첨부되어 있습니다.
4개의 좋아요