개념을 먼저 잡기
3. Objects → 4. Actors → 5. Collections 순서로 읽으면 ActivityPub의 데이터 구조가 먼저 잡힙니다. 그 다음 6장과 7장으로 넘어가면 API 흐름이 덜 낯섭니다.
2~7, A~D
개별 상세 페이지
서버를 만든다면
2. Conformance로 범위를 정하고, 4. Actor 프로필과 5. inbox/outbox를 만든 뒤, 6. outbox POST와 7. 연합 배달을 붙이는 순서가 현실적입니다.
놓치기 쉬운 부분
A. Internationalization과 B. Security는 마지막 부록처럼 보이지만 실제 구현 품질에 직접 영향을 줍니다. 특히 HTML 정화, 비공개 수신자, 언어 태그는 초기에 설계해 두는 편이 좋습니다.
2. Conformance
무엇을 구현해야 ActivityPub 호환이라고 말할 수 있는지, Client/Server/Federated Server 범위를 나눕니다.
3. Objects
Note, Activity, Collection을 id와 type이 있는 Object로 읽고 저장, 조회, 검증하는 기준을 잡습니다.
4. Actors
사람, 조직, 앱, 서비스 같은 Actor가 inbox/outbox를 통해 네트워크에서 어떻게 발견되는지 설명합니다.
5. Collections
inbox, outbox, followers, following, liked, likes, shares를 Collection으로 다루는 법을 정리합니다.
6. Client to Server
클라이언트 앱이 사용자를 대신해 outbox에 Activity를 제출하고 서버가 side effect를 만드는 흐름입니다.
7. Server to Server
Activity를 원격 Actor의 inbox/sharedInbox로 배달하고 수신 서버가 검증하는 연합 프로토콜입니다.
A. Internationalization
원격 콘텐츠의 언어 태그와 다국어 값을 잃지 않고 저장하고 표시하는 방법을 다룹니다.
B. Security
원격 JSON 검증, SSRF, HTML 정화, 스팸과 DoS, 비공개 수신자 노출을 막는 체크포인트입니다.
C. Acknowledgements
구현 요구사항은 아니지만 ActivityPub가 열린 웹 표준으로 만들어진 협업 맥락을 보여 줍니다.
D. References
ActivityStreams, JSON-LD, HTTP 등 ActivityPub 의미를 완성하는 참고 문헌을 추적하는 지도입니다.