알겠습니다.
꽤나 답답하네요.
친구들이 곧 출시될 ActivityPub 때문에 디스코스를 다른 플랫폼으로 옮겼어요.
이제 또 다들 디스코스를 깎아내리고 있고…
게다가 ActivityPub 공식 포럼까지 디스코스로 넘어와서, 이제 뭘 해야 할지 논쟁을 벌여야 하는 상황이네요…
Lemmy를 개발하는 팀들은 커뮤니티 소프트웨어에서 ActivityPub를 사용 가능하도록 적응시키는 이 분야에서 훌륭한 일을 하고 있습니다:
https://github.com/LemmyNet/lemmy-docs/blob/main/src/en/federation/overview.md
그러나 ActivityPub를 확장해야 했기 때문에, 그들의 activities를 구현하는 다른 소프트웨어는 없습니다.
우리의 연방(federation) 구현은 이미 기능적으로 완성되었지만, 지금까지 ActivityPub 사양 준수에는 전혀 초점을 맞추지 않았습니다. 따라서 Lemmy는 유효한 activities를 주고받는 것을 기대하는 구현체와 호환되지 않을 가능성이 높습니다.
Lemmy가 Mastodon과 호환되도록 만들 수 있다면, 우리는 Lemmy가 사용하는 동일한 API를 구현하고 매핑할 수 있을 것 같습니다.
| Discourse | Lemmy ActivityPub |
|---|---|
| Category | Community |
| Watching | Follow |
| Topic | Post |
| Post | Comment |
| Like | Like |
19개의 좋아요
ActivityPub 용어로는 이것은 Page가 되며, Page 게시 기능을 고려하면 이는 매우 합리적입니다. 첫 번째 부분은 Page로 공지되고, 그 후의 모든 응답은 Note가 됩니다.
Category → Community에 대해서는 확신이 서지 않습니다. AP 지원과 SSO 덕분에 이 구분이 더 유동적이기 때문입니다. 저는 하나의 커뮤니티를 위해 Discourse 인스턴스를 하나 이상 운영하는 경향이 있습니다.
5개의 좋아요
참고로, 다음 Discourse 인스턴스들이 사용자와 주제(Topic)를 모두 공유하기 시작했으며, Discourse의 ActivityPub는 우리 모두에게 매우 유용할 것입니다:
https://love.public.cat/t/what-is-at-stake-with-interoperability/96
7개의 좋아요
흥미롭네요. Mobilizon도 Framasoft에서 개발한 이벤트 계획 수립을 위해 ActivityPub를 사용한다는 점도 주목할 만합니다… Peertube를 만든 사람들입니다.
1개의 좋아요
Discourse가 ActivityPub 구현으로 나아가지 않는 것이 안타깝습니다. 이미 Discourse를 사용 중인 수많은 커뮤니티가 있으며, 이들은 이 기능을 1일차부터 바로 활용할 수 있을 텐데, 그 잠재력이 많이 놓치고 있다고 느껴집니다… 아직 그 사실을 알지 못하더라도요! 
3개의 좋아요
안녕하세요 @rishabh, @riking, @codinghorror,
(아래에 TL;DR이 있습니다)
얼마 전 @sl007와 @hellekin을 통해 이 Phase 1을 단기적으로 추진하지 않을 것이라는 사실을 알게 되었습니다. NGI0 자금 지원이 있더라도 마찬가지입니다. ActivityPub 기반 상호운용성을 지지하는 또 다른 사람으로서, 당연히 아쉬운 점입니다. 하지만 가장 선두에 서 있고 가장 인기 있는 포럼 소프트웨어인 Discourse의 관점에서 보면, 고려해야 할 수많은 힘과 다른 우선순위들이 존재하며, 그런 맥락에서 이 비즈니스 결정은 아마도 매우 합리적일 것입니다:
결정: 제안된 이 RFC는 우선순위를 부여받고 로드맵에 포함될 만큼 충분히 매력적이지 않았습니다.
@Falco가 제안한 "포럼 간 Facebook 유사한 집계 콘텐츠 피드를 만들어서 시작합시다"라는 MVP 접근법을 취한 이 RFC는, 어떤 형태로든 네이티브 ActivityPub 지원을 통해 나올 수 있는 수많은 기능 중 하나일 뿐입니다. 논리적으로 따져볼 때, 이러한 타임라인은 일반적으로 포럼에서 볼 수 있는 것들을 우회하는 것이며, 저에게는 진정한 핵심 기능처럼 보이지 않습니다. 더 보태어 붙인 확장 기능, 즉 있으면 좋은(nice-to-have) 기능에 가깝습니다.
다른 접근법
ActivityPub 지원의 빠른 MVP에 대한 필요성이 해소되었으니, 아마도 반대 과정을 따를 수 있을 것입니다:
아이디어화: 상호운용성 사용 사례를 브레인스토밍하고 비즈니스 이점과 USP 측면에서 실현 가능성을 평가합니다.
즉, Discourse에서 진정으로 매력적으로 가질 만한 기능은 무엇일까요? 또는: 가능한 것들에 대해 루프에 참여하지 않는다면 Discourse가 어떤 배를 놓칠 수 있을까요?
@Falco의 위 최근 게시물에서 그는 Lemmy를 언급합니다. Lemmy는 그들의 비즈니스 도메인과 일치하는 전용 Linked Data 어휘를 기반으로 처음부터 구축되었습니다. 그들은 MVP를 준비하여 프로덕션에 배포했으며, 이제 자체 도메인 위에 기능 집합을 확장하는 것을 검토하고 있습니다. 여기에는 Mastodon과 Pleroma 등이 매우 성공적인 **다른 도메인**인 마이크로블로그와의 연동을 포함할 수 있습니다.
아이디어화 접근법은 이러한 연습을 따를 수 있습니다:
연습: Discourse가 처음부터 자체 ActivityPub 기반 비즈니스 도메인(Linked Data 어휘로 정의됨)에 기반하여 구축되었다면 어땠을지 상상해 봅시다.
이 브레인스토밍 세션에서 자유롭게 생각해보고, 창의성을 자유롭게 발휘합시다.
이 모든 것에서 나오는 사용 사례 목록은 비즈니스 관점에서 충분히 흥미로워 로드맵의 일부가 될 수 있지만, 그렇지 않더라도 커뮤니티가 플러그인과 컴포넌트를 구축하도록 영감을 주고, 나중에 구축할 수 있는 기반을 마련하는 데 도움이 될 수 있습니다.
ActivityPub 대 Fediverse
어플리케이션에 ActivityPub 지원을 갖는다는 것이 무엇을 의미하는지에 대해 광범위한 오해가 있음을 알아차립니다. 많은 사람들이 그 이유가 'Fediverse의 일부가 되기 위해서’라고 생각합니다. 그리고 여기서 생각은 즉시 Mastodon 인스턴스와의 연동, 즉 (연동된) 마이크로블로그 도메인에 합류하기 위한 상호운용성 구현으로 향합니다.
네, ActivityPub 지원을 갖게 되면 이는 매우 매력적인 기회이며, PixelFed (인스타그램 대체재), PeerTube (유튜브 대체재) 및 Lemmy (레딧 대체재)와 같은 많은 다른 애플리케이션들도 이를 시도하고 있습니다. 그들은 Fediverse를 참여하기에 더 매력적인 곳으로 만들며, Fediverse의 미래를 정말로 흥미롭게 만드는 수많은 혁신이 형태를 갖추어 가고 있습니다.
하지만(BUT)…
논리적으로 따져볼 때, Discourse와 같이 대규모 사용자 기반을 대상으로 하는 조직은 다음과 같은 질문을 할 수 있습니다: “약 400만 명 정도의 사용자만 있는 Fediverse와 왜 통합하고 싶을까요?” 또는 “완전히 다른 도메인에서 운영되는 내 소프트웨어에 마이크로블로그를 왜 통합해야 합니까?”. 그들은 그렇게 말하는 것이 맞으며, 그 전제 하에 ActivityPub 구현을 포기할 것입니다.
그러나(HOWEVER)…
ActivityPub 구현은 (마이크로블로그 부분의) Fediverse의 일부가 되는 것보다 훨씬 더 많은 것을 의미합니다. 자체 비즈니스 도메인을 위해 고유하게 설계된 Linked Data 어휘를 구현하고, 자체 제품 인스턴스들이 함께 연동되도록 하는 것은 완벽한 의미가 있습니다. 또는, 같은 어휘를 채택하는 산업 내 경쟁 제품 인스턴스들과 함께 연동하는 것도 마찬가지입니다.
여기 하나의 예로, 코드 포지(github, gitlab, gitea, sourcehut 등)가 구현할 상호운용성 표준을 정의하려는 ForgeFed 프로젝트가 있습니다. 이렇게 하는 것은 큰 의미가 있으며, 특히 중앙 집중식이고 점점 더 폐쇄적인(walled-garden) 플랫폼으로 변해가고 있는 Github에 대한 매력적인 대안을 제공하기 위한 작은 코드 포지 프로젝트들에게 그렇습니다. 광범위하게 채택된다면, 개발자들은 더 이상 흥미로운 코드 프로젝트에 참여하고, 이슈를 등록하고, 댓글을 달고, PR을 제출하기 위해 인터넷 곳곳에 흩어진 서버들에서 수많은 포지 계정을 jongle할 필요가 없을 것입니다.
(위에서 지적했듯이, 여기저기 흩어져 있는 독립형 코드 포지들이 가진 문제점은, 저와 다른 사람들이 수많은 Discourse 커뮤니티에 참여하면서 경험하는 문제와 동일합니다.)
기회: Discourse는 포럼 소프트웨어의 상호운용성 표준을 설정하는 데 주도적 역할을 할 독특한 위치에 있으며, 현재 Discourse 기능 집합과 완벽하게 일치하도록 표준을 형성할 수 있습니다.
당신의 산업에는 혁신적이고, 새로운 접근법을 취하며, 새 기능을 추가하는 데 빠르게 반복하는(누가 그런지 Discourse에서는 가장 잘 알 것입니다 
) 부상하는 경쟁자들이 있습니다. 제 생각에는 기능 완성도 측면에서 Discourse는 여전히 그들의 제품들이 제공하는 것보다 훨씬 위에 있습니다. 또한 제품을 발전시키는 데 도움이 될 수 있는, 그 어떤 곳에서도 볼 수 없는 커뮤니티를 보유하고 있습니다.
하지만 현재 존재하는 상호운용성 기회는 위협이 될 수도 있습니다. 경쟁자들이 먼저 이 기회에 뛰어든다거나, 또는 - 아마도 EU 디지털 시장법(Digital Markets Act)에 의해 주도되어 - 빅테크 플랫폼들이 포럼 소프트웨어 도메인과 겹치는 무언가를 만들 수 있습니다. 이 두 경우 모두에서 Discourse가 이 표준과 정렬하고 그 명세 설계에서 가장 권위 있는 목소리를 내는 것이 더 어려워질 것입니다.
TL;DR
이것은 의도했던 것보다 긴 게시물이 되었습니다. 죄송합니다 
요약하자면, ActivityPub 지원에 대한 현재 입장을 고려할 때, 단기적인 MVP 유사한 초점보다, 장기적으로 ActivityPub 상호운용성이 Discourse에게 USP와 포지셔닝 측면에서 무엇을 가져다줄 수 있는지에 대한 더 광범위한 평가로 넘어가는 것이 신중할 수 있다고 주장합니다. 즉, 아이디어화 단계로 시작하여 ActivityPub 채택의 비즈니스 사례를 상세히 다듬는 것입니다.
(이것이 가장 잘 설정되는 방법 - 관심 있으시다면 - 은 중간에 남겨두겠지만, 단순히 새 AP 토픽을 만들어 상단에 수집된 사용 사례의 요약 위키를 두고, 스레드에서 사용 사례 아이디어를 논의하는 것에서부터 시작할 수 있습니다)
11개의 좋아요
Arnold, 자금 접근이 가능하다면 왜 플러그인으로 이 기능을 위임하지 않는 걸까요?
때때로 플러그인에서 기능을 개발하고 검증하는 것이 더 넓은 범위와 코어 채택에 더 큰 도움이 됩니다.
이것의 좋은 예는 Topic List Previews(플러그인)입니다. Baked Thumbnail previews는 원래 100% 나중에 덧붙인 것이었습니다. 그러나 입증된 인기에 힘입어 이제 Discourse 코어가 네이티브로 섬네일을 지원합니다.
@angus와 저는 코어가 이 아이디어가 충분히 성숙하고 인기 있다고 판단하여 직접 구현할 수 있을 정도로 이를 발전시켰습니다.
이러한 접근 방식은 위험을 낮추고 코어 로드맵에 포함되기 전에 실질적인 장벽을 극복하는 데 도움이 될 수 있습니다.
단순히 이런 생각이 들어서…
9개의 좋아요
마켓플레이스에는 이미 자금 지원 제안이 있었고, 디스코urs 팀의 누군가가 이를 채택했지만, 나중에 채택된 제안이 철회되었습니다. 해당 제안을 여전히 공개되어 있지만, 유럽의 법인이 이를 채택해야 합니다. The Pavilion의 유럽 회원일 수도 있습니다. 기존 제안을 재활용하는 것이 자금 조달에 성공하기까지의 과정을 크게 앞당기는 데 도움이 될 것이므로, 제안서 작성에 기꺼이 도움을 드리겠습니다.
5개의 좋아요
그 문제를 어떻게 해결할 수 있을지 오프라인에서 논의해 볼 수 있습니다.
4개의 좋아요
Dansup에 대한 링크는 지난 몇 년간 사용 가능했던 WordPress의 ActivityPub 플러그인을 떠올리게 합니다. 이 사람처럼, 저는 출시 초기부터 제 WordPress 사이트에서 ActivityPub 플러그인과 현재는 거의 비활성화된 Pterotype을 사용해 왔습니다.
이 플러그인을 사용하면 사이트가 Fediverse의 액터(Actor)가 되며, 예를 들어 @latest@meta.discourse.org와 같은 형태로 표시됩니다. 계정 설명을 추가할 수 있고, 사이트 아이콘이 연동된 사용자 프로필 사진으로 표시됩니다. 게시물은 다른 사용자에게 연동되어 표시되며, 그들의 댓글은 연동된 사용자 아이콘과 이름과 함께 제 사이트에 표시됩니다.
예시 댓글:
@doug@mastodoon.social:
이 연동 관련 스레드를 따라 읽는 것이 정말 재미있었습니다. 좋은 작업 계속해 주세요!
WordPress에서 그저 또 다른 댓글처럼 표시되지만, 동시에 ActivityPub를 통한 진정한 의미의 연동된 댓글이기도 하므로 정말 좋습니다.
수정: Prismo를 확인해 보세요. Ruby / PostgreSQL 기반으로 구축된 Lemmy/Reddit의 연동 버전으로, Discourse의 설계와 더 밀접하게 부합할 수 있습니다.
3개의 좋아요
Hi @merefield,
플러그인 개발은 분명 매우 현실적인 옵션입니다. 제가 진행한 논의에서는 현재 제품과 생태계에서 무엇이 가능/불가능/실행 불가능한지를 잠시 보류하고, 연동(Federation)을 염두에 두고 처음부터 Discourse를 구축했다고 가정하는 "가설적 사고"를 제안했습니다. 이를 통해 모든 가능성을 열린 마음으로 조사하려는 것이었습니다. 우리가 도출해 낸 각 아이디어는 플러그인으로 구현하기에 완벽하게 적합할 수 있습니다.
저는 주로 이 Fediverse의 다양한 측면에서 작업하고 있습니다. 제 답변은 열렬한 Discourse 팬이자 홍보자로서, 그리고 Fediverse를 옹호하는 입장에서 나온 것입니다. Fediverse는 혁신적이며, 저는 이것이 차세대, 사용자 주도적이고 더 인간적인 소셜 미디어 환경을 구축할 최고의 기회라고 생각합니다.
그러나 위 게시물에서 제가 강조하고 싶었던 것은 Fediverse 연동과 완전히 독립적인 상호운용성(Interoperability) 사용 사례가 존재한다는 점입니다. 이는 서로 다른 Discourse 커뮤니티 간의 직접적인 상호운용성을 의미합니다. P.S. ActivityPub 지원의 이 측면에 대한 인식을 높이기 위해 SocialHub 포럼에 후속 게시물을 올렸습니다: Positioning ActivityPub: De-Emphasize "Being Part of the Fediverse" as primary USP - Fediverse Futures - SocialHub
감사합니다, 정말 고맙습니다. 훌륭한 생각이며, 이 스레드가 플러그인 개발자들로 하여금 잠재된 가능성을 발견하도록 영감을 주기를 바랍니다.
네, 정말 좋습니다. 이 프로젝트들은 @merefield가 언급한 Fediverse 지원에 초점을 맞춘 Discourse의 미래 방향성에 훌륭한 영감이 될 수 있습니다.
4개의 좋아요
과거에 우리는 Discourse-Discourse 연동이 전혀 흥미롭지 않다는 결론을 내린 바 있습니다. OpenGraph를 통한 기본적인 상호운용성 기능이 이미 있으며, 이는 충분히 좋은 것으로 보입니다. 설득력 있는 사용 사례가 있는 분이라면 듣고 싶지만, 아직까지 그런 사례를 본 적이 없습니다. 기술적 가능성에 대해만 말씀하셨을 뿐, 이 기술이 실제로 어떤 제품 기능을 가능하게 하는지에 대해서는 언급하지 않으셨습니다.
4개의 좋아요
좋은 지적입니다! 만약 한 포럼의 게시글을 다른 Discourse 포럼의 게시글과 동기화하는 것이 목표라면… 이미 matterbabble과 matterbridge를 함께 사용할 수 있습니다.
1개의 좋아요
아니, 맞습니다. 제가 제안했던 것이 바로 그것입니다(제 TL;DR에서 "ActivityPub 도입의 비즈니스 사례를 구체화하고, 아이디어 구상 단계로 시작하자"라고 한 부분 말입니다).
이 브레인스토밍 제안은 이 스레드의 주제 범위를 훨씬 벗어나고, 특정 기능이나 RFC를 가리키는 것이 아니라 더 거시적인 비전(Vision)에 가깝기 때문에 Community Building 카테고리에 별도의 주제를 생성했습니다:
5개의 좋아요
디스커스에서 ActivityPub 지원을 구현하는 것이 왜 중요한지 @riking에게 설득할 수 있는 출발점이 될 수 있는 비즈니스 사용 사례를 구체화하는 제안을 올려 보았습니다. @merefield, 해당 토론에 참여해 주시겠어요? – 물론 ActivityPub가 지원된다면 훨씬 수월하겠죠!
4개의 좋아요
잘못된 것 같다면 용서해 주시겠지만, feed2toot를 사용하여 RSS 피드를 ActivityPub로 변환하는 것은 어떨까요? Mastodon과 Pleroma를 지원한다고 확인했습니다. Discourse는 기본적으로 카테고리 및 그룹에 대해 RSS 피드를 생성합니다. Hubzilla와 Friendica에도 RSS 지원 기능이 내장되어 있습니다.
그것은 "단방향"만 되는 것 아닌가요? Discourse에서 ActivityPub 인스턴스로 “나가는” 방향만 가능하고, 반대 방향으로는 불가능합니다.
@hellekin 죄송하지만, 여기에서 "사용 사례"를 잘 이해하지 못하겠습니다. 왜 그렇게 해야 하는지, 어떤 이점이 있는지 등을 말씀해 주실 수 있을까요?
그 스레드를 다시 읽어보고 Community has no boundary: Discourse-as-a-Fabric - ideation & brainstorm 에서 아이디어를 확장한 후, Shaping Up a Business Use-Case for ActivityPub in Discourse - Fediverse Futures - SocialHub 에서 다시 생각해보니, 여기에서 그 이유를 자세히 설명해달라는 질문을 한 사람이 없었네요. 이건 저와 다른 AP(액티비티펍) 옹호자들의 실수인 것 같습니다. 죄송합니다.
디스코urses가 연방(Federation) 기능에 대해 더 깊이 살펴보는 것을 꺼리고 있는 이유가 무엇인지, 그리고 액티비티펍 커뮤니티가 더 많은 정보와 지원을 제공할 수 있는 흥미로운 분야가 무엇인지 더 많은 통찰을 공유해 주시겠습니까?
3개의 좋아요