# ActivityPub 지원: 1단계 RFC

**URL:** https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624
**Category:** Feature
**Tags:** rfc
**Created:** [11월 5, 2019, 8:38오전 UTC](https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624 "2019-11-05T08:38:55Z")
**Posts on this page:** 1
**Showing post:** 30

<div class="post-metadata">

### Author: ![aschrijver](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/aschrijver/32/92004_2.png) [@aschrijver](https://meta.discourse.org/u/aschrijver)
#### Post date: [12월 17, 2020, 7:07오전 UTC](https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624/30 "2020-12-17T07:07:26Z")

</div>

안녕하세요 @rishabh, @riking, @codinghorror,

(아래에 TL;DR이 있습니다)

> [@rishabh](#):
>
> 우리는 확실히 작게 시작해야 하므로, 우선 첫 번째 반복에 포함될 작고 실현 가능한 기능 집합을 결정해야 합니다.

얼마 전 @sl007와 @hellekin을 통해 이 Phase 1을 단기적으로 추진하지 않을 것이라는 사실을 알게 되었습니다. NGI0 자금 지원이 있더라도 마찬가지입니다. ActivityPub 기반 상호운용성을 지지하는 또 다른 사람으로서, 당연히 아쉬운 점입니다. 하지만 가장 선두에 서 있고 가장 인기 있는 포럼 소프트웨어인 Discourse의 관점에서 보면, 고려해야 할 수많은 힘과 다른 우선순위들이 존재하며, 그런 맥락에서 이 비즈니스 결정은 아마도 매우 합리적일 것입니다:

> **결정** : 제안된 이 RFC는 우선순위를 부여받고 로드맵에 포함될 만큼 충분히 매력적이지 않았습니다.

@Falco가 제안한 "포럼 간 Facebook 유사한 집계 콘텐츠 피드를 만들어서 시작합시다"라는 MVP 접근법을 취한 이 RFC는, 어떤 형태로든 네이티브 ActivityPub 지원을 통해 나올 수 있는 수많은 기능 중 하나일 뿐입니다. 논리적으로 따져볼 때, 이러한 타임라인은 일반적으로 포럼에서 볼 수 있는 것들을 우회하는 것이며, 저에게는 진정한 핵심 기능처럼 보이지 않습니다. 더 보태어 붙인 확장 기능, 즉 있으면 좋은(nice-to-have) 기능에 가깝습니다.

## 다른 접근법

ActivityPub 지원의 빠른 MVP에 대한 필요성이 해소되었으니, 아마도 반대 과정을 따를 수 있을 것입니다:

> **아이디어화** : 상호운용성 사용 사례를 브레인스토밍하고 비즈니스 이점과 USP 측면에서 실현 가능성을 평가합니다.

즉, Discourse에서 _진정으로_ 매력적으로 가질 만한 기능은 무엇일까요? 또는: 가능한 것들에 대해 루프에 참여하지 않는다면 Discourse가 어떤 배를 놓칠 수 있을까요?

@Falco의 위 [최근 게시물](https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624/25?u=aschrijver)에서 그는 [Lemmy](https://lemmy.ml/)를 언급합니다. Lemmy는 그들의 비즈니스 도메인과 일치하는 전용 Linked Data 어휘를 기반으로 처음부터 구축되었습니다. 그들은 MVP를 준비하여 프로덕션에 배포했으며, 이제 자체 도메인 위에 기능 집합을 확장하는 것을 검토하고 있습니다. 여기에는 Mastodon과 Pleroma 등이 매우 성공적인 \*\*_다른 도메인_\*\*인 마이크로블로그와의 연동을 포함할 수 있습니다.

아이디어화 접근법은 이러한 연습을 따를 수 있습니다:

> **연습** : Discourse가 처음부터 자체 ActivityPub 기반 비즈니스 도메인(Linked Data 어휘로 정의됨)에 기반하여 구축되었다면 어땠을지 상상해 봅시다.

이 브레인스토밍 세션에서 자유롭게 생각해보고, 창의성을 자유롭게 발휘합시다.

이 모든 것에서 나오는 사용 사례 목록은 비즈니스 관점에서 충분히 흥미로워 로드맵의 일부가 될 수 있지만, 그렇지 않더라도 커뮤니티가 플러그인과 컴포넌트를 구축하도록 영감을 주고, 나중에 구축할 수 있는 기반을 마련하는 데 도움이 될 수 있습니다.

## ActivityPub 대 Fediverse

어플리케이션에 ActivityPub 지원을 갖는다는 것이 무엇을 의미하는지에 대해 광범위한 오해가 있음을 알아차립니다. 많은 사람들이 그 이유가 'Fediverse의 일부가 되기 위해서’라고 생각합니다. 그리고 여기서 생각은 즉시 Mastodon 인스턴스와의 연동, 즉 (연동된) 마이크로블로그 도메인에 합류하기 위한 상호운용성 구현으로 향합니다.

네, ActivityPub 지원을 갖게 되면 이는 매우 매력적인 기회이며, [PixelFed](https://pixelfed.org/) (인스타그램 대체재), [PeerTube](https://joinpeertube.org/) (유튜브 대체재) 및 Lemmy (레딧 대체재)와 같은 많은 다른 애플리케이션들도 이를 시도하고 있습니다. 그들은 Fediverse를 참여하기에 더 매력적인 곳으로 만들며, Fediverse의 미래를 정말로 흥미롭게 만드는 수많은 혁신이 형태를 갖추어 가고 있습니다.

하지만(BUT)…

논리적으로 따져볼 때, Discourse와 같이 대규모 사용자 기반을 대상으로 하는 조직은 다음과 같은 질문을 할 수 있습니다: “약 400만 명 정도의 사용자만 있는 Fediverse와 왜 통합하고 싶을까요?” 또는 “완전히 다른 도메인에서 운영되는 내 소프트웨어에 마이크로블로그를 왜 통합해야 합니까?”. 그들은 그렇게 말하는 것이 맞으며, 그 전제 하에 ActivityPub 구현을 포기할 것입니다.

그러나(HOWEVER)…

ActivityPub 구현은 (마이크로블로그 부분의) Fediverse의 일부가 되는 것보다 훨씬 더 많은 것을 의미합니다. 자체 비즈니스 도메인을 위해 고유하게 설계된 Linked Data 어휘를 구현하고, 자체 제품 인스턴스들이 함께 연동되도록 하는 것은 완벽한 의미가 있습니다. 또는, 같은 어휘를 채택하는 산업 내 경쟁 제품 인스턴스들과 함께 연동하는 것도 마찬가지입니다.

여기 하나의 예로, 코드 포지(github, gitlab, gitea, sourcehut 등)가 구현할 상호운용성 표준을 정의하려는 [ForgeFed](https://forgefed.peers.community/) 프로젝트가 있습니다. 이렇게 하는 것은 큰 의미가 있으며, 특히 중앙 집중식이고 점점 더 폐쇄적인(walled-garden) 플랫폼으로 변해가고 있는 Github에 대한 매력적인 대안을 제공하기 위한 작은 코드 포지 프로젝트들에게 그렇습니다. 광범위하게 채택된다면, 개발자들은 더 이상 흥미로운 코드 프로젝트에 참여하고, 이슈를 등록하고, 댓글을 달고, PR을 제출하기 위해 인터넷 곳곳에 흩어진 서버들에서 수많은 포지 계정을 jongle할 필요가 없을 것입니다.

(위에서 지적했듯이, 여기저기 흩어져 있는 독립형 코드 포지들이 가진 문제점은, 저와 다른 사람들이 수많은 Discourse 커뮤니티에 참여하면서 경험하는 문제와 동일합니다.)

> **기회** : Discourse는 포럼 소프트웨어의 상호운용성 표준을 설정하는 데 주도적 역할을 할 독특한 위치에 있으며, 현재 Discourse 기능 집합과 완벽하게 일치하도록 표준을 형성할 수 있습니다.

당신의 산업에는 혁신적이고, 새로운 접근법을 취하며, 새 기능을 추가하는 데 빠르게 반복하는(누가 그런지 Discourse에서는 가장 잘 알 것입니다 🙂) 부상하는 경쟁자들이 있습니다. 제 생각에는 기능 완성도 측면에서 Discourse는 여전히 그들의 제품들이 제공하는 것보다 훨씬 위에 있습니다. 또한 제품을 발전시키는 데 도움이 될 수 있는, 그 어떤 곳에서도 볼 수 없는 커뮤니티를 보유하고 있습니다.

하지만 현재 존재하는 상호운용성 기회는 위협이 될 수도 있습니다. 경쟁자들이 먼저 이 기회에 뛰어든다거나, 또는 - 아마도 EU 디지털 시장법(Digital Markets Act)에 의해 주도되어 - 빅테크 플랫폼들이 포럼 소프트웨어 도메인과 겹치는 무언가를 만들 수 있습니다. 이 두 경우 모두에서 Discourse가 이 표준과 정렬하고 그 명세 설계에서 가장 권위 있는 목소리를 내는 것이 더 어려워질 것입니다.

## TL;DR

이것은 의도했던 것보다 긴 게시물이 되었습니다. 죄송합니다 😊

요약하자면, ActivityPub 지원에 대한 현재 입장을 고려할 때, 단기적인 MVP 유사한 초점보다, 장기적으로 ActivityPub 상호운용성이 Discourse에게 USP와 포지셔닝 측면에서 무엇을 가져다줄 수 있는지에 대한 더 광범위한 평가로 넘어가는 것이 신중할 수 있다고 주장합니다. 즉, 아이디어화 단계로 시작하여 **ActivityPub 채택의 비즈니스 사례를 상세히 다듬는 것** 입니다.

(이것이 가장 잘 설정되는 방법 - 관심 있으시다면 - 은 중간에 남겨두겠지만, 단순히 새 AP 토픽을 만들어 상단에 수집된 사용 사례의 요약 위키를 두고, 스레드에서 사용 사례 아이디어를 논의하는 것에서부터 시작할 수 있습니다)

---

_[View the full topic](https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624)._