ActivityPub

1.1 소셜 웹 워킹 그룹

2.1 사양 프로필

이 명세서는 긴밀하게 연관되고 상호작용하는 두 개의 프로토콜을 정의합니다:

클라이언트-서버 프로토콜 또는 "Social API"

이 프로토콜은 클라이언트가 사용자 대신 동작할 수 있도록 허용합니다. 예를 들어, 이 프로토콜은 모바일 앱이 사용자의 액터 소셜 스트림과 상호작용하는 데 사용됩니다.

서버-서버 프로토콜 또는 "연합 프로토콜"

이 프로토콜은 서로 다른 서버의 액터 간에 활동을 배포하여 동일한 소셜 그래프에 묶을 수 있도록 사용됩니다.

ActivityPub 명세는 이 두 프로토콜 중 하나라도 구현하면 다른 하나를 지원하는 데 추가 비용이 거의 없도록 설계됐습니다. 그러나 서버는 여전히 둘 중 하나만 구현할 수도 있습니다. 이로 인해 아래 세 가지 적합성 클래스가 생깁니다:

ActivityPub 적합 클라이언트

이는 클라이언트-서버 프로토콜의 클라이언트 부분 전체를 구현한 케이스에 적용됩니다.

ActivityPub 적합 서버

이는 클라이언트-서버 프로토콜의 서버 부분 전체를 구현한 케이스에 적용됩니다.

ActivityPub 적합 연합 서버

이는 연합 프로토콜 전체를 구현한 케이스에 해당합니다.

명세의 특정 부분이 연합 프로토콜 구현에만 적용될 때는 이를 명확히 표시합니다. 또한, 어떤 요구사항이 명시될 때는 그것이 클라이언트(클라이언트-서버 프로토콜), 서버(클라이언트-서버 프로토콜), 혹은 서버-서버 프로토콜의 송신/수신 서버에 적용되는지 분명히 나타냅니다.

3.1 객체 식별자(Object Identifiers)

[ActivityStreams]의 모든 객체는 전역적으로 고유한 식별자를 가져야 합니다. ActivityPub에서는 이 요구를 확장하여, ActivityPub 프로토콜을 통해 배포되는 모든 객체는 반드시 고유한 전역 식별자를 가져야 하며, 의도적으로 일시적인 객체(예: 조회 불가능한 단명 채팅 메시지나 게임 알림 등)가 아니라면 반드시 필요한 조건입니다. 이런 식별자는 아래 둘 중 하나여야 합니다:

1. 출처 서버 권한(authority)을 갖는 HTTPS URI 등 공개 dereferencing이 가능한 URI. (공개 콘텐츠는 권장적으로 HTTPS URI 사용)
2. JSON null 객체로 명시적으로 지정된 ID. 이는 익명 객체(상위 컨텍스트의 일부임을 의미).

서버-서버 통신으로 게시되는 액티비티에는, 그 활동이 명시적으로 일시적이 아닌 한 반드시 식별자를 제공해야 합니다. 하지만 클라이언트-서버 통신의 경우, outbox로 게시된 객체에 id가 지정되지 않았을 때 서버는 해당 액터의 네임스페이스에 객체 ID를 할당해 게시 객체에 붙여줘야 합니다(권장).

모든 객체에는 다음 속성이 있습니다:

id

객체의 전역 고유 식별자(객체가 일시적이면 id는 생략 가능).

type

객체의 타입.

3.2 객체 검색

HTTP GET 메소드는 객체의 id 속성에 대해 dereference될 수 있으며, 이를 통해 액티비티를 조회할 수 있습니다. 서버는 [RFC7231]에 정의된 HTTP 콘텐츠 협상을 선택적으로 사용할 수 있지만, application/ld+json; profile="https://www.w3.org/ns/activitystreams" 미디어 타입으로 요청받을 경우 반드시 ActivityStreams 객체 표현(리턴값)을 제공해야 하고, 또한 가능하다면 application/activity+json에도 ActivityStreams 표현을 제공해야 합니다. 클라이언트는 액티비티를 조회하려면 Accept 헤더를 application/ld+json; profile="https://www.w3.org/ns/activitystreams" 미디어 타입으로 반드시 지정해야 합니다.

서버는 위 요구를 충족하지 않는 요청에 대해 다른 동작을 구현할 수 있습니다. (예: 추가적인 기존 프로토콜 지원, 하나의 URI로 HTML과 ActivityStreams 포맷 모두 제공 등)

서버는 B.1 인증 및 권한 부여에서 규정한 대로 권한 인증을 요구할 수 있으며, 추가적인 권한 정책을 자체적으로 둘 수도 있습니다. 서버는 권한 검증에 실패한 요청을 적절한 HTTP 오류 코드나, 객체 존재 자체를 비공개로 하고 싶으면 403 Forbidden 오류 코드로 실패 처리해야 합니다. 비공개 객체 존재 유무 자체도 노출하고 싶지 않으면, 원 서버는 404 Not Found 상태코드로 응답할 수도 있습니다.

3.3 source 속성

[Activity-Vocabulary]가 정의한 모든 속성 외에도, ActivityPub은 Object에 source 속성을 추가로 제공합니다. source 속성은 content 마크업이 어디서 파생되었는지, 즉 원본 정보나 향후 클라이언트 수정 시 활용할 수 있도록 표시합니다. 일반적으로 source에서 content로의 변환은 클라이언트가 담당하며(그 반대는 아님), source의 형식을 직접 지원할 수 있는지는 클라이언트에 따라 다릅니다.

source 값은 content와 mediaType 필드를 갖는 별도의 객체로, 원본 정보를 담습니다.

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "en"}],
  "type": "Note",
  "id": "http://postparty.example/p/2415",
  "content": "<p>나는 <em>딸기를</em> 정말 좋아한다!</p>",
  "source": {
    "content": "나는 *정말* 딸기를 좋아한다!",
    "mediaType": "text/markdown"}
}

4.1 액터 객체

액터 객체는 3.1 Object 식별자에서 요구하는 속성 이외에, 아래 속성들을 반드시 포함해야 합니다:

inbox

이 액터가 받은 모든 메시지들이 포함된 [ActivityStreams] OrderedCollection에 대한 참조입니다. 자세한 내용은 5.2 Inbox를 참조하세요.

outbox

이 액터가 생성한 모든 메시지들이 포함된 [ActivityStreams] OrderedCollection입니다. 5.1 Outbox를 참고하세요.

구현에서는 아래 속성도 권장적으로 제공해야 합니다:

following

이 액터가 팔로우하는 액터들의 [ActivityStreams] 컬렉션 링크입니다. 5.4 Following Collection 참고.

followers

이 액터를 팔로우하는 액터들의 [ActivityStreams] 컬렉션 링크입니다. 5.3 Followers Collection 참고.

구현에서는 아래 속성도 선택적으로 제공할 수 있습니다:

liked

이 액터가 '좋아요' 누른 오브젝트들의 [ActivityStreams] 컬렉션 링크입니다. 5.5 Liked Collection 참고.

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "ja"}],
  "type": "Person",
  "id": "https://kenzoishii.example.com/",
  "following": "https://kenzoishii.example.com/following.json",
  "followers": "https://kenzoishii.example.com/followers.json",
  "liked": "https://kenzoishii.example.com/liked.json",
  "inbox": "https://kenzoishii.example.com/inbox.json",
  "outbox": "https://kenzoishii.example.com/feed.json",
  "preferredUsername": "kenzoishii",
  "name": "石井健蔵",
  "summary": "この方はただの例です",
  "icon": [
    "https://kenzoishii.example.com/image/165987aklre4"
  ]
}

구현에서는 아래 속성도 선택적으로 추가할 수 있습니다:

streams

참고로 쓸 수 있는 추가 컬렉션의 목록입니다.

preferredUsername

액터를 지칭할 때 쓸 수 있는 짧은 사용자명(고유성은 보장되지 않음).

endpoints

추가적인(주로 서버/도메인 전체에 해당) 엔드포인트를 매핑한 JSON 오브젝트입니다. 액터 자신이나 이 액터를 참조하는 사람이 활용할 수 있습니다. 이 매핑은 액터 문서 안에 값으로 포함될 수도 있고, 이런 속성을 가진 JSON-LD 문서 링크일 수도 있습니다.

endpoints 매핑에는 아래 속성을 선택적으로 포함할 수 있습니다:

proxyUrl

이 액터의 클라이언트가 인증이 필요한 원격 ActivityStreams 오브젝트에 접근할 수 있도록 하는 엔드포인트 URI. 이 엔드포인트를 사용하려면, 클라이언트는 x-www-form-urlencoded의 id 파라미터에 요청 오브젝트의 id를 넣어 POST합니다.

oauthAuthorizationEndpoint

만약 OAuth 2.0 베어러 토큰 [RFC6749] [RFC6750]이 클라이언트-서버 상호작용 인증에 사용된다면, 이 엔드포인트는 웹 브라우저 사용자 인증을 통한 새로운 권한 부여 획득용 URI입니다.

oauthTokenEndpoint

만약 OAuth 2.0 베어러 토큰 [RFC6749] [RFC6750]이 클라이언트-서버 상호작용 인증에 사용된다면, 이 엔드포인트는 클라이언트가 엑세스 토큰을 획득하는 URI입니다.

provideClientKey

Linked Data Signatures 및 HTTP Signatures가 인증/권한부여에 사용될 경우, 브라우저 사용자가 클라이언트-서버 상호작용 에 쓰일 클라이언트 공개키를 승인하는 URI입니다.

signClientKey

Linked Data Signatures 및 HTTP Signatures가 인증/권한부여에 사용될 경우, 클라이언트 키를 액터의 키로 일정 시간동안 서명하여 외부 서버에서 액터를 대신해 동작할 수 있도록 하는 URI입니다.

sharedInbox

공개로 주소지정된 활동 및 팔로워에게 보낼 활동을 효율적으로 전달할 때 사용하는 선택적 엔드포인트입니다. 자세한 내용은 Shared Inbox Delivery를 참고하세요. sharedInbox 엔드포인트는 권장적으로 Public 특수 컬렉션에 주소지정된 오브젝트들이 담긴 공개 OrderedCollection 오브젝트여야 합니다. sharedInbox를 읽을 때 절대 Public이 아닌 오브젝트는 표시하지 않아야 합니다.

5.1 Outbox

outbox는 액터의 outbox 프로필 속성에서 찾을 수 있습니다. outbox는 반드시 OrderedCollection이어야 합니다.

outbox 스트림에는 사용자가 발행한 액티비티가 들어 있는데, 실제로 액티비티를 볼 수 있는지 여부는 요청자의 권한에 따라 달라집니다(즉, 읽는 사람의 권한에 따라 outbox 내용이 필터링됨). 만약 Authorization 없이 요청한다면, 서버는 Public으로 주소지정된 게시물만 응답해야 합니다. 실제로는 서버마다 사용자가 볼 수 있는 아이템 수를 제한하거나 다르게 구현할 수 있습니다.

outbox는 HTTP POST 요청을 받으며, 동작 방식은 클라이언트-서버 상호작용에서 설명합니다.

5.2 Inbox

inbox는 액터의 inbox 프로필 속성에서 찾을 수 있습니다. inbox도 반드시 OrderedCollection이어야 합니다.

inbox 스트림에는 액터가 받은 모든 액티비티가 들어 있습니다. 서버는 권장적으로 요청자 권한에 따라 내용을 필터링해야 합니다. 일반적으로 inbox 소유자는 자신의 모든 내용을 볼 수 있지만, 접근 제어에 따라 일부는 공개·일부는 권한 인증이 필요할 수 있습니다.

서버는 inbox에 반환하는 액티비티의 중복을 반드시 제거해야 합니다. 예를 들어 액티비티가 한 액터의 팔로워와 특정 팔로워 모두에 보내지는 경우 등, 서버가 반복 수신자 목록을 중복 제거하지 못하면 중복이 발생할 수 있습니다. 이때 id가 같은 액티비티를 걸러내야 합니다.

연합 서버의 액터는 inbox에서 HTTP POST 요청을 받을 수 있으며, 동작 방식은 Delivery에서 설명합니다. 비연합 서버는 권장적으로 POST 요청을 받으면 405(Method Not Allowed)로 응답해야 합니다.

5.3 Followers 컬렉션

모든 액터는 followers 컬렉션을 권장적으로 가져야 합니다. 이는 액터에 대해 Follow 액티비티를 보낸, 즉 팔로우한 주체의 목록으로, 부수 효과로 추가된 항목입니다. 해당 액터를 팔로우하는 모든 액터의 목록을 여기에 찾을 수 있습니다. followers 컬렉션은 반드시 OrderedCollection 또는 Collection 여야 하며, 로그인된 사용자의 권한에 따라, 혹은 인증이 없는 경우 적절하게 필터링 가능합니다.

5.4 Following 컬렉션

모든 액터는 following 컬렉션을 권장적으로 가져야 합니다. 이는 액터가 팔로우한 모든 대상의 목록으로, 부수 효과로 추가된 항목입니다. following 컬렉션은 반드시 OrderedCollection 또는 Collection 여야 하며, 로그인된 사용자의 권한에 따라, 혹은 인증이 없는 경우 적절하게 필터링 가능합니다.

5.5 Liked 컬렉션

모든 액터는 liked 컬렉션을 선택적으로 가질 수 있습니다. 이는 액터의 모든 Like 액티비티가 부수 효과로 추가되어 모인 목록입니다. liked 컬렉션은 반드시 OrderedCollection 또는 Collection 여야 하며, 로그인된 사용자의 권한에 따라, 혹은 인증이 없는 경우 적절하게 필터링 가능합니다.

5.6 공개 주소지정(Public Addressing)

[ActivityStreams] 컬렉션 및 오브젝트 외에도, Activity는 특별한 "public" 컬렉션(https://www.w3.org/ns/activitystreams#Public)에 주소지정할 수도 있습니다. 예시:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://www.w3.org/ns/activitystreams#Public",
  "type": "Collection"
}

이 특별 URI로 주소지정된 Activity는 누구나 인증 없이 접근할 수 있어야 합니다. 구현에서는 "public" 특수 컬렉션으로의 전달을 절대 허용하면 안 됩니다. 해당 컬렉션은 실제 activity를 받는 것이 불가능합니다. 다만, 액터는 sharedInbox 엔드포인트를 두고 공개 글(혹은 팔로워 전용 글)의 효율적 일괄 배포에 이용할 수 있습니다. 자세한 내용은 7.1.3 Shared Inbox Delivery 참고.

5.7 Likes 컬렉션

모든 오브젝트는 likes 컬렉션을 선택적으로 가질 수 있습니다. 이는 이 오브젝트가 object 속성에 명시된 모든 Like 액티비티 목록으로, 부수 효과로 추가됩니다. likes 컬렉션은 반드시 OrderedCollection 또는 Collection 여야 하며, 로그인된 사용자의 권한에 따라, 혹은 인증이 없는 경우 적절하게 필터링 가능합니다.

5.8 Shares 컬렉션

모든 오브젝트는 shares 컬렉션을 선택적으로 가질 수 있습니다. 이는 이 오브젝트를 object 속성으로 한 Announce 액티비티들의 목록이며, 부수 효과로 추가됩니다. shares 컬렉션은 반드시 OrderedCollection 또는 Collection 여야 하며, 로그인된 사용자의 권한에 따라, 혹은 인증이 없는 경우 적절하게 필터링 가능합니다.

6.1 클라이언트 주소지정

클라이언트는 새 Activity에 대해 올바르게 주소지정할 책임이 있습니다. 이는 실제 클라이언트 구현에 어느 정도 의존하지만, 클라이언트는 서버가 to, bto, cc, bcc, audience 필드에 있는 수신자에게만 Activity를 전달함을 인지해야 합니다.

Followers 컬렉션과/또는 Public 컬렉션은 새 Activity의 기본 주소지정 대상으로 적합한 선택입니다.

클라이언트는 새 Activity에 object, target, inReplyTo 및/또는 tag 필드를 통해 첨부된 오브젝트를 검사하고, 그 오브젝트의 actor 또는 attributedTo 속성(들)을 추출해야 하며, 선택적으로 주소지정 속성들도 가져와서, 새 Activity의 to나 cc에도 추가할 수 있습니다. 클라이언트는 첨부 오브젝트를 재귀적으로 따라가도 되지만, 이런 경우 권장적으로 제한을 두어야 합니다. (참고: 이는 클라이언트가 주소지정되는 액터의 컬렉션 전체를 개별 수신자로 '펼치라'는 의미가 아님)

클라이언트는 이 주소지정 값을 UI에서 사용자가 수정할 기회를 제공해도 됩니다.

예를 들어 Chris가 Amy의 아래 게시글(article)에 좋아요를 누르는 경우:

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "en-GB"}],
  "id": "https://rhiaro.co.uk/2016/05/minimal-activitypub",
  "type": "Article",
  "name": "Minimal ActivityPub update client",
  "content": "Today I finished morph, a client for posting ActivityStreams2...",
  "attributedTo": "https://rhiaro.co.uk/#amy",
  "to": "https://rhiaro.co.uk/followers/",
  "cc": "https://e14n.com/evan"
}

클라이언트는 아래와 같이 like를 생성합니다:

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "en"}],
  "type": "Like",
  "actor": "https://dustycloud.org/chris/",
  "summary": "Chris liked 'Minimal ActivityPub update client'",
  "object": "https://rhiaro.co.uk/2016/05/minimal-activitypub",
  "to": ["https://rhiaro.co.uk/#amy",
         "https://dustycloud.org/followers",
         "https://rhiaro.co.uk/followers/"],
  "cc": "https://e14n.com/evan"
}

받는 쪽 outbox는 delivery를 통해 Chris(좋아요 누른 사람)의 팔로워뿐 아니라, Amy와 Amy의 팔로워(Evan 포함)까지 알림을 보냅니다.

다음과 같은 Activity를 outbox에 제출하는 클라이언트는 object 속성을 반드시 Activity에 제공해야 합니다: Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo. 또한 다음 Activity를 outbox에 제출할 때는 target 속성도 반드시 제공해야 합니다: Add, Remove.

6.2 Create Activity

Create Activity는 새 오브젝트 게시에 사용됩니다. Activity 내부(object 속성)에 포함된 오브젝트가 생성된다는 부수 효과가 있습니다.

Create Activity가 게시될 때, 해당 Activity의 actor를 오브젝트의 attributedTo 필드에 반드시 복사해야 합니다.

Create Activity와 그 object의 주소지정이 다르면 혼란이 발생할 수 있으므로, 서버는 초기 배포 시 Create Activity의 수신자를 object에도 복사하고 반대도 권장적으로 복사해야 합니다. 단, 이후 object의 주소지정은 Create의 주소지정을 변경하지 않고 별도로 바뀔 수도 있습니다(예: Update activity로).

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "content": "This is a note",
  "published": "2015-02-10T15:04:55Z",
  "to": ["https://example.org/~john/"],
  "cc": ["https://example.com/~erik/followers",
         "https://www.w3.org/ns/activitystreams#Public"]
}

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "id": "https://example.net/~mallory/87374",
  "actor": "https://example.net/~mallory",
  "object": {
    "id": "https://example.com/~mallory/note/72",
    "type": "Note",
    "attributedTo": "https://example.net/~mallory",
    "content": "This is a note",
    "published": "2015-02-10T15:04:55Z",
    "to": ["https://example.org/~john/"],
    "cc": ["https://example.com/~erik/followers",
           "https://www.w3.org/ns/activitystreams#Public"]
  },
  "published": "2015-02-10T15:04:55Z",
  "to": ["https://example.org/~john/"],
  "cc": ["https://example.com/~erik/followers",
         "https://www.w3.org/ns/activitystreams#Public"]
}

6.3 Update Activity

Update Activity는 기존 오브젝트를 수정할 때 사용됩니다. 이 Activity의 부수 효과로, 액터가 해당 오브젝트에 대한 수정 권한이 있는 경우 object가 Activity에서 정의한 새 구조로 반드시 변경됩니다.

6.4 Delete Activity

Delete Activity는 기존 오브젝트를 삭제할 때 사용됩니다. 이 Activity의 부수 효과로, 서버는 object를 Tombstone 타입으로 대체해 삭제된 오브젝트를 참조하는 Activity에 표시될 수 있도록 동작할 수 있습니다. 삭제된 오브젝트 요청 시 서버는 Tombstone을 본문으로 반환한다면 410 Gone 상태코드로 답해야 하며, 그렇지 않으면 404 Not Found로 답해야 합니다.

삭제된 오브젝트 예시:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://example.com/~alice/note/72",
  "type": "Tombstone",
  "published": "2015-02-10T15:04:55Z",
  "updated": "2015-02-10T15:04:55Z",
  "deleted": "2015-02-10T15:04:55Z"
}

6.5 Follow Activity

Follow Activity는 다른 액터의 활동을 구독하는 데 사용됩니다.

outbox에서 이 Activity를 수신할 경우, 서버는 이후 Accept Activity가 이 Follow Activity를 object로 포함해 도착할 때에만, object를 actor의 following 컬렉션에 추가해야 합니다.

6.6 Add Activity

outbox로 Add Activity를 수신 시, 서버는 target 속성의 컬렉션에 object를 추가해야 합니다. 단,

• target이 수신 서버의 소유가 아니라서 서버가 갱신 권한이 없는 경우
• 다른 사유로 해당 object가 target 컬렉션에 추가되면 안 된다고 서버가 판단할 때

6.7 Remove Activity

outbox로 Remove activity를 수신 시, 서버는 target의 컬렉션에서 object를 제거해야 합니다. 단,

• target이 수신 서버 소유가 아니어서 갱신할 권한이 없는 경우
• 다른 사유로 object를 target 컬렉션에서 제거하면 안 된다고 서버가 판단할 때

6.8 Like Activity

Like Activity는 actor가 object를 좋아함을 나타냅니다.

outbox에서 이 Activity를 수신 시, 서버는 object를 actor의 liked 컬렉션에 추가해야 합니다.

6.9 Block Activity

Block Activity는 게시 액터가 object 속성에 지정된 액터가 자신이 게시한 오브젝트와 상호작용하지 못하도록 하고 싶을 때 사용됩니다. 서버는 차단된 사용자가 액터가 게시한 오브젝트와 상호작용하지 못하도록 막아야 합니다.

서버는 Block Activity를 object에게 전달하면 안 됩니다.

6.10 Undo Activity

Undo Activity는 이전 Activity를 취소할 때 사용됩니다. 자세한 내용은 Activity Vocabulary 문서의 역활동 및 "Undo" 항목을 참고하십시오. 예를 들어, Undo는 이전의 Like, Follow, Block을 되돌릴 때 활용할 수 있습니다. undo 및 대상이 되는 활동은 반드시 같은 actor를 가져야 하며, 가능한 한 모든 부수 효과도 취소되어야 합니다. (예: Like를 undo하면 이전에 올린 카운터도 적절히 감소해야 함)

단, 명시적인 역활동(inverse activity)이 따로 존재하는 경우에는 그것을 사용해야 합니다. Create 기반 액티비티는 Delete로, Add는 Remove로 undo해야 합니다.

6.11 전달

연합 서버는 outbox에 게시된 모든 Activity에 대해 outbox 전달을 반드시 수행해야 합니다.

7.1 전달

아래 내용은 오직 연합(federated) 서버 간 통신에 필수입니다.

Activity는 우선 타겟(즉, 액터)의 inbox를 찾고 그 inbox에 Activity를 POST하여 전달됩니다. 전달 대상은 ActivityStreams audience targeting의 규정에 따라, Activity의 to, bto, cc, bcc, audience 필드를 확인해 결정합니다.

inbox는 먼저 대상 액터의 JSON-LD 표현을 조회한 뒤, inbox 속성을 찾아 결정합니다. 수신자가 Collection 또는 OrderedCollection이라면, 서버는 반드시(사용자 인증 정보로) 컬렉션을 dereference해서, 컬렉션 내 각 항목의 inbox를 알아내야 합니다. 서버는 반드시 컬렉션을 통한 연쇄 dereference의 깊이에 제한을 두어야 하며, 보통 1단계만 허용할 수 있습니다.

서버는 최종 타겟 수신자 목록을 반드시 deduplicate(중복 제거)해야 합니다. 또한 Activity의 actor와 동일한 액터는 목록에서 반드시 제외합니다. 즉, 액터 본인이 본인의 Activity를 스스로 수신해서는 안 됩니다.

이후 inbox에(Submit 한 사용자 권한으로) HTTP POST 요청을 하며, 요청 본문에 Activity를 담습니다. Activity는 수신자의 inbox OrderedCollection에 item으로 추가됩니다. 비연합 서버의 inbox로 전달을 시도한 경우 권장적으로 405 Method Not Allowed 응답을 받아야 합니다.

제3의 서버로 전달하는 연합 서버의 경우, 전달은 비동기로 수행해야 하며, 네트워크 오류로 인해 실패한다면 재시도 또한 수행해야 합니다.

참고: 동일 오리진 내 액터 간 Activity 유통에는 내부 메커니즘을 사용할 수 있으며 반드시 HTTP를 쓸 필요는 없습니다.

7.2 Create Activity

inbox로 Create Activity를 수신해도 추가 부수 효과는 거의 없습니다; Activity는 액터의 inbox에 표시되고, 서버는 이 Activity와 딸린 오브젝트의 내부 표현을 저장할 수 있습니다. 그러나 이는 원래 inbox로 전달되는 activity 처리 과정에서 항상 발생하는 현상입니다.

7.3 Update Activity

서버-서버 상호작용에서, Update Activity는 수신 서버가 동일 id를 가진 자체 object의 사본을 Activity에 첨부된 사본으로 업데이트해야 함을 뜻합니다. 클라이언트-서버 Update activity 처리와 달리, 전체 오브젝트를 완전히 덮어쓰는 전체 갱신 방식입니다.

수신 서버는 반드시 Update가 해당 object를 변경할 권한이 있는지 확인해야 합니다. 최소한, Update와 그 object가 같은 오리진인지를 점검해야 합니다.

7.4 Delete Activity

이를 inbox로 수신하면(단, object가 송신 액터/서버 소유라는 전제 하에) 수신 서버는 동일 id의 object 내부 표현을 삭제 (및 Tombstone 오브젝트로 대체)해야 합니다.

(참고로, 오리진 서버에서 원격 서버로 activity를 전달한 뒤에는, ActivityPub 프로토콜에 원격 서버 오브젝트 표현의 삭제를 강제할 수 있는 장치는 없습니다.)

7.5 Follow Activity

이를 inbox로 수신하면, 서버는 권장적으로 Follow를 object로 가진 Accept 또는 Reject activity를 생성해 해당 Follow의 actor에게 전달해야 합니다. Accept 또는 Reject는 자동으로 생성할 수도 있고, 사용자 입력(예: 검토 후 응답 등) 결과로 생성할 수도 있습니다. 서버가 Reject를 명시적으로 보내지 않도록 할 수도 있지만, 이 경우 요청을 보낸 쪽 서버가 중간 상태에 남을 수 있음을 인지해야 합니다. 예를 들어, 사용자의 프라이버시 보호 위해 Reject를 보내지 않을 수도 있습니다.

Accept가 도착하고 그 object가 이전에 수신자가 보낸 Follow Activity일 경우, 서버는 권장적으로 actor를 수신자의 Followers Collection에 추가해야 합니다. Reject의 경우, 서버는 절대 actor를 수신자의 Followers Collection에 추가하면 안 됩니다.

7.6 Accept Activity

이를 inbox에서 수신할 때의 부수 효과는 수신한 object 타입에 따라 다르며, 문서에 정의되지 않은 타입(예: Offer 등)도 수락할 수 있습니다.

inbox로 도착한 Accept의 object가 이전에 수신자가 보낸 Follow activity라면, 서버는 권장적으로 actor를 수신자의 Following Collection에 추가해야 합니다.

7.7 Reject Activity

이를 inbox에서 수신할 때의 부수 효과는 수신한 object 타입에 따라 다르며, 문서에 정의되지 않은 타입(예: Offer 등)도 거절할 수 있습니다.

inbox로 수신된 Reject의 object가 수신자가 이전에 보낸 Follow activity라면, 이는 수신자가 Follow 요청을 승인하지 않았음을 의미합니다. 서버는 절대 actor를 수신자의 Following Collection에 추가하면 안 됩니다.

7.8 Add Activity

inbox로 Add Activity를 수신하면, 서버는 target 속성의 컬렉션에 object를 추가해야 합니다 (단,

• target이 수신 서버 소유가 아니어서 갱신할 권한이 없는 경우
• 수신 서버 정책상 다른 사유로 object가 target 컬렉션에 추가되면 안 되는 경우

7.9 Remove Activity

inbox로 Remove Activity를 수신하면, 서버는 target 속성의 컬렉션에서 object를 제거해야 합니다 (단,

• target이 수신 서버 소유가 아니어서 갱신할 권한이 없는 경우
• 수신 서버 정책상 object가 target 컬렉션에서 제거되면 안 되는 경우

7.10 Like Activity

inbox로 이 Activity를 수신하면, 서버는 해당 오브젝트의 like 개수를 증가시키고, 받은 Activity를 likes 컬렉션에(존재한다면) 추가해야 합니다.

7.11 Announce Activity (공유)

inbox로 Announce Activity를 수신하면, 서버는 해당 오브젝트의 공유 개수를 증가시키고, 받은 Activity를 shares 컬렉션에(존재한다면) 추가해야 합니다.

7.12 Undo Activity

Undo Activity는 이전 Activity의 부수 효과를 되돌릴 때 사용합니다. ActivityStreams 문서의 역활동 및 "Undo"를 참고하세요. Undo Activity의 범위와 제한은 클라이언트-서버 상호작용 맥락의 Undo activity와 동일하며, 그 적용 대상이 연합 환경임을 제외하고 동일합니다.