W3C ActivityPub 1. Overview
1장 Overview의 핵심은 간단합니다. 사용자는 앱으로 자기 서버에 글을 보내고, 서버끼리는 그 활동을 상대방의 받은 편지함으로 전달합니다.
공식 문서 열기1. Overview 데모
ActivityPub는 “계정 프로필에서 inbox/outbox 주소를 찾고, Activity 객체를 그 주소로 주고받는 방식”입니다.
Client to Server앱이 내 outbox에 글을 보냅니다.
Server to Server내 서버가 상대 inbox로 전달합니다.
Actor각 계정은 inbox와 outbox 주소를 가진 JSON 프로필입니다.
1. Overview 한국어 번역
원문 전체를 장문으로 그대로 복제하지 않고, 문단 순서와 예시 흐름을 보존해 학습용 한국어로 옮겼습니다. 구현할 때는 반드시 원문 규격의 MUST/SHOULD 문장을 다시 확인하세요.
ActivityPub에는 두 층이 있습니다. 하나는 분산된 웹사이트들이 서로 정보를 나눌 수 있게 하는 서버 대 서버 연합 프로토콜이고, 다른 하나는 사용자가 휴대폰, 데스크톱 앱, 웹 앱 같은 클라이언트를 통해 자기 서버의 계정으로 활동할 수 있게 하는 클라이언트 대 서버 프로토콜입니다.
구현체는 둘 중 하나만 지원할 수도 있고 둘 다 지원할 수도 있습니다. 어느 한쪽을 만들고 나면 다른 쪽을 붙이는 일이 아주 멀지는 않으며, 둘을 함께 지원하면 사이트가 분산형 소셜 웹의 일부가 되고 여러 서비스에서 동작하는 클라이언트와 라이브러리를 활용할 수 있습니다.
ActivityPub에서 사용자는 서버의 계정을 통해 Actor로 표현됩니다. 같은 사람이 여러 서버에 계정을 가지고 있으면 각각은 별도의 Actor입니다.
모든 Actor는 세상에서 메시지를 받는 inbox와, 다른 사람에게 메시지를 보내는 outbox를 가집니다.
inbox와 outbox는 특별한 마법이 아니라 Actor의 ActivityStreams 설명 문서 안에 들어 있는 URL입니다.
예를 들어 어떤 Actor 문서를 가져오면 그 JSON 안에서 프로필 이름, 사용자 이름, 팔로워 목록, 받은 편지함, 보낸 편지함 주소를 확인할 수 있습니다.
ActivityPub는 ActivityStreams 어휘를 사용합니다. ActivityStreams에는 소셜 네트워크에서 필요한 활동과 콘텐츠를 표현하는 공통 단어가 이미 들어 있습니다. 더 필요한 것이 있으면 JSON-LD로 확장할 수 있지만, 확장을 하지 않는다면 보통의 JSON 문서처럼 읽어도 충분히 이해할 수 있습니다.
메시지 흐름은 이렇게 생각하면 쉽습니다. 사용자가 친구에게 보낼 Note를 작성하면 클라이언트는 그 Note를 자기 Actor의 outbox로 보냅니다.
서버는 이 객체가 Activity가 아니라 새로 만들어진 객체라는 것을 보고, 필요하면 Create Activity로 감싸서 “누가 무엇을 만들었다”는 형태로 정리합니다.
그런 다음 보내는 서버는 받는 사람의 Actor 문서를 조회해 상대 Actor의 inbox 주소를 찾고, 그 inbox로 Activity를 POST합니다.
그래서 사용자가 보기에는 “내 outbox에서 상대 inbox로 메시지가 흘러간다”고 이해할 수 있습니다. 실제로는 클라이언트 대 서버 단계와 서버 대 서버 연합 단계가 나뉘어 있습니다.
나중에 사용자는 자기 앱으로 inbox를 GET해서 새로 받은 활동을 읽습니다. 또 어떤 Activity는 이미 Activity 형태이기 때문에 서버가 다시 Create로 감싸지 않습니다.
예를 들어 좋아요는 Like Activity 그대로 outbox에 제출됩니다.
공개 글을 만들 때는 수신자에 팔로워 컬렉션과 ActivityStreams의 Public 대상을 함께 넣을 수 있습니다. 이렇게 주소가 지정된 활동은 팔로워에게 전달되고, 공개 대상으로 표시된 내용은 권한 없이도 읽을 수 있는 공개 게시물로 다뤄집니다.
1.1절은 ActivityPub가 Social Web Working Group에서 만든 여러 관련 규격 중 하나라고 설명합니다. 구현자는 필요에 따라 Micropub이나 Social Web Protocols 개요 같은 보완 규격도 함께 살펴볼 수 있습니다.
원문 흐름별 상세 풀어쓰기
첫 문단은 ActivityPub를 하나의 단일 API로 설명하지 않습니다. 서로 다른 웹사이트가 정보를 주고받게 하는
server to server federation과, 사용자의 앱이 자기 계정으로 서버에 요청하게 하는
client to server가 함께 있습니다. 그래서 ActivityPub 구현을 볼 때는 항상 “앱이 서버에 말하는 부분인가,
서버가 다른 서버에 말하는 부분인가”를 먼저 나눠야 합니다.
문서는 구현체가 한 계층만 선택할 수도 있다고 설명합니다. 다만 하나를 구현하면 다른 하나로 이어지는 길이 멀지 않고, 둘을 함께 지원하면 분산형 소셜 웹에 참여하면서 여러 사이트에서 동작하는 클라이언트와 라이브러리를 쓸 수 있습니다. 이 말은 작은 앱은 클라이언트부터, 서버 제품은 연합 기능부터 시작할 수 있다는 뜻이기도 합니다.
ActivityPub에서 네트워크가 직접 다루는 것은 “사람 그 자체”가 아니라 서버 위의 계정입니다. 한 사람이 여러 서버에 계정을 만들면
각 계정은 서로 다른 Actor가 됩니다. Actor에는 메시지를 받는 inbox와 메시지를 내보내는
outbox가 있고, 이 두 URL이 이후 모든 통신의 기준점입니다.
Actor의 inbox와 outbox는 숨은 내부 값이 아니라 Actor 설명 문서 안에 들어 있는 URL입니다.
예시 Actor 문서에는 id, name, preferredUsername,
summary, inbox, outbox, followers,
following, liked가 들어갑니다. 구현자는 이 문서를 “원격 계정 주소록”처럼 읽으면 됩니다.
ActivityPub가 새로 모든 단어를 만들지 않고 ActivityStreams vocabulary를 사용한다는 점이 중요합니다.
Person, Note, Create, Like 같은 타입과 속성은
ActivityStreams 쪽 의미를 따릅니다. 확장이 필요하면 JSON-LD가 도움이 되지만, 기본 예시는 보통 JSON처럼 읽어도 흐름을 이해할 수 있습니다.
Overview는 inbox와 outbox를 단순한 저장소가 아니라 메서드에 따라 의미가 바뀌는 endpoint로 설명합니다. 상대 inbox에 POST하는 것은 서버 대 서버 배달이고, 내 inbox를 GET하는 것은 받은 활동 읽기입니다. 내 outbox에 POST하는 것은 클라이언트가 새 활동을 제출하는 것이고, 누군가의 outbox를 GET하는 것은 그 Actor가 발행한 활동을 보는 것입니다.
Alyssa가 Ben에게 보낼 Note를 작성하는 예시는 ActivityPub의 핵심 패턴을 보여 줍니다.
클라이언트가 outbox에 비-Activity 객체를 올리면 서버는 “이 Actor가 이 Object를 만들었다”는 뜻의
Create Activity로 감쌉니다. 이렇게 해야 서버 간 배달에서 “누가 무엇에 어떤 행동을 했는가”가 분명해집니다.
Alyssa의 서버는 Ben의 Actor 문서를 조회하고, 그 안에서 Ben의 inbox URL을 찾은 뒤 Create Activity를 POST합니다. 사용자에게는 outbox에서 inbox로 곧장 흘러가는 것처럼 보이지만, 실제로는 클라이언트 대 서버 제출과 서버 대 서버 배달이라는 두 단계가 이어진 결과입니다.
나중에 Alyssa가 inbox를 GET하면 Ben의 답장을 Create Activity로 보게 됩니다. Ben의 Note는 원래 Alyssa 글을
inReplyTo로 가리킵니다. Alyssa가 그 답장을 좋아요할 때는 이미 Like가 Activity이므로
다시 Create로 감싸지 않습니다. 공개 글 예시는 followers 컬렉션과 Public 대상을 함께 써서
배달 대상과 공개 범위를 표현합니다.
Overview 끝의 1.1절은 ActivityPub가 Social Web Working Group의 여러 관련 규격 중 하나라는 점을 알려 줍니다. 구현자가 ActivityPub만으로 해결되지 않는 클라이언트 게시 API나 보완 프로토콜을 검토해야 할 때 Micropub과 Social Web Protocols 개요로 이어질 수 있습니다.
GET/POST 흐름
서버 대 서버 연합 단계입니다. 보내는 서버가 받는 Actor의 inbox를 찾아 Activity를 POST합니다.
클라이언트 앱이 아무 Actor의 inbox에 직접 쓰는 흐름으로 읽으면 안 됩니다.
클라이언트가 내 Actor의 inbox를 조회해 새 메시지, 답장, 알림 같은 활동을 읽습니다.
실제로 어떤 항목이 보이는지는 로그인 사용자와 접근 권한에 따라 달라질 수 있습니다.
클라이언트 대 서버 단계입니다. 앱은 사용자를 대신해 outbox에 Note, Like, Follow 같은 객체나 Activity를 제출하고,
서버는 필요하면 Create로 감싼 뒤 저장과 배달을 시작합니다.
누군가의 outbox를 조회하면 그 Actor가 올린 활동을 볼 수 있습니다.
단, 비공개 항목까지 항상 보인다는 뜻은 아니며 서버는 요청자의 권한에 맞는 항목만 반환해야 합니다.
문단별 대조표
federation, client to server
Client, Server
Actor, inbox, outbox
ActivityStreams, JSON-LD
Note, Create
POST, remote inbox
GET, Like, Public
Micropub, Social Web
원문과 나란히 대조하려면 W3C Overview 원문을 함께 열어 보세요.
Overview는 ActivityPub를 “클라이언트가 내 서버와 말하는 규칙”과 “서버끼리 서로 전달하는 규칙”으로 나눠 설명합니다. 이 구분을 잡고 읽으면 뒤의 6장과 7장이 자연스럽게 이어집니다.
원문은 사람 자체가 아니라 서버 위의 계정을 Actor로 봅니다. 같은 사람이 서버마다 계정을 만들면 각 계정은 서로 다른 Actor가 됩니다. 이 Actor 문서 안에 inbox와 outbox URL이 들어 있습니다.
ActivityStreams와 JSON-LD가 기반이지만, 확장을 깊게 다루지 않는다면 Actor, Note, Create, Like 같은 값은 평범한 JSON 필드처럼 읽어도 됩니다.
다만 구현에서는 @context와 vocabulary 의미를 보존해야 합니다.
사용자가 단순 Note를 outbox에 올리면 서버는 “새 Note를 만들었다”는 뜻의 Create Activity로 감싸 배달할 수 있습니다. 이미 Like 같은 Activity라면 다시 Create로 감싸지 않습니다.
보내는 서버는 받는 사람의 Actor 문서를 가져와 inbox를 찾고, 그 URL로 Activity를 POST합니다. 그래서 학습용으로는 “내 outbox에서 상대 inbox로 흐른다”고 생각하면 충분합니다.
공개 글은 followers 컬렉션과 Public 대상을 함께 주소로 넣을 수 있습니다. followers는 배달 대상이고, Public은 인증 없이 읽을 수 있는 공개 대상이라는 의미입니다.
Overview 예시 따라 읽기
inbox, outbox, followers, following, liked가 들어 있고,
이 주소들이 뒤의 모든 통신을 찾는 출발점이 됩니다.
Create Activity로 감쌉니다. ActivityPub의 기본 문장은 “어떤 Actor가 어떤 Object에 어떤 Activity를 했다”입니다.
여기서는 Alyssa가 Note를 만들었다는 형태가 됩니다.
Create Activity이고, 내부 Note는 원래 Alyssa 글에 대한 inReplyTo 관계를 가집니다.
Like 자체가 Activity이므로 서버가 다시 Create로 감쌀 필요가 없습니다.
이 차이가 비-Activity 객체 제출과 Activity 제출의 차이를 보여 줍니다.
followers는 실제 배달 대상이고, Public은 인증 없이 읽을 수 있는 공개 범위를 뜻합니다.
두 계층
모바일 앱이나 웹 앱이 내 Actor의 outbox에 글쓰기, 좋아요, 팔로우 같은 Activity를 POST합니다.
내 서버가 받는 사람 Actor를 조회하고, 그 Actor의 inbox로 Activity를 보내 연합 소셜 그래프를 만듭니다.
Actor 프로필
예시 Actor JSON
흐름 데모
2~7, A~D 상세 페이지