네, Discourse는 댓글 임베지드 위젯을 통해 비슷한 기능을 제공할 수 있습니다. 이 기능은 특히 활성 사용자가 몇 명뿐인 포럼을 시작할 때 일부 사용자가 느끼는 어색함을 줄이는 데 도움이 될 수 있습니다: AI sockpuppet accounts to jumpstart my community?. 새로운 Discourse 사이트는 블로그 게시물을 활용하여 포럼을 홍보하고 초기 콘텐츠를 채우는 데 사용할 수 있습니다. 현재에도 어느 정도 가능하지만, 사용자가 임베지드 위젯에서 직접 댓글을 달 수 있도록 하면 이 과정을 더욱 매끄럽게 만들 수 있을 것입니다.
3개의 좋아요
워드프레스 쪽에 디스커스(Discourse)와 연동된 간단한 댓글 폼을 제공하여, 방문객들이 댓글을 달기 전에 먼저 디스커스로 가서 계정을 생성해야 하는 번거로움을 줄여준다면, 적어도 나 같은 발행인의 경우 마찰을 줄이고 참여도를 높이는 데 도움이 될 것입니다.
제 사용 사례에서는 댓글 작성자가 이름과 이메일 주소만 입력하면 댓글을 남길 수 있는 것이 이상적입니다. 이렇게 하면 디스커스에서 단계별 사용자(staged user)를 생성하고, 대화를 계속하기 위해 완전한 가입을 초대할 수 있으며, 댓글 작성 자체를 막지는 않습니다.
현재 우리는 게시된 기사에 댓글을 달기 위해 계정을 생성해야 한다는 추가적인 마찰이 참여도를 높이고 궁극적으로 포럼의 커뮤니티를 성장시키는 것을 어렵게 만들고 있음을 발견하고 있습니다. 예를 들어, 현재 디스커스-워드프레스 통합을 사용하는 우리의 댓글 섹션에 대해 물었을 때 한 저자가 다음과 같은 피드백을 주었습니다:
대화 영역에 관해서: 지금 언급하시니… 그걸 봤던 기억이 나요. 그때 저는 가입하는 데 시간이 걸릴 것 같아 당분간 잊어버리기로 했었거든요. 대부분의 사람들이 그 과정을 겪을 때 어떤 감정을 느낄지에 대한 강력한 증거가 됩니다. 저는 보통 제 글에 대한 댓글을 보는 것에 거의 집착할 정도예요. 스스로 웃으며 "지금 당장 이걸 처리할 만큼 집착하는 건 아닌 것 같군"이라고 말했던 기억이 납니다. 이상적으로는 가입 과정 없이 모든 사람에게 댓글을 열려 있게 하는 것이 좋겠지만, 어떤 수준의 단순화나 편의성도 그곳의 참여도를 높이는 데 도움이 될 것입니다. 그런 종류의 댓글은 보통 충동적인 행동입니다. 사람들이 조금이라도 막히면, 그들은 시간을 들여서까지 하지 않고 그냥 지나칠 가능성이 큽니다.
4개의 좋아요
며칠 전 이 주제에 대해 생각해보게 되었습니다. 이상하게도 블로그 글에 워드프레스 댓글 기능이 있던 시절이 그리워지더군요. 워드프레스는 시작하기가 매우 쉬웠고, 진입 장벽이 거의 없었기 때문입니다.
현재 가입 과정이 정말로 간단하지만, 누군가가 이 글에 댓글을 남기려면 새로운 페이지를 방문해야 합니다. 그 장벽이 너무 부담스럽게 느껴질 수 있다고 생각합니다. 마치 A에 댓글을 남기고 싶은데, A에 댓글을 남기기 위해 B를 방문해야 하고, 다시 A로 돌아와서 댓글을 확인해야 하는 상황과 비슷합니다. A 바로 아래에 A에 대한 댓글을 남길 수 있다면 훨씬 자연스러울 것 같습니다.
사용자를 단계별로 관리하는(staging) 아이디어는 마음에 듭니다. 워드프레스 댓글 양식을 통해 디스코urses 포럼으로 이메일을 보내고, 그렇게 사용자를 단계별로 관리하는 방식으로 이 기능을 만들어볼 수 있을 것 같습니다. 다만, 이렇게 완전히 통합하면 훨씬 복잡해질 것이라 생각합니다.
3개의 좋아요
이전에는 가능했던 것 같은데, 현재 Discourse는 이메일의 "From Header"와 Return Path를 비교하는 것으로 보입니다. 두 값이 일치하지 않으면 이메일이 거부됩니다. (만약 Discourse가 Return Path를 확인하지 않는다면, 댓글 시스템이 쉽게 악용될 수 있습니다 - 어떤 이메일 주소든 양식에 입력할 수 있게 되니까요.)
Discourse를 댓글 시스템으로 사용하는 문제에는 몇 가지 접근 방식이 있습니다. 가장 좋은 접근 방식은 Discourse가 댓글 임베드 iframe을 개선하여 사용자가 인증된 Discourse 사용자로 상호작용할 수 있도록 하는 것이라고 생각합니다. 그것이 불가능하다면, 내장형 Discourse 댓글 웹앱을 개발할 수 있습니다. 흥미로운 프로젝트이지만, 너무 깊이 들어가기 전에 Discourse가 내장형 댓글 iframe을 통해 유사한 기능을 제공하지 않을 것이라는 점을 확신하고 싶습니다.
WordPress에 특화된 몇 가지 해결책도 있습니다. 가장 간단한 방법은 WordPress 댓글과 WP Discourse 플러그인을 모두 활성화하는 것입니다. 위험한 점은 이렇게 하면 Discourse 포럼의 활동이 감소할 수 있다는 것입니다. 하지만 WordPress UI에서 이를 보완하는 방법이 있을 것이라고 생각합니다 - 예를 들어, Discourse에서 진행 중인 관련 대화에 링크를 제공하는 식입니다.
Discourse SSO 제공자로 기능하는 WordPress 사이트에 특화된 것을 개발하는 것도 가능합니다. 저는 이 주제에 대한 이전 게시물들에서 이에 대해 서술했습니다. 이를 잘 수행하려면 WP Discourse 플러그인에 상당한 변경이 필요할 수 있습니다. 다만(여기서 제 생각을 말로 정리해 보겠습니다):
위 스크린샷으로 제가 하려는 것은, Discourse SSO 제공자인 WordPress 사이트의 경우, 댓글을 Discourse 댓글 iframe으로 표시할 수 있다는 것입니다. 댓글은 Discourse API에 게시하는 양식을 통해 생성할 수 있습니다. 새로운 댓글이 추가될 때 iframe이 새로 고침되도록 보장하기 위해 Discourse 댓글 iframe에 일부 변경이 필요할 수 있지만, 사용자가 인증된 Discourse 사용자로 상호작용할 수 있어야 할 필요는 없습니다.
4개의 좋아요
정리하자면, 제 이해가 맞다면 아이디어는 다음과 같습니다. 댓글 작성자가 먼저 WordPress 측에 가입한 뒤, 임베드된 Discourse iframe을 통해 댓글을 남기면 해당 댓글이 Discourse의 토픽에 게시되고, 다시 WordPress 화면이 새로고침되어 댓글이 즉시 표시되도록 하는 것입니다.
WordPress 가입 과정에서 이메일 인증이 이루어질 것으로 생각됩니다. 하지만 이 방식은 Discourse의 SSO 제공자를 WordPress로 변경해야 한다는 것을 의미하며, 가능은 하지만 다소 불행한 상황입니다. 단순히 포럼 가입만 원하는 사용자에게 마찰을 다른 쪽으로 전가하기 때문입니다.
여기서 말씀하신 내용에 동의하는 편입니다:
만약 iframe 안에서 바로 가입할 수 있거나, 적어도 가입 절차가 진행되어 이메일 인증이 완료되면 게시되더라도 댓글 작성을 계속할 수 있는 단계적 과정이 가능하다면, 이는 사용 편의성과 보안 사이의 균형을 잘 맞추는 해결책이 될 것 같습니다.
2개의 좋아요
네, 맞습니다. WordPress가 SSO 제공자라면, 사용자가 Discourse 주제에 댓글을 달 수 있도록 하는 문제는 해결하기가 그렇게 어렵지 않습니다. 현재 WP Discourse 플러그인의 상태에 맞춰 작업할 때 까다로운 부분은 WordPress에서 댓글을 어떻게 표시할지 알아내는 것입니다. 현재 WP Discourse의 댓글 섹션은 Discourse 주제에 대한 답변을 그대로 반영하지 않습니다. 대신 '최고’로 선정된 댓글 중 일부만 표시됩니다.
이 사용 사례를 처리하도록 WP Discourse 플러그인을 업데이트하는 것은 가능하지만, 이를 적절히 수행하려면 Discourse 댓글을 처리하는 방식을 완전히 다시 작성해야 합니다. 이 결정은 제 권한이 아니지만, Discourse 댓글 iframe을 개선하는 데 노력을 기울이는 것이 시간을 더 잘 활용하는 방법이라고 생각합니다.
5개의 좋아요
이 기능을 원한다는 목소리를 더하고 싶어서 글을 남깁니다.
WP(WordPress) 사용자들이 포럼으로 이동할 필요 없이 WP에서 간단히 가입/로그인한 뒤 게시물 바로 아래에 댓글을 달 수 있다면 정말 좋겠습니다. 그렇게 하면 전체가 댓글 시스템처럼 느껴질 것입니다. 사용자의 댓글은 게시물 아래와 생성된 디스코러스(Discourse) 스레드 양쪽에 모두 표시될 것입니다. 그리고 사용자는 디스코러스, 워드프레스, 또는 양쪽에 동시에 게시할 수 있으며, 이 모든 것이 매끄럽게 이루어집니다. 이것이 어떻게 구현될지는 모르겠지만, 기존 플러그인으로 얻고 있는 것보다 훨씬 더 자연스럽고 어색하지 않은 방식으로 WP 댓글을 디스코러스와 통합할 수 있는 방법이며, 현재보다 댓글 수가 크게 증가할 것입니다.
3개의 좋아요
아마도 이 방법이 될 것 같습니다:
하지만 AFAIK(제가 아는 한) 이 방법은 Discourse의 로그인을 완전히 가로채버립니다.
이 경우, 사용자가 WordPress 게시물 바로 아래에 댓글을 게시할 수 있고, 해당 게시물이 대응하는 Discourse 스레드에 자동으로 입력되도록 할 수 있을까요?
현재 이 작업을 진행 중입니다. 첫 번째 버전은 프론트엔드에 Remix 프레임워크를 사용하는 헤드리스 WordPress 사이트를 위해 제작됩니다. 이 작업이 완료되면 일반 WordPress 사이트를 위한 버전도 만들 예정입니다. 아마도 WP Discourse 플러그인을 확장하는 플러그인 형태가 될 것입니다. 헤드리스 WordPress 사이트에서 수행하는 작업의 대부분을 일반 WordPress 사이트로 이식할 수 있기를 희망하지만, 일부 타협이 필요할 수도 있습니다.
외부 사이트에서 사용자가 직접 댓글을 달 수 있도록 하는 것은 구현이 매우 간단합니다. 주요 요구 사항은 외부 사이트가 사용자의 Discourse 인증 정보를 접근할 수 있어야 한다는 것입니다. 이는 외부 사이트를 Discourse의 DiscourseConnect 제공자로 사용하는 방법이나, Discourse를 외부 사이트의 DiscourseConnect 제공자로 설정하는 방법으로 수행할 수 있습니다.
두 번째 시나리오(Discourse의 DiscourseConnect 제공자가 외부 사이트가 아닌 경우)에서는, 사용자가 외부 사이트에서 댓글을 달려고 할 때 외부 사이트의 계정을 Discourse 계정에 연결해야 합니다(아직 Discourse에 가입하지 않았다면 가입해야 합니다). 이는 사용자의 관점에서 상당히 매끄럽게 처리될 수 있습니다.
그러나 위의 변경 사항만으로는 전체가 일반적인 댓글 시스템처럼 느껴지지 않습니다. 댓글 시스템에 대한 일반적인 기대는 모든 댓글을 읽고 상호작용할 수 있다는 것입니다. WP Discourse 플러그인은 Discourse가 제공하는 특수 라우트에서 가져온 일부 댓글만 표시합니다. 댓글에 대한 상호작용 기능을 제공하지 않습니다.
이 문제의 어려운 부분은 다음과 같습니다:
- 수천 개에 달할 수 있는 주제의 모든 댓글을 WordPress에서 페이지네이션하는 것
- 긴 댓글 목록에서 사용자가 어디에 있는지 알려주는 UI를 제공하는 것
- 다른 댓글에 대한 직접적인 답변인 댓글을 어떻게 표시할지 결정하는 것. (Discourse의 이 관행은 대부분의 댓글 시스템이 답변을 처리하는 방식과 일치하지 않습니다.)
- 사용자가 댓글에 직접 답변하거나, 댓글에 좋아요를 누르거나, 자신의 댓글을 수정하는 등의 기능을 허용하는 것
- Discourse에서 생성되어 외부 사이트에서 쉽게 렌더링하거나 상호작용할 수 없는 콘텐츠나 마크업을 포함할 수 있는 댓글을 처리하는 것. (예: 원박스, 투표 등)
- 최신, 가장 오래된, 최고 등 기준으로 댓글을 필터링하는 방법을 제공하는 것
이 모든 것은 외부 사이트의 서버에 과도한 부하를 주거나, Discourse에 너무 많은 API 요청을 하거나, 사용자 기기의 메모리를 너무 많이 사용하지 않으면서(목표는 가벼운 댓글 시스템을 만드는 것입니다) 달성되어야 합니다. 이는 달성 가능하지만, 기존 WP Discourse 코드를 대규모로 수정하지 않고 단순히 추가할 수 있는 것이 아닙니다.
4개의 좋아요
시작하셨다니 정말 반갑습니다!
한 가지 생각이 드는데, 이 아이디어의 일부가 사람들이 댓글을 달기까지의 마찰을 줄이는 것이므로, 첫 번째 댓글 작성 과정의 매끄러움에 초점을 맞추는 것이 좋은 방법이 될 수 있을 것 같습니다. 위에서 언급했듯이, 많은 사람들이 단순히 이메일 주소만으로 댓글을 달 수 있기를 원하는 것 같습니다. 그렇다면 문제는 인증 및 로그인, 또는 계정 생성이 될 텐데(물론 DiscourseConnect가 어떻게 구성되느냐에 따라 달라지겠지만요).
사용자가 일단 진입하면, Discourse 기반의 모든 토론 기능을 활용하기 위해 해당 포럼 주제에 더 자주 방문할 가능성이 높을 것이라고 생각합니다. 다만, 문제의 어려운 부분들이 “첫 번째 댓글”이라는 문제를 해결하는 것을 방해하지 않기를 바랍니다. 그렇게 되면 수천 개의 댓글에 대해 페이지네이션을 어떻게 처리할지 고민해야 하는 상황은 “좋은 문제”가 될 것입니다. 
4개의 좋아요
네, 그것은 진정한 우려 사항입니다. 첫 번째 단계는 데모 사이트를 온라인에 올리는 것입니다. 테스트할 수 있는 라이브 사이트가 있으면 마찰 지점이 무엇인지 분명해질 것입니다.
익명 사용자의 게시물 댓글 작성을 허용하는 것이 기술적으로 가능할 수 있습니다. 제가 생각할 수 있는 유일한 비해킹(hacky) 방식은 익명 사용자를 대신하여 실제 사용자가 댓글을 게시하는 것입니다. 하지만 그것은 조금 이상하게 느껴집니다.
WordPress에는 “게스트” 사용자의 댓글 생성을 허용하는 설정이 있다는 것을 알고 있습니다. 이는 “게스트” 댓글이 댓글을 생성한 사용자가 댓글 생성 후 나중에 사이트에 가입하더라도 실제 사용자와 연결되지 않는다는 제한 사항이 있습니다. 사용자를 “대신하여” 게시하는 방식도 유사하게 기능해야 합니다 - 익명 댓글을 생성한 사용자가 댓글과 함께 제공한 이메일 주소를 소유한 사람이라는 것을 아는 방법이 없게 됩니다.
이상적으로는, 사용자가 댓글을 생성하기 전에 외부 사이트 또는 Discourse에서 인증되어야 합니다.
사용자의 관점에서 볼 때, 최소한의 마찰은 외부 사이트가 Discourse의 SSO 제공자일 때의 경우입니다. 그러면 사용자는 Discourse 사이트를 방문할 필요 없이 Discourse 주제에 댓글을 달 수 있게 됩니다.
사이트 소유자의 관점에서 볼 때, 사용자를 인증하는 가장 기술적으로 쉬운 방법은 Discourse를 외부 사이트의 인증 제공자로 기능하게 하는 것입니다. 이것은 제가 현재 로컬 테스트 사이트에서 사용하고 있는 구성입니다. 외부(Remix) 사이트에는 사용자 테이블조차 없습니다. 그것은 단순히 Discourse의 /session/sso_provider 루트에서 받은 응답을 기반으로 사용자 세션을 생성할 뿐입니다.
Discourse를 외부 사이트의 인증 제공자로 사용하는 단점은 사용자가 Discourse의 등록/로그인 과정을 거쳐야 한다는 것입니다. 그 과정 자체에 문제는 없지만, 사용자가 외부 사이트의 댓글을 남기고 싶을 때 모든 Discourse 자산을 다운로드하도록 강요하는 것처럼 보인다는 점이 예외입니다. 그래서 다소 느립니다. 더 조사해 보겠습니다…
그렇겠네요 더 현실적인 시나리오를 위해 100개 수준으로 줄여보는 것도 좋을 것 같습니다. 제가 하려는 점은 게시물 1페이지(20개 게시물)를 넘어가면 문제가 복잡해진다는 것입니다.
수정: Discourse 초대 기능을 사용하여 프로세스를 간소화할 수 있을 것 같습니다 - 익명 사용자가 게시물에 댓글을 달고 싶다면, 댓글 양식 옆에 이메일 필드가 표시될 것입니다. 댓글을 제출하면 Discourse가 해당 이메일 주소로 초대를 보내도록 트리거됩니다. 초대가 수락될 때까지 댓글은 대기열에 유지됩니다. 이렇게 하면 사용자가 영감이 떠오를 때 댓글을 생성할 수 있고, 댓글의 상태에 대한 즉각적인 피드백을 받을 수 있습니다.
4개의 좋아요
@simon 님의 해결책이 어떤지 궁금합니다.
이와 관련하여 다른 방향으로 개발 중인 솔루션에 대해 언급하고 싶습니다. 바로 ActivityPub를 사용하는 것입니다. 최신 버전의 공식 WordPress ActivityPub 플러그인에는 Discourse ActivityPub 플러그인에 대한 지원이 추가되었습니다.
즉, WordPress ActivityPub 플러그인과 Discourse ActivityPub 플러그인이 모두 설치되어 있다면, WordPress의 액터가 게시글을 작성하거나(또는 WordPress 사이트 전체를) "팔로우"하도록 카테고리를 설정하기만 하면 됩니다. 그러면 WordPress 게시글이 해당 Discourse 카테고리의 새로운 주제로 나타납니다.
(WordPress 플러그인에는 게시 지연 기능이 있어 비디오에서 Discourse에 표시되기까지 약 1분이 걸립니다. 1:40으로 건너뛰어 표시되는 모습을 확인해 보세요.)
WordPress ActivityPub 플러그인은 Activity 수신도 지원하며, 게시글에 대한 답글로 들어오는 활동을 해당 게시글의 "댓글"로 처리하도록 이미 설정되어 있습니다. 다만, Discourse 플러그인이 보내는 Activity와는 아직 그 부분이 작동하지 않습니다(WordPress 플러그인이 아직 announced notes를 지원하지 않는 것 같습니다). 하지만 곧 그 부분도 작동할 것입니다.
자세한 내용은 아래를 참고하세요.
6개의 좋아요
Wordpress 플러그인의 유지보수자 Matthias가 이를 작동하도록 만들었으므로, 곧 Discourse와 Wordpress 간의 게시 공유 및 ActivityPub를 통한 네이티브 양방향 댓글 기능이 지원될 것입니다.
https://socialhub.activitypub.rocks/t/this-is-a-test-federation/4164/2
https://pfefferle.org/this-is-a-test-federation/#comment-148
3개의 좋아요
이 주제는 Discourse 기반의 댓글 시스템이 Coral과 유사한 기능을 제공할 수 있다는 아이디어로 시작되었습니다. 여기에 웹사이트 댓글을 일반적인 Discourse 주제로 분기할 수 있다는 추가적인 장점이 있습니다. Discourse는 웹사이트의 댓글을 관리(모더레이션)하고, 댓글과 관련된 토론이 포럼에서 이루어지도록 하는 기능을 제공합니다.
모더레이션의 필요성은 논쟁의 여지가 없다고 생각합니다.
댓글을 실제 Discourse 주제로 분기할 수 있어야 하는 필요성은 덜 명확할 수 있습니다. 저는 온라인에서 어떤 형태의 대화든 어려운 것이라는 전제에서 생각하고 있습니다. 대면 대화에는 온라인에 존재하지 않는 다양한 미묘한 단서들이 제공되니까요. 소수의 사람들이 아닌 더 많은 사람들과 의미 있는 온라인 대화를 나누기는 거의 불가능합니다. 바로 이 부분이 Discourse가 빛을 발하는 지점입니다. Discourse의 그룹 기능은 특정 주제에 참여할 수 있는 사용자를 제한할 수 있는 기능을 제공합니다. 댓글 작성자 그룹이 폐쇄된 Discourse 주제에 참여하도록 허용할 수 있습니다. 이는 페디버스(Fediverse)의 작동 방식과 거의 반대되는 개념입니다.
그럼에도 불구하고, Discourse/WordPress 페디버스 통합이 어떻게 작동할 수 있을지 궁금합니다. 예를 들어, Sally가 Bob의 WordPress 게시물에 댓글을 달았을 때, Sally에게 Discourse 계정이 있다면 그녀의 댓글에 대해 어떤 일이 일어나길 기대할 수 있을까요? Sally에게 Discourse 계정이 없다면 그녀의 댓글에 대해 어떤 일이 일어나길 기대할 수 있을까요? Sally가 자신의 댓글이 페디버스에 게시되는 것을 거부할 수 있는 방법이 있을까요?
주제에서 약간 벗어나지만, 서방 국가에서 시행되거나 제안되고 있는 다양한 온라인 해악 방지 법안들과 관련하여, Sally의 댓글이 비방으로 판단된다면 그것을 게시한 책임은 누구에게 있을까요? 현재로서는 이 질문에 답할 수 없는 것이라 가정합니다.
3개의 좋아요
흥미롭네요!
ActivityPub가 모더레이션(운영)과 그룹화(그리고 기타 온라인 커뮤니케이션 기준)를 어떻게 처리하는지에 대해 이렇게 생각해보라고 제안합니다. ActivityPub는 기본적으로 통신 표준입니다. 이러한 문제를 처리하기 위한 몇 가지 메커니즘을 제공하지만, 대부분은 시스템 내의 다양한 클라이언트에 그 판단을 맡깁니다.
통신 표준으로서의 이메일은 불완전하지만 유용한 비유가 될 수 있습니다. "이메일"은 인터넷상의 누구와도 메시지를 교환할 수 있게 해주는 통신 표준들의 집합입니다. 스팸과 같은 다양한 “품질 관리” 문제가 있습니다. 우리가 "이메일"이라 부르는 표준 집합 중에는 이러한 문제를 해결하는 데 도움이 되는 측면들(예: DMARC, DKIM, SPF 등)이 있지만, 품질 관리가 주로 처리되는 방식은 이메일 클라이언트 자체에서 이루어집니다. Gmail이 인기 있는 이메일 클라이언트가 된 이유는 부분적으로 스팸(및 유사한 품질 관리 문제)을 상당히 잘 처리했기 때문이라고 할 수 있습니다.
이 비유를 따르자면, Discourse는 ActivityPub의 "Gmail"과 같습니다. Discourse를 훌륭한 토론 플랫폼으로 만들어주는 모든 모더레이션 도구, 사용자 그룹화 및 기타 기능들은 ActivityPub 컨텍스트 내에서 (거의) 그대로 사용할 수 있습니다. 질문들에 대한 답변을 시작하면서 이를 더 자세히 설명해 보겠습니다.
우선 어떤 일이 일어나는지 설명한 후, 더 복잡한 질문들로 넘어가 보겠습니다. 여기서는 많은 부분을 생략하고 기본 사항에 대한 답변에 집중하겠습니다:
-
Sally의 댓글은 Wordpress에서 ActivityPub 객체로 게시됩니다.
-
해당 객체는 Discourse로 가져와져 게시물로 변환됩니다.
-
Sally의 "Actor"가 Discourse의 사용자 계정과 연관되어 있다면, 해당 게시물은 그 사용자 계정과 연관됩니다. 그녀의 Actor가 아직 사용자 계정과 연관되어 있지 않다면, Sally의 actor로부터 스테이징(staged) 사용자가 생성되고, 이 사용자가 해당 게시물의 소유자가 됩니다.
위와 같은 과정이 이 주제에서 어떻게 작동하는지 볼 수 있습니다:
-
Discourse 카테고리 WordPress - SocialHub 는 Matthias의 Wordpress를 팔로우하고 있습니다.
-
Matthias는 그의 일반 WordPress 계정을 사용하여 블로그에 새 기사를 게시했습니다.
-
이는 Discourse에서 새 주제로 나타났으며, 게시물은 Matthias의 Actor와 연관된 스테이징 사용자와 연관되었습니다.
-
댓글이 작동하는 방식은 정확히 동일합니다.
아마도 가장 명백한 질문에 대해 간단히 언급하자면: Matthias는 Wordpress actor에서 생성된 “스테이징” 사용자와 해당 서버의 일반 Discourse 사용자를 일치(reconcile)시킬 수 있을까요?
단기적인 답변은, Discourse 플러그인이 “인가(Authorization)” 기능 집합을 갖추고 있으며, 현재 이 기능을 통해 다른 Discourse 서버나 Mastodon 서버의 actor에 대한 소유권을 주장하여 해당 스테이징 사용자를 내 계정으로 병합할 수 있다는 것입니다(즉, 이제 내 메인 Discourse 계정에서 게시물을 소유하게 됨). 이 기능 집합은 Wordpress로 확장될 수 있습니다. 이 설명이 다소 장황할 수 있고, 이 데모를 통해 제가 무엇을 의미하는지 이해하는 것이 더 쉬울 수 있다고 생각합니다:
장기적인 답변은, 식별 증명(identity proofs)이 언젠가 ActivityPub 활동에 내장되어 사용자 주도 인가의 필요성을 제거할 수 있으며, 이를 통해 "일치화(reconciliation)"가 (더) 자동으로 이루어질 수 있다는 것입니다.
또 다른 질문은, Matthias가 여전히 그의 ActivityPub Actor를 통해 스테이징 사용자의 식별 속성을 제어하고 있기 때문에(이는 Wordpress에서 편집 가능하며, 편집 내용은 Discourse의 스테이징 사용자로 전달됨), "일치화"가 정말로 필요한지 여부에 관한 것입니다.
이 모든 말을 한 이유는 목을 가다듬는 성격의 서론이므로, 여러분의 더 복잡하고 중요한 질문들로 넘어갈 수 있기 위해서입니다. 지금까지는 말이 되는지 모르겠습니다.
2개의 좋아요
잘 이해하고 있습니다.
모더레이션(관리) 문제와 관련하여, 저는 Discourse를 사용하여 WordPress 댓글을 관리하는 것에 대해 이야기하고 있습니다. 이 기능 덕분에 Discourse가 Coral과 유사한 방식으로 사용될 수 있습니다. WordPress 댓글이 실제로는 WordPress에서 API를 통해 Discourse로 게시되는 Discourse 댓글이라면, 이 기능은 쉽게 구현할 수 있습니다. 기본적으로 바로 작동합니다. 이를 통해 Discourse가 제공하는 AI 기반 모더레이션 도구 등을 활용할 수 있습니다. WordPress/Discourse ActivityPub 통합에서도 유사한 결과를 얻을 수 있을지 궁금합니다.
스테이징 사용자의 신원 증명은 무엇인가요? 이메일 주소가 원본 서버에서 전달되나요?
저의 (개인적인) 우려 사항인, 콘텐츠를 페디버스(fediverse) 전체에 게시하고 싶지 않다는 점에 대해, Discourse 사이트와 WordPress 사이트 사이에 1:1 ActivityPub 관계를 설정하는 것이 기술적으로 가능해 보입니다. 하지만 이것이 ActivityPub 프로토콜의 목적을 무색하게 만드는 것은 아닌지 궁금합니다.
수정: 웹사이트와 관련 Discourse 포럼 사이에 윈-윈(win-win) 관계를 구축하는 것이 목표라는 점을 덧붙이는 것이 좋을 것 같습니다. Discourse의 모더레이션 도구는 웹사이트의 댓글 시스템이 잘 관리되고 있다는 확신을 제공하기 위한 것입니다. 웹사이트의 댓글 섹션은 Discourse 사이트에 주제와 사용자를 시드(seed)로 제공하기 위해 사용될 예정입니다.
2개의 좋아요
ActivityPub 객체에서 변환된 게시글에는 API를 통해 생성된 게시글과 거의* 동일한 전처리 및 후처리 함수가 적용됩니다. 진입점은 다릅니다(즉, 게시글 컨트롤러 대신 ActivityPub 컨트롤러를 사용하지만), 게시글이 생성되는 방식은 대부분 동일합니다.
*더 기술적인 용어로 설명하자면, API를 통해 게시글을 생성하면 실제 처리는 NewPostManager를 통해 이루어지며, 이어서 대부분의 작업은 PostCreator로 위임됩니다. 여기서 NewPostManager가 처리하는 주요 사항(현재 맥락에서)은 검토 대기열(review queue)입니다. 나머지는 모두 PostCreator에서 처리됩니다.
현재 ActivityPub 플러그인은 NewPostManager를 건너뛰고 플러그인 자체의 PostHandler에서 PostCreator로 바로 전달합니다. 이는 초기 구현 시 복잡도를 줄이기 위한 조치였습니다. 플러그인의 PostHandler가 게시글을 NewPostManager로 전달하여 검토 대기열 체크의 이점을 누릴 수 없는 본질적인 이유는 없습니다.
요약하자면, ActivityPub 플러그인을 통해 생성된 게시글과 일반 API를 통해 생성된 게시글 사이에 실질적인 차이가 없습니다.
이것에는 몇 가지 단계가 있습니다.
-
첫째, 원본 서버에서 서버로 전송되는 POST 요청은 HTTP 서명을 사용하여 서명되어, 해당 요청이 실제로 원본 서버에서 온 것인지 확인합니다.
-
둘째, 해당 원본 서버의 각 액터(Actor, 즉 사용자)는 UUID, 즉 도메인과 연결되어 피뎱스(fediverse)에서 고유한 ID를 가집니다. 형태는 다음과 같습니다:
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619dActivityPub에서는 이메일이 사용되지 않습니다.
-
수신하는 각 액티비티(Activity, 예: 게시글 유사 객체의 생성)는 특정 액터 ID와 연관됩니다. 그리고 각 액터 ID는 액터 속성으로 해석될 수 있습니다.
-
따라서 서버에서 “액티비티”(예: 새 게시글 유사 객체의 생성)를 수신할 때, 액티비티를 수신한 도메인에 따라 해당 액티비티를 수행한 액터의 속성을 알게 됩니다. 여기서는 전송하는 도메인을 신뢰하게 되는데, 이는 항상 그렇습니다. 예를 들어 Discourse가 WP Discourse 플러그인을 사용하는 WordPress 인스턴스가 올바른 사용자 속성을 전송하도록 신뢰하는 것과 마찬가지입니다.
따라서 스테이징된 사용자 자체는 이메일로 생성된 스테이징된 사용자와 마찬가지로 신원 증명 자체가 필요하지 않습니다.
신원 증명이 필요한 경우는 ActivityPub 액터와 연결된 실제 인물과 다른 Discourse 계정(예: 위 Matthias의 예시)이 자신의 신원을 통합(또는 “조화”)하려는 경우입니다. 단일 Discourse에 사실상 두 개의 "사용자"가 있는 것을 원하지 않을 수 있습니다. 이러한 조화 없이도, 해당 사용자는 다음을 제어할 수 있습니다.
- 소스 도메인을 통해 ActivityPub 액터/스테이징 사용자의 신원 속성 제어(예: WordPress 프로필을 업데이트하면 해당 업데이트가 연동되어 Discourse에도 동일한 변경이 적용됨); 그리고
- 소스 도메인을 통해 ActivityPub 액터/스테이징 사용자와 연관된 콘텐츠 제어(예: WordPress 댓글을 편집하면 Update 액티비티가 전송되어 Discourse에서 처리됨).
그러나, 여전히 Discourse에 두 명의 사용자가 있는 것이 “불편하게” 느껴질 수 있습니다. 그래서 플러그인에는 “인증(Authorization)” 기능 세트를 갖추고 있어, 일반 Discourse 사용자가 해당 스테이징 사용자를 가진 ActivityPub 액터와 연관되어 있음을 보여줄 수 있도록 합니다. 현재 이는 플랫폼별 인증 메커니즘을 통해 수행됩니다:
-
Mastodon의 경우 Mastodon의 OAuth API를 통해 수행됩니다. 이는 관련 액터를 제어하고 있음을 증명하기 위해 Mastodon에서 계정을 인증해야 합니다.
-
Discourse의 경우 User API를 통해 수행됩니다. 이는 이전 게시글의 비디오에서 보여준 것과 동일합니다.
-
WordPress의 경우 동일한 작업을 수행할 수 있는 몇 가지 방법이 있습니다. 예를 들어 WP Discourse 플러그인을 통한 DiscourseConnect 등이 있습니다. 이는 아직 구현되지 않았습니다.
스테이징 사용자와 연관된 액터의 소유권을 증명하면, 스테이징 사용자는 일반 사용자와 병합되고, 해당 사용자의 게시글이 내 것이 되며, 해당 액터와 연관된 새로운 액티비티도 자동으로 내 것이 됩니다. 하지만 이 기능 세트는 UX 개선을 위한 것이며, 엄밀히 말하면 필수적이지는 않습니다. 이러한 다양한 사용자 뒤의 실제 인물은 처음부터 사용자 속성과 콘텐츠를 모두 제어하고 있기 때문입니다.
네, 출간 대상의 채널을 지정하고, 수신 공개물의 소스를 제한하는 것은 가능합니다. 이것이 ActivityPub의 목적을 무색하게 만드는지는 논쟁의 여지가 있습니다. 엄밀히 말하면 ActivityPub는 단지 표준일 뿐입니다. 저는 이 표준을 이런 방식으로 사용할 수 없는 이유가 없다고 주장합니다. 역사적으로 ActivityPub는 탈중앙화 소셜 네트워크, 특히 Mastodon과 연관되어 왔기 때문에, 이러한 접근 방식이 ActivityPub의 목적을 무색하게 만드는 것처럼 느껴질 수 있습니다. 하지만 저는 ActivityPub 표준 자체와 그 기존 구현들 사이의 구분을 분명히 하고 싶습니다.
또한 이 맥락에서, 이메일과 마찬가지로 우리가 "ActivityPub"이라고 부르는 것은 실제로 표준들의 모음입니다. "ActivityPub"이라는 제목의 표준 문서는 여기서 주요한 역할을 하는 주요 객체를 설명하는 "ActivityStreams"라는 다른 표준 문서와 함께 읽어야 합니다. ActivityStreams 표준은 ActivityPub 자체보다 더 확고하게 "서비스 중립적"입니다(즉, 탈중앙화 소셜 네트워크와 덜 연결되어 있음).
(또 다른) 비유를 들자면, 블록체인이라는 기술은 단순히 탈중앙화 원장이며, 처음 설명을 들었을 때 19세기(호주에서) 부동산 거래에서의 사기를 방지하기 위해 발명된 토지 등기 시스템인 토렌스 시스템(Torrens System)을 떠올리게 했습니다. 블록체인이 발명된 본질적인 이유(즉, 부동산 거래에서의 사기 방지)와 거의 동일한 이유였습니다. 하지만 블록체인의 가장 인기 있는 구현은 Bitcoin이며, 이는 (다른) 특정 용도와 문화적 뉘앙스를 가지고 있습니다. 이 비유가 완벽하지는 않지만, Mastodon과 탈중앙화 소셜 네트워크가 ActivityPub에 대한 관계라고 생각하면, Bitcoin이 블록체인에 대한 관계라고 볼 수 있습니다.
실제로, 제가 NodeBB, Flarum 등과 함께 새로운 W3C ActivityPub for Forums 워킹 그룹을 설립하는 데 도움을 준 이유 중 하나는, ActivityPub 통합의 초점을 기존 구현들(예: Mastodon)에서 포럼의 관심사, 예를 들어 여러분이 제기하고 있는 모더레이션과 같은 문제로 이동시키려는 시도입니다. 사실 우리의 다음 회의는 오늘입니다. 시간이 있으시다면, 동료 “디스크러스 사용자(Discourser)”(이런 표현이 맞는 건가요?)를 그곳에 모시고 싶습니다
4개의 좋아요
저는 WordPress에 _표시_되는 댓글을 Discourse의 모더레이션 도구를 사용하여 관리하는 것에 대해 이야기하고 있습니다. 기술적으로는 Discourse API 요청이나 Webhook을 통해 이를 수행할 수 있습니다. Discourse에서 모더레이션 작업이 발생하면, WordPress에서 해당 댓글의 상태를 변경하기 위해 요청을 보낼 수 있습니다.
ActivityPub 게시물이 검토 큐(review queue)로 처리되도록 변경된다고 가정하더라도, 댓글이 WordPress에 처음 게시되는 시점과 Discourse에 나타나는 시점 사이의 시간 지연 문제가 여전히 존재합니다. 이 지연 시간이 몇 분 정도라고 알고 있습니다.
이 특정 사례에서 주요 장점은 "Discourse를 사용하여 웹사이트 댓글을 관리한다"는 것입니다. 여기에는 Discourse의 모더레이션 기능, 신뢰도 레벨 시스템, 검토 큐, AI 기반 모더레이션 도구 등이 나열되어 있습니다. 이러한 도구는 작은 블로그에는 있으면 좋겠지만, 메인스트림 뉴스 사이트에는 필수적인 요구 사항입니다. 댓글이 두 개(또는 그 이상)의 데이터베이스에 존재하는 대신, 댓글의 단일 진실 공급원(single source of truth)으로 Discourse를 사용하는 것이 이 목표를 달성하는 가장 좋은 방법이라고 생각합니다.
정말 좋은 소식입니다! 더 깊이 생각해 볼 시간이 없었지만, 저는 Discourse의 훌륭한 대표자가 되지는 못할 것 같습니다.
토론, 게시물, 사용자를 단순히 데이터 조각으로 취급하는 아이디어에 대해 몇 가지 일반적인 우려가 있습니다. 토론이 이루어지는 맥락이 사라지지 않도록 보장하는 방법이 필요합니다.
더 실용적인 수준에서, ActivityPub 프로토콜은 여러 국가에서 도입되고 있는 온라인 해악(online-harms) 법안보다 먼저 확산되었습니다. 원본 서버에서 데이터를 소비하는 서버가 삭제 요청을 존중한다는 확신이 필요합니다. 그렇지 않으면, 원본 서버에서 콘텐츠를 생성한 사용자는 나중에 해당 국가에서 그 콘텐츠가 유해한 것으로 판단될 경우 법적 불이익을 감수해야 할 위험이 있습니다.
3개의 좋아요