많은 Discourse 사용자가 직면하는 일반적인 문제는 구독 중인 모든 관심 그룹을 한곳에 모아 보여줄 수 없다는 것입니다. 여러 Discourse 인스턴스의 콘텐츠를 중앙 집중적이고 소셜한 사용자 피드 형태로 소비할 쉬운 방법이 없습니다. Reddit과 같은 중앙 집중식 플랫폼은 모든 커뮤니티에 대한 단일 로그인과 reddit.com 랜딩 페이지에서 단일 스트림으로 표시되는 모든 커뮤니티의 집계 피드를 통해 이를 해결합니다. 우리는 ActivityPub 프로토콜을 통해 이 후자의 기능을 Discourse에서 재현하고자 합니다.
예를 들어, A라는 사용자가 여러 Discourse 인스턴스를 자주 방문한다고 가정해 봅시다. 정치 관련 하나, 취미 관련 둘, 그리고 지역 커뮤니티 포럼 하나를 이용하지만, 모든 관련 콘텐츠를 단일 피드에서 소비할 방법이 없습니다. 반면, 여러 Facebook 그룹이나 Reddit 서브레딧에 가입했다면 가장 관련성 높은 게시물이 이미 피드에 표시됩니다.
스펙 (v1)
Discourse 플러그인을 통해 다음 기능을 활성화하여 MVP 프로토타입을 만들 수 있습니다:
ActivityPub 피드를 요청 시(on demand) 생성 (이미 RSS 피드가 있는 모든 페이지에 대해)
URL에 .rss를 추가하는 것과 유사하게, 올바른 엔드포인트를 요청할 때 AP 프로토콜을 사용하여 콘텐츠를 가져오도록 허용합니다.
URL에 사용자 API 키를 추가하여 비공개 콘텐츠에 대해서도 이를 활성화할 수 있을 것입니다.
포럼 관리자가 카테고리별로 ActivityPub(전송)을 활성화하거나 기본적으로 켜두도록 할 것인가? (@Falco님이 여기에 대해 몇 가지 생각을 가지고 있다고 믿습니다)
이 콘텐츠를 Discourse 포럼 / Mastodon 피드에서 소비하는 방법(수신)을 알아내는 것
다음 단계
우리는 확실히 작게 시작해야 하므로, 처음에는 첫 번째 반복에 포함될 작고 실현 가능한 기능 세트를 결정해야 합니다. 저는 ActivityPub 프로토콜을 살펴보고 있지만, 아직 내부 작동 방식에 익숙하지 않습니다. 따라서 이 주제에 많은 관심을 보여준 다른 분들을 토론에 초대하여(@Falco, @hellekin, @merefield) 첫 번째 반복에 대한 실현 가능한 스펙을 구축하고 위의 스펙에 대한 변경 사항을 권장해 주시길 부탁드립니다.
솔직히 말씀드리면, Facebook에 비유한 원래 제안은 제 이해 범위를 벗어납니다. 저는 Facebook이 실제로 어떤 일을 하는지 전혀 알지 못하며, 그것이 Discourse와 어떤 관련이 있는지 이해하지도 못합니다.
제 이해로는 Discourse의 ActivityPub 지원이 **토픽을 연동(federate)**하거나, 심지어 Discourse 인스턴스 간에 카테고리를 공유하는 데 도움이 될 수 있다고 봅니다. 예를 들어, discourse.joinmastodon.org의 공지 토픽 하나가 관련 있는 #software:mastodon 카테고리에서 socialhub.activitypub.rocks로 연동될 수 있습니다.在那里, 로컬 사용자는 해당 토픽이 로컬 토픽인 것처럼 좋아요, 답글, 인용 등을 할 수 있지만, 원래 토픽은 joinmastodon의 인스턴스에 존재하게 됩니다.
또 다른 측면은, 두 인스턴스 모두에 계정이 있는 경우, 이 계정을 연결할 수 있는 방법이 있어야 한다는 것입니다. 즉, 특정 Discourse 인스턴스를 주요 ID 제공자로 사용하는 방식입니다. 이것이 첫 번째 반복 작업의 초점은 아니라는 점을 이해하고 있지만, "[여기에 좋아하는 ActivityPub 구현체 이름 입력]로 로그인"이라는 상황이 발생할 수 있으므로 이 점을 염두에 두는 것이 좋습니다.
위 제안들에서 제가 이해한 내용은 Android용 Discourse 앱의 복제본으로, 인스턴스 목록을 가지고 모든 인스턴스에서 알림을 받는 구조입니다. 많은 출처에서 온 관련 없는 응답을 **교차(interleave)**시키는 것은 특히 맥락이 사라질 때 다소 위험해 보입니다.
제 이해가 올바른가요? 그리고 제 이해가 ActivityPub와 Discourse 통합에 대한 비전의 두 번째 단계로 좋은 방향이 될까요?
현재의 모든 ActivityPub 구현은 게시물이 안정적인 액터(Actor)에 의해 게시되기를 기대하므로, 다음 중 하나가 필요할 수 있습니다:
모든 게시물을 게시하는 시스템 계정
팔로우 가능한 피드당 하나의 계정
팔로우 가능한 피드당 하나의 계정으로, Discourse 사용자별로 작성된 것으로 간주되는 게시물의 Announce를 수행
첫 번째는 구현이 가장 쉬울 가능성이 높고, 세 번째는 데이터 모델을 가장 잘 매칭시킵니다.
또한 전체 토픽 콘텐츠를 게시할지, 토픽의 첫 번째 게시물만 게시할지, 아니면 /top 페이지의 게시물을 홍보하는 별도의 게시물을 만드는 StackExchange의 트위터 피드 같은 방식을 취할지 선택할 수도 있습니다. 혹은 “상위 게시물” 피드가 그렇게 동작하고, 다른 피드들은 모든 것을 게시하도록 하는 것도 가능합니다…
기술적인 측면에서 URL은 변경될 필요가 없어야 합니다: 모든 서버는 Accept: application/activity+json 또는 그 대체 헤더를 보내기 때문입니다.
ActivityPub에서 서로 다른 시점의 다양한 소스의 피드를 혼합하는 리더 애플리케이션 - "알고리즘 타임라인"을 옵트인(opt-in) 기능으로 재현하는 것 - 은 오랫동안 원해왔던 것인데, 현재 존재하지 않는 것 같습니다.
@hellekin: 크로스 도메인 작성(cross-domain authoring)은 Discourse가 가지고 있는 많은 스팸 방지 보호 기능을 치명적으로 우회할 가능성이 높다고 생각합니다. 읽기는 구현하는 것이 더 중요합니다: 결국, 읽기는 근본적입니다!
솔직히 말하면, 댓글들을 잠시만 살펴봤습니다. 제 제안은 각 카테고리를 독립적인 액터(타입은 “Group”)로 설정하는 것입니다. 그러면 외부에서 사람들이 특정 카테고리에 쉽게 구독할 수 있습니다. 이 카테고리 내의 게시물은 “Group” 계정이 사용자의 게시물을 대신 발표하는 방식으로 구현할 수 있습니다. 이렇게 하면 카테고리 정보와 작성자 정보를 모두 확보할 수 있습니다. 저희는 자체 소프트웨어에서 이 방식을 사용하고 있습니다. JSON-LD 서명을 사용하면 비공개 카테고리에서도 안전하게 적용할 수 있습니다.
문제는 외부에서 오는 댓글을 어떻게 처리할 것인가입니다. 그룹 계정을 "수동 승인"으로 설정하는 것을 제안합니다. 그러면 무분별한 스팸을 방지하기 위해 검증 과정을 추가할 수 있습니다. 이렇게 검증된 계정들은 해당 게시물에 댓글을 달 수 있어야 합니다.
이 방식은 (거의) 전체 페디버스(Fediverse)의 사람들이 디스커스(Discourse) 시스템과 연결하고 상호작용할 수 있도록 즉시 가능하게 해줍니다.
Every category Group actor can have an owner who has power to manage the category: control posting permissions, ban or remove users, set visibility (public or private)…
Local users would create categories on their instance, as long as the instance staff approve their category creations.
If a category owner doesn’t fit their position, the site staff can change them.
That’s the way many centralized forums and communities work. What to improve is making it federating.
Nevertheless, there are still problems:
Should actor ids be mutable? Discourse usernames can be set to modifiable in the site settings. However, I doubt whether other AP software can handle this. Is Object's `id` immutable? - ActivityPub - SocialHub
(More to be mentioned)
못 가서 죄송합니다. 참고로, 우리는 NGI0 자금 지원을 신청하지 않았고, 현재 이 프로젝트에 작업 중인 사람은 아무도 없습니다. 프로토콜에 익숙하지 않아서 이 일을 주도하기에는 가장 적합한 사람이 아니지만, @Falco 님께 언급해서 혹시 이 일을 진행할 생각이 있거나 관심이 있는지 확인해 보겠습니다.
글쎄요, 당시에는 팀원 중 한 명이 신청했었습니다. 그 사람이 더 이상 팀에 있지 않고, 여러분이 선정되었기 때문에 누군가는 이를 승인해야 했을 텐데, 어떤 "우리"를 말씀하시는 건지 모르겠습니다. 어쨌든 @Falco와 논의하는 것을 기대하고 있습니다. 어떤 형태의 AP(ActivitPub) 지원도 ActivityPub 커뮤니티에 정말 도움이 될 것입니다. 특히 Discourse 인스턴스 간 작업을 용이하게 하고 Fediverse와의 통합을 개선할 수 있기 때문입니다.
스팸 방지 문제에 대해서는 충분히 인지하고 있지만, 로컬 계정을 실제로 등록하기 전까지 등록되지 않은 이메일 사용자와 같은 스테이징 Fediverse 사용자를 통해 이 문제를 완화할 수 있다고 생각합니다.
네, 과거에 우리는 자금 지원을 신청했습니다. 하지만 올해早些에 NLnet 팀과 연락하여 프로젝트를 종료하고 우리에게 예약되어 있던 자금을 해제하기로 했습니다. 당시 선정되었더라도, NGI0와의 협력은 현재로서는 취소되었습니다. 물론, 미래에 제안서를 제출할 자유는 있습니다.
@riking도 관심이 있을 것 같다는 것을 방금 기억났습니다
1개의 좋아요
sl007
(Sebastian Lasse | @sl007@mastodon.social)
20
흥미롭네요.
이 프로젝트는 유럽연합 집행위원회의 차세대 인터넷(Next Generation Internet) 프로그램의 재정적 지원으로 NLnet이 설립한 NGI0 Discovery Fund를 통해 자금을 지원받았습니다. 이 기금은 통신 네트워크, 콘텐츠 및 기술 총국(DG Communications Networks, Content and Technology)의 관할 하에 보조금 계약 번호 825322에 따라 운영됩니다.
그러니까: 여기서 말하는 "Discourse"가 또 다른 "Discourse"를 의미하는 건가요?
"프로젝트 자체 웹사이트: https://discourse.org"라는 부분 때문에 궁금해서 물어봅니다…
어쨌든