ActivityPub C2S 프로토콜이 실제로 채택되지 못한 이유를 살펴보고, FEP 기반의 최소 확장과 Mastodon API 어댑터, 그리고 Flowz 사례를 통해 상호운용 가능한 클라이언트 생태계를 되살리는 경로를 제안한다.
URL: https://www.stevebate.net/activitypub-client-api-a-way-forward/
ActivityPub의 클라이언트-서버(Client-to-Server, C2S) 프로토콜은 서버-서버(Server-to-Server, S2S) 프로토콜과 함께 탈중앙화 소셜 웹의 초석으로 구상되었다. 2018년 W3C에 의해 표준화된 C2S는 모바일 앱이나 웹 클라이언트 같은 사용자용 애플리케이션과 봇이 Activity Streams 2.0 및 JSON-LD를 사용해 소셜 서버와 상호작용하는 방법을 정의한다. 이론적으로는 규격을 준수하는 어떤 클라이언트라도 호환되는 어떤 서버와도 연결할 수 있어, 중앙집중형 API와 독점적 통합에 대한 유연한 연합(federated) 대안을 제공한다.
하지만 이러한 약속에도 불구하고 ActivityPub C2S는 현실 세계에서의 채택이 극히 미미했다. Fediverse의 대부분 플랫폼—지배적인 구현체인 Mastodon을 포함해—은 이를 지원하는 것을 적극적으로 피해 왔다. 대신, 클라이언트의 동작을 서버 내부에 강하게 결합시키는 커스텀 API를 노출한다. 이 파편화는 클라이언트 개발자가 각각의 맞춤형 인터페이스를 대상으로 개발해야 하는 생태계를 낳았고, 그 결과 상호운용성, 이식성, 그리고 연합이라는 더 큰 비전이 희생되었다. Mastodon 팀은 서버 개발자들에게 Mastodon의 클라이언트 API를 구현하지 말 것을 권고해 왔는데, 그 API가 종종 잘못 구현되기 때문이라고 밝힌 바 있다. 일부 비(非) Mastodon 서버 구현에서는 이것이 보안 사고로 이어지기도 했다.
표준 API 접근법은 [...] 클라이언트 개발자와 서비스 제공자 모두에게 도움이 된다. API 클라이언트를 API 서버로부터 분리(decouple)해 주기 때문이다. 클라이언트 개발자는 동일한 코드베이스로 여러 플랫폼을 대상으로 개발할 수 있다. - The ActivityPub book
불행히도 C2S가 외면받아 온 이유가 근거 없는 것은 아니다. 기본 사양은 매우 최소한으로만 정의되어 있으며, 현대 소셜 애플리케이션에 필수로 여겨지는 많은 기능—검색, 미디어 업로드, 실시간 업데이트, 북마크 및 리스트(커스텀 피드) 관리, 팔로워 승인 대기 관리 같은 기본 기능—이 빠져 있다. 이런 기능들 중 일부는 W3C Wiki 같은 비규범적 외부 문서나 비공식 Fediverse Enhancement Proposals (FEPs)에 흩어진 형태로만 기술되어 있다. JSON-LD를 파싱하고 그래프 기반 데이터를 처리해야 한다는 점은 클라이언트 개발자에게 추가 복잡성을 가져온다. 더구나 C2S를 지원하는 서버가 소수이고 그 지원도 대개 부분적이어서, 클라이언트 개발자가 이 프로토콜에 투자할 유인이 적고 그 반대도 마찬가지인 ‘닭이 먼저냐 달걀이 먼저냐’ 문제를 만든다.
이 글은 C2S가 원래 목적을 여전히 달성할 수 있다고 본다. 다만 원칙적(principled)이고, 최소(minimal)이며, 상호운용 가능한(interoperable) 방식으로 확장되어야 한다. 커뮤니티 주도의 FEP를 통해 핵심 공백을 메우고, Flowz 같은 실제 구현에서 배운다면, C2S는 풍부하고 사용자 친화적이며 탈중앙화된 소셜 애플리케이션의 새로운 세대를 위한 실질적 기반이 될 수 있다.
나는 C2S의 기술적 메커니즘, 주요 플랫폼이 이를 거부한 이유, 현재의 제약, 그리고 제대로 확장했을 때 제공하는 이점을 살펴볼 것이다. 또한 FEP가 제시하는 전진 경로와 Flowz가 개념 증명(proof-of-concept)으로서 어떤 역할을 하는지도 탐구한다. 목표는 기존의 독점적 클라이언트 API와 경쟁하려는 것이 아니라, 연합체(Fediverse)에서 클라이언트 선택권, 서버 다양성, 사용자 역량 강화를 되살리는 공유 기반(substrate)으로서 ‘되살아난 C2S’의 필요성을 주장하는 데 있다.
ActivityPub 클라이언트-서버(C2S) 프로토콜은 탈중앙화 소셜 네트워크 환경에서 소셜 미디어 클라이언트가 서버와 직접 통신하는 방법을 정의한다. 핵심적으로 이 프로토콜은 클라이언트가 사용자의 outbox 엔드포인트로 HTTP POST 요청을 보내 활동(activity)을 전송하는 방식으로 동작한다(예: 게시물 생성, 좋아요, 사용자 팔로우). 이 outbox는 사용자가 생성한 모든 활동의 권위 있는(authoritative) 스트림 역할을 한다. 반대로 클라이언트는 inbox 엔드포인트에 HTTP GET 요청을 발행하여 알림이나 메시지 같은 수신 데이터를 받는데, 서버는 클라이언트를 대상으로 한 활동을 이곳에 큐잉한다.
이 상호작용을 보호하고 권한 있는 클라이언트만 사용자를 대신해 동작하도록 보장하기 위해, OAuth 2.0이 비공식적으로 인증 및 인가 방식으로 권장되지만 다른 접근도 허용된다. 이를 통해 클라이언트는 활동을 게시하거나 조회하기 전에 유효한 자격 증명을 제시해야 하며, 사용자 계정과 프라이버시를 보호할 수 있다.
데이터 교환의 기반은 ActivityStreams 2.0 어휘(vocabulary)로, 표준화되고 확장 가능한 JSON-LD 형식이다. 이 데이터 모델은 Create, Like, Follow 등과 같은 소셜 상호작용을 구조화된 링크드 객체로 표현하여 클라이언트와 서버가 이해하고 조작할 수 있게 한다. JSON-LD 사용은 의미적 풍부함과 유연성을 제공하여, 상호운용성을 유지하면서도 구현체가 객체를 확장하거나 커스터마이즈할 수 있게 한다. 클라이언트는 활동 내부에 포함된 링크를 따라가 추가 컨텍스트나 관련 객체를 가져올 수 있으며, 이를 통해 동적이고 유연한 소셜 데이터 그래프가 가능해진다(URI 구조를 미리 고정하는 대신 링크를 따라가며 탐색하는 이 설계를 흔히 follow your nose 디자인이라고 부른다).
C2S의 설계 의도는 ‘진정한 보편성’이다. 단 하나의 클라이언트 애플리케이션이 서버별 커스터마이징이나 독점 API 적응 없이 표준을 준수하는 어떤 서버에도 연결할 수 있어야 한다. 이는 다양한 서버가 각각 고유 API 또는 부분 구현을 제공하여 사용자 경험을 파편화하고 클라이언트 이식성을 제한하는 현재의 생태계와 대비된다. C2S 프로토콜을 준수하면 클라이언트는 다양한 플랫폼 전반에서 매끄럽게 동작할 수 있고, 이는 소셜 웹의 탈중앙화·연합적 특성을 강화하며 사용자 자유와 선택을 촉진한다.
가장 크고 영향력 있는 ActivityPub 구현체인 Mastodon은 2019년에 개발팀이 강한 유보 의견을 표명하면서 C2S 지원을 명시적으로 거부했다. 그들의 주요 비판 중 하나는 C2S 사양이 지나치게 ‘뼈대만’ 있어 풍부한 사용자 경험에 필요한 핵심 기능이 부족하다는 점이었다. 특히 알림, 검색, 타임라인, 뮤트 기능 지원의 부재를 지적했다. 그 결과 C2S를 구현하는 클라이언트는 과도하게 많은 복잡한 로직을 자체적으로 처리해야 하며, 이는 비현실적이라고 보았다.
ActivityPub C2S 사양은 믿기 어려울 정도로 뼈대만 있습니다. 알림(홈 피드와 분리된 형태)이 없고—모두 "inbox"에 섞여 있습니다—검색도 없고, 자동완성도 없고, 도메인 차단도 없고, 뮤트(차단과 다른)도 없고… 등등. 결국 너무 많은 커스텀 어휘와 엔드포인트를 정의하게 될 텐데, 그러느니 Mastodon REST API를 쓰는 게 낫습니다. - Issue Discussion, Eugen Rochko (@Gargron)
Mastodon 팀은 C2S 채택이 가져올 막대한 구현 부담을 강조했다. 그들은 C2S를 통합하려면 "Mastodon의 아키텍처를 다시 구축해야" 하며, 즉각적이거나 "명확한 사용자 이익"이 없다고 말했다. 이 관점은 개발 노력과 아키텍처 변경 비용이 이점보다 클 것이라는 우려를 보여준다. Mastodon은 이미 필요를 충족하는 클라이언트 API를 갖고 있었고, 이것 또한 결정에 영향을 미쳤다.
시간이 지나면서 Mastodon의 독점 클라이언트 API의 지배력은 환경을 더 복잡하게 만들었다. 이 API는 Fediverse에서 클라이언트-서버 상호작용의 사실상(de facto) 표준이 되었고, 서버와 클라이언트 모두에게 이에 대한 호환성을 유지할 강한 유인을 만들었다. 결과적으로 이런 생태계 관성은 C2S 프로토콜의 광범위한 채택을 방해했고, C2S가 활용되지 못하는 악순환을 지속시켰다. 비판자들은 이 파편화가 진정한 상호운용성의 잠재력을 제한하고, 통일된 C2S 구현이 가능케 할 혁신을 억눌렀다고 주장한다.
유망한 설계에도 불구하고, ActivityPub의 클라이언트-서버(C2S) 프로토콜 한계는 광범위한 채택을 가로막는 중대한 기술적 제약이다. 앞서 논의했듯이 특히 눈에 띄는 공백은 검색, 북마크 관리, 리스트 관리(커스텀 피드), 미디어 업로드, 실시간 스트리밍, 액터(actor) 인증 및 인가 같은 기능의 부재다.
놀라운 공백도 있다. 예컨대 ActivityPub 사양은 S2S 프로토콜에서 Announce 활동(“부스트/리블로그” 같은 동작에 사용)을 정의하지만, C2S API에서 Announce를 어떻게 처리해야 하는지는 명시적으로 규정하지 않는다.
이런 누락 요소들은 특히 Mastodon 같은 독점 API가 제공하는 포괄적 기능에 비추어 볼 때, 매끄럽고 기능이 풍부한 사용자 경험을 제공하는 데 결정적이다.
클라이언트 측에서 개발자는 상당한 복잡성을 마주한다. JSON-LD에 의존하는 프로토콜 특성상 클라이언트는 복잡한 링크드 데이터 그래프를 효율적으로 파싱하고, 컨텍스트 및 링크된 객체를 해석(resolution)하며, 다양한 Activity Streams 2.0 타입을 처리해야 한다. 이 가파른 학습 곡선과 링크드 데이터 구조를 다루는 오버헤드는 개발 속도를 늦추고 클라이언트 작성자가 C2S를 채택하는 것을 주저하게 만든다. 다른 선택지는 개발자가 더 쉽다고 느껴 흔히 택하는 방식인데, ActivityPub 메시지를 JSON (JSON-LD가 아닌)으로만 처리하는 것이다. ActivityPub 메시지를 단순 JSON으로 취급하면 컨텍스트 정의 같은 JSON-LD 기능을 사용할 수 없게 되어 확장성이 훼손된다. 그 결과 속성 이름 충돌 가능성이 생기고, 구현체가 메시지를 신뢰성 있게 해석하거나 확장하기 어렵다.
성능도 우려 사항이다. C2S 상호작용은 주로 HTTP 기반이며 무상태(stateless)이므로, 잦은 폴링과 데이터 페칭은 WebSocket 기반 프로토콜 같은 상태 유지 대안에 비해 반응성을 떨어뜨리고 지연 시간을 늘릴 수 있다. 이는 특히 실시간 알림과 타임라인 업데이트에서 사용자 경험을 저하시킬 수 있다. 다만 작은 서버에서는 치명적 문제가 아닐 수도 있고 폴링만으로도 충분할 수 있다.
ActivityPub의 클라이언트-서버(C2S) 프로토콜이 가진 잠재력은 여전히 설득력 있으며, 탈중앙화 소셜 네트워킹의 미래에 필수적이다. 이상적인 세계에서 C2S는 진정한 상호운용성을 제공하여, 맞춤형 통합이나 서버별 적응 없이도 클라이언트가 다양한 서버에 매끄럽게 연결되어 동작하게 한다. 이러한 보편성은 사용자가 단일 소프트웨어 생태계에 종속되지 않고 클라이언트와 서버를 독립적으로 선택할 수 있는, 진정으로 연합된 소셜 웹이라는 Fediverse의 원래 비전에 더 가까이 다가가게 한다.
어떤 면에서는 C2S API가 S2S보다 더 중요하다고 느꼈다
@erincandescent - ActivityPub 공동 저자
상호운용성을 넘어, C2S는 클라이언트 개발을 복잡하고 종종 파편화된 서버 측 로직으로부터 분리함으로써 중요한 혁신 잠재력을 연다. 이러한 분리는 개발자가 독점 API를 역공학하거나 재현할 필요 없이 새로운 UI와 상호작용 모델을 실험할 수 있는 환경을 조성한다. 이런 자유는 소셜 소프트웨어 디자인에 대한 창의적 접근을 장려하고, 궁극적으로 사용자에게 더 매력적이고 접근 가능하며 유연한 경험을 제공하게 된다.
C2S를 채택하고 강화하는 일은 Fediverse를 지탱하는 탈중앙화 원칙과 깊이 맞닿아 있다. 단일 서버 API에 대한 의존을 줄임으로써 C2S는 생태계의 회복력과 개방성을 강화한다. 또한 사용자가 진정한 데이터 소유권을 갖고, 소셜 그래프를 잃지 않고 클라이언트나 서버를 바꿀 수 있으며, 벤더 종속에서 자유로워지도록 돕는다. 이러한 특성은 활기차고 다양하며 사용자 중심의 탈중앙화 소셜 네트워크를 유지하는 데 결정적이다.
커뮤니티 주도 FEP가 프로토콜의 공백을 계속 메우고, 선도적인 서버 프로젝트가 C2S 지원을 우선시한다면 낙관할 이유가 있다. C2S는 소셜 웹의 지형을 더 상호운용 가능하고, 혁신적이며, 궁극적으로 전 세계 사용자에게 더 큰 역량을 부여하는 방향으로 바꿀 잠재력을 지닌다.
좋은 소식은 C2S로 소셜 웹 UI를 만드는 것이 가능하다는 점이다. 실험적 Flowz 클라이언트는 이러한 가능성의 일부를 보여 주지만, 할 수 있는 일은 훨씬 더 많다.
확장된 C2S 정의에 포함될 수 있는 기존 FEP는 많이 존재한다. 가장 빠르게 진전을 이루려면, 현재의 독점 API 기반 클라이언트 UI와 유사한 기능을 가진 클라이언트를 개발할 수 있도록, 기존 ActivityPub C2S 정의에 대한 ‘최소한의’ 확장과 수정에 집중해야 한다고 본다. 이러한 필수 FEP 중 일부는 액터의 승인 대기(pending) 팔로워에 대한 클라이언트 접근(fep-4ccd)과 액터 차단(fep-c648)을 지원한다.
답글/대화 컬렉션을 관리하는 여러 제안도 있다(fep-76ea, fep-171b, fep-f228). 확장된 C2S API는 답글 탐색(및 대화 백필링)을 효과적이고 효율적으로 구현하기 위해 이 중 하나를 선택하거나 유사한 무언가를 개발해야 한다.
또한 C2S Announce 동작(S2S Announce와 매우 유사)을 규정하고, 사용자 관리 컬렉션 참조(액터 문서에서 “follow your nose” 방식으로 링크를 따라갈 수 있도록)를 정의하는 추가 FEP가 필요하다. (현재 W3C 위키에 기술된) 미디어 업로드 같은 기능도 새로운 FEP의 좋은 후보가 될 것이다.
ActivityPub C2S의 ‘닭과 달걀’ 인과 순환을 깨는 데 있어 어려움 중 하나는, C2S 클라이언트 개발자가 단기간에 잠재 사용자에게 접근할 방법이 필요하다는 점이다.
ActivityPub 클라이언트-서버(C2S) API를 Mastodon 클라이언트 API로 매핑하는 어댑터를 만들면, ActivityPub 네이티브 클라이언트를 Mastodon 기반 서버와 통합하기 위한 중간 해법을 제공할 수 있다. 서버 구현이 ActivityPub C2S를 직접 지원하기를 기다리기보다(이는 복잡하고 장기적일 수 있다), 이 어댑터는 개발자가 표준 ActivityPub C2S 인터페이스를 대상으로 개발하면서도 기존 Mastodon 호환 서버와 상호운용할 수 있게 해준다. 어댑터는 표준 ActivityPub 클라이언트 요청을 동등한 Mastodon 클라이언트 API 호출로 번역하여, 새로 떠오르는 C2S 생태계와 지배적인 Mastodon 호환 인프라 사이의 다리 역할을 한다.
이 어댑터는 ActivityPub C2S 클라이언트와 Mastodon(또는 Mastodon 준수) 서버 사이에 위치하는 독립형 프록시 서비스로 배포될 수 있다. 클라이언트는 Create 활동을 게시하거나 Follow 요청을 보내거나 객체를 가져오는 등 순수하게 ActivityPub로만 통신하고, 어댑터는 대응하는 Mastodon API 엔드포인트를 호출하는 데 필요한 번역과 상태 추적을 모두 처리한다. 어댑터는 ActivityPub과 Mastodon 사이의 식별자(identifier)도 매핑하며, 가능하다면 기존 Mastodon URI를 우선적으로 사용한다. 어댑터가 Mastodon 특화 로직을 캡슐화하므로, 클라이언트는 Mastodon 구현 상세와 깔끔하게 분리된 상태를 유지할 수 있고, 어떤 C2S 준수 시스템에서도 재사용이 가능해진다.
이 접근의 핵심 이점은 기존 Mastodon 서버에 수정이 전혀 필요 없다는 점이다. 이는 호환성을 보존하고 실험 진입 장벽을 낮춰, 서버 생태계가 점진적으로 진화하는 동안에도 개발자가 오늘 당장 C2S 우선(C2S-first) 클라이언트를 만들 수 있게 해준다. 또한 어댑터는 Mastodon 자체뿐 아니라 Mastodon 호환 API를 구현한 다른 서버도 지원할 수 있어, 더 넓은 호환성 계층을 제공할 수 있다.
이상적으로는 이 어댑터가 임시적이어야 하며, 서버 구현에서 ActivityPub C2S 네이티브 지원이 보편화될 때까지만 사용되어야 한다. 그러나 전환기 동안에는 중요한 전략적 역할을 한다. 즉, 클라이언트 개발자가 상호운용성을 포기하지 않으면서도 표준 API와 데이터 모델을 조기에 채택하도록 해준다. 또한 오늘날의 Fediverse 인프라와 호환성을 유지하면서도, Mastodon API의 제약에 갇히지 않는 더 풍부하고 표현력 있는 클라이언트 상호작용으로 진화할 공간을 만든다.
ActivityPub의 클라이언트-서버 프로토콜을 독점 API에 대한 실질적이고 경쟁력 있는 대안으로 만들기 위해서는, 조율된 다면적 노력이 필수적이다. 이 로드맵은 Fediverse 생태계에서 C2S의 더 넓은 채택과 성숙을 추진하기 위한 핵심 단계와 우선순위를 개괄한다.
핵심 FEP의 완성 및 안정화
C2S 채택의 토대는 중요한 Fediverse Enhancement Proposals(FEP)의 작성, 완성, 안정화에 있다. 이러한 커뮤니티 주도 확장은 현재 사양의 의미 있는 공백을 메워야 한다. 기존 및 신규 C2S FEP를 우선순위로 두어 안정적인 드래프트 상태(가능하면 최종 상태)에 이르게 하면, 서버·클라이언트 구현자 모두에게 명확하고 상호운용 가능한 지침이 제공되어 파편화와 불확실성이 줄어든다.
AP C2S-to-Mastodon API 어댑터 구축
Mastodon의 지배적 위치와 방대한 기존 사용자 기반을 고려할 때, 중요한 전환 전략은 ActivityPub C2S 프로토콜과 그 확장을 Mastodon의 독점 클라이언트 API로 번역하는 C2S 어댑터를 개발하는 것이다. C2S 클라이언트를 Mastodon API에 연결함으로써, 이 접근은 단기간에 대규모 사용자 기반에 즉시 접근할 수 있게 하여 C2S 클라이언트가 가까운 시일 내에 성장할 수 있게 한다.
서버 개발자와의 협업
성공적인 C2S 생태계에는 핵심 프로토콜과 확장을 완전히 지원하는 서버 구현이 필요하다. 이미 C2S를 구현했거나 구현할 계획이 있는 서버 프로젝트, 특히 Vocata, rdf-pub, ActivityPods 같은 도메인 독립적 ActivityPub 서버들과의 적극적 협업이 중요하다. 이 개발자들과 함께 적합성(conformance) 및 상호운용성 테스트를 보장하면 C2S 클라이언트를 위한 견고하고 신뢰할 수 있는 서버 측 기반을 마련하는 데 도움이 된다. 이러한 참여는 채택 초기 단계에서 실용적 문제와 개선 기회를 조기에 드러내기도 한다.
activitypub-testsuite 같은 테스트 스위트는 개발자가 확장된 C2S 사양을 준수하는지 확인하는 데 활용할 수 있다.
다양한 클라이언트 개발 장려
C2S가 탄력을 받으려면, 다양한 소셜/애플리케이션 도메인을 겨냥한 풍부한 클라이언트 생태계가 등장해야 한다. 마이크로블로깅, 미디어 공유, 이벤트 관리, 또는 다른 Fediverse 활용 사례에 초점을 둔 C2S 네이티브 클라이언트 개발을 장려하면 프로토콜의 범용성과 사용자 경험 잠재력을 보여줄 수 있다. 이러한 다양성은 혁신을 촉진하고, 현실 세계의 사용성 및 확장 필요에 대한 가치 있는 피드백을 제공하여 사양을 더 정교하게 만든다.
재사용 가능한 ActivityPub 컴포넌트 라이브러리를 개발하는 것도 클라이언트 개발을 지원할 기회다. ap-components는 이러한 가능성 일부를 보여주는 초기 프로젝트다.
이러한 전략적 단계들은 함께 C2S의 광범위한 채택을 향한 실용적이고 점진적인 경로를 이룬다. 프로토콜 확장을 안정화하고, 견고한 서버 기반을 구축하며, 다양한 클라이언트 혁신을 촉진하고, 기존 서버 생태계를 연결함으로써, Fediverse 커뮤니티는 진정으로 상호운용 가능하고 확장 가능하며 사용자 중심인 클라이언트-서버 프로토콜의 약속을 실현할 수 있다. 이 로드맵은 현재의 기술적·생태계적 과제를 해결할 뿐 아니라, 탈중앙화 소셜 웹의 미래를 위한 지속 가능한 표준으로서 C2S를 자리매김시킨다.
Flowz는 ActivityPub 클라이언트-서버(C2S) 프로토콜을 위한 실험적 클라이언트로, 프로토콜의 실용적 실현 가능성을 보여주고 미래 개선을 탐색하기 위한 유연한 기반을 제공하기 위해 만들어졌다. 아키텍처는 의도적으로 모듈식이며 표준 준수에 강하게 초점을 맞춰, 핵심 C2S 사양을 구현한 어떤 서버와도 상호작용할 수 있게 설계되었다. 여기에는 마이크로블로깅, 미디어 공유, 이벤트/회의 조정 등 다양한 소셜 애플리케이션을 지원하는 서버가 포함된다. 현재 Flowz UI는 주로 마이크로블로깅에 초점을 맞추지만, 독점 서버 API에 의존하는 대신 일반적인 C2S 호환성에 기반하므로 다른 유형의 애플리케이션으로도 확장할 수 있다.
대략적인 Flowz 프로토타입을 빠르게 볼 수 있는 데모 영상은 아래를 참고하라.
Flowz의 동기는 실용적 필요에서 출발했다. ActivityPub 서버를 만든 뒤, 그것을 Fediverse에서 일상적으로 사용(daily driver)하고 싶었다. 그러려면 사용자 인터페이스가 필요했다. 보통의 선택지—서버 전용 클라이언트와 API를 만들거나, Mastodon 호환 앱을 쓰기 위해 Mastodon 클라이언트 API를 구현하는 것—은 제한적으로 느껴졌다. 그래서 C2S 프로토콜에 기반해 만들기로 했다. 표준 C2S 기능 세트는 비교적 최소하지만, 이를 확장하는 일은 가능해 보였고, 내 서버뿐 아니라 더 넓은 AP 생태계에도 폭넓게 이로울 수 있다고 판단했다.
Flowz의 핵심 목표는 유연성과 우아한 성능 저하(graceful degradation)다. 최소 핵심 C2S 기능만 지원하는 서버에 연결하더라도 클라이언트는 여전히 합리적인 사용자 경험을 제공한다. 사용자는 타임라인을 읽고 업데이트를 게시하는 같은 필수 동작을 수행할 수 있다. 하지만 Flowz가 진가를 발휘하는 순간은 확장된 C2S 기능을 제공하는 서버에 연결될 때다. 여기에는 커뮤니티 주도 FEP 구현이나 баз 프로토콜을 넘어선 기타 확장이 포함될 수 있다. 이런 경우 Flowz는 현재의 Mastodon 기반 클라이언트가 제공하는 수준에 맞먹거나 그 이상인 기능 풍부한 경험을 제공할 수 있다. 더 풍부한 미디어 표현, 커스터마이즈 가능한 피드, 그리고 (단지 Follow 관계뿐 아니라) 일반적인 액터 관계 관리 같은 미래 기능까지 지원할 수 있다. 이러한 유연성은 탈중앙화 소셜 웹에서 강력하고 사용자 중심인 애플리케이션을 가능케 하는 C2S 모델의 장기적 약속을 보여준다.
아직 알파 단계이며 공개 배포되지는 않았지만, Flowz는 이미 점점 늘어나는 기능들을 지원하고 있고 더 많은 기능이 계획되어 있다. 포함되는 기능은 다음과 같다:
타임라인
게시물 편집 (리치 텍스트 에디터, TBD)
게시물 렌더링
Place에 대한 지도 렌더링(Leaflet 사용)게시물 상호작용
액터 프로필
액터 상호작용
검색 (URI 기반 및 단순 확장 검색)
북마크 컬렉션
커스텀 컬렉션 (계획)
알림
우아한 성능 저하(Graceful Degradation)
인증과 인가 또한 유연성을 염두에 두고 다뤄지고 있다. ActivityPub은 단일 표준 접근을 요구하지 않지만, Flowz는 여러 플러그형 인증/인가 전략을 지원하도록 설계되어 다양한 서버 환경과 사용 사례에 적응할 수 있다.
확장된 C2S 프로토콜의 유연성을 탐색하기 위해, 온라인 마켓플레이스, 작업(할 일) 관리, 혹은 단순 온라인 게임 같은 사용 사례에 초점을 맞춘 다른 UI가 개발될 수도 있다(가능한 예시 중 일부). Flowz 개발 과정에서, 다른 특화 UI에서 재사용하기 쉽도록 일반 목적의 C2S 관련 기능을 추출할 기회도 찾을 예정이다.
요컨대 Flowz는 동작하는 클라이언트이자 연구 플랫폼이다. 아직 초기 진행 중인 작업이지만, 실제 환경에서의 테스트를 통해 C2S의 진화를 촉진하고, 확장 FEP를 다듬는 데 도움을 주며, 클라이언트와 서버가 사용자를 폐쇄 생태계에 가두지 않고 함께 성장할 수 있는, 개방적이고 확장 가능하며 상호운용 가능한 표준 위의 Fediverse라는 비전을 장려하길 기대한다.
오랫동안 주변부로 밀려났던 ActivityPub의 C2S 프로토콜은 클라이언트 다양성과 상호운용성을 되찾는 열쇠를 쥐고 있다. 목표가 분명한 FEP와 Flowz 같은 선도적 구현을 통해, Fediverse는 독점 클라이언트 API와 거대한 단일 클라이언트/서버 구현에서 벗어나 소셜 웹 혁신의 새로운 물결을 가능케 할 수 있다.