ActivityPub: 분산 소셜 네트워킹

ActivityPub 프로토콜이 뭐야?

ActivityPub은 분산형 소셜 네트워킹 프로토콜입니다. 이 프로토콜은 다양한 소셜 네트워킹 서비스에서 사용되며, 사용자 간에 컨텐츠를 공유하고 상호 작용할 수 있는 기능을 제공합니다.

ActivityPub은 사용자들이 소셜 네트워킹 서비스를 호스팅할 수 있는 분산된 방식을 촉진합니다. 이 프로토콜을 사용하면 여러 서로 다른 도메인에 있는 사용자들이 서로의 컨텐츠를 구독하고 공유할 수 있습니다. 예를 들어, 한 사용자가 자신이 작성한 게시물을 다른 사용자와 공유하고 다른 사용자의 게시물을 구독할 수 있습니다.

ActivityPub은 활동(activities)을 기반으로 작동합니다. 활동은 사용자들이 서로 상호 작용할 때 생성되는 작업을 나타냅니다. 예를 들어, 게시물 작성, 좋아요 표시, 댓글 작성 등이 활동의 예입니다. 이러한 활동은 JSON 형식으로 표현되며, 분산된 소셜 네트워킹 서비스 간에 교환될 수 있습니다.

ActivityPub은 다른 프로토콜과 통합될 수 있습니다. 예를 들어, Mastodon, Pleroma, PeerTube 등의 소셜 네트워킹 서비스는 ActivityPub을 기반으로 구축되었으며, 사용자들이 서로를 팔로우하고 컨텐츠를 공유할 수 있습니다. 또한, OStatus, WebSub, Salmon 등과 같은 다른 표준 프로토콜과도 상호 작용할 수 있습니다.

ActivityPub은 자유롭고 개방적인 소셜 네트워킹 경험을 제공하기 위해 설계되었습니다. 사용자는 자신이 원하는 서비스를 선택하고 컨텐츠와 상호 작용할 수 있으며, 이 모든 것이 분산된 형태로 이루어집니다. 이를 통해 중앙 집중식 플랫폼에 의존하지 않고도 사용자들은 자신의 커뮤니티와 연결되고 상호 작용할 수 있습니다.

활동의 교환에 대해 더 설명해줘. 예를 들어 Mastodon 에 내가 컨텐츠 A를 올린 뒤 Mastodon 를 사용하지 않게 되더라도 다른 ActivityPub 기반의 서비스에서 내가 올렸던 컨텐츠 A를 유지할 수 있다는 말인가?

맞습니다. ActivityPub은 사용자들이 활동을 생성하고 교환할 수 있는 프로토콜입니다. 예를 들어, Mastodon에서 컨텐츠 A를 올렸다면, 해당 활동은 ActivityPub을 통해 다른 ActivityPub 기반의 서비스와 공유될 수 있습니다.

이는 분산된 소셜 네트워킹의 핵심 원리 중 하나입니다. 사용자가 Mastodon을 사용하던 다른 ActivityPub 기반의 서비스를 사용하던 상관없이, 활동은 프로토콜을 통해 다른 서비스에 전파됩니다. 다른 서비스에 가입한 사용자들은 Mastodon에서 올린 컨텐츠 A를 구독하고 볼 수 있습니다.

따라서, Mastodon을 사용하지 않게 되더라도 컨텐츠 A는 다른 ActivityPub 기반의 서비스에서 유지됩니다. 이는 분산된 소셜 네트워킹의 중요한 이점 중 하나입니다. 사용자는 자유롭게 서로 다른 서비스 간에 이동하면서 커뮤니티와 연결되고 컨텐츠를 공유할 수 있습니다.

다만, 이러한 활동의 전파는 각 서비스의 정책과 설정에 따라 달라질 수 있습니다. 일부 서비스는 특정 활동을 필터링하거나 일부 제한할 수도 있습니다. 또한, 사용자가 컨텐츠를 삭제하면 해당 활동은 전파되지 않을 수 있습니다. 따라서, 활동의 전파는 서비스 간의 정책과 사용자의 조작에 따라 달라질 수 있습니다.

분산에 사용되는 기술은?

ActivityPub은 분산된 소셜 네트워킹을 위한 중요한 프로토콜이지만, 이를 실현하기 위해 다양한 기술과 표준들이 함께 사용됩니다. 여기에는 다음과 같은 기술과 표준들이 포함됩니다:

분산된 식별자(Distributed Identifiers): 사용자와 리소스를 식별하기 위해 분산된 식별자 시스템이 사용됩니다. 예를 들어, Decentralized Identifiers (DIDs)는 사용자와 리소스에 고유한 식별자를 할당하고 이를 통해 분산 시스템에서 신뢰할 수 있는 식별을 제공합니다.
분산된 데이터 저장소: 분산된 소셜 네트워킹 시스템에서는 사용자의 프로필, 게시물, 댓글 등의 데이터를 저장하기 위해 분산된 데이터 저장소가 사용됩니다. 예를 들어, IPFS (InterPlanetary File System)는 분산된 파일 시스템으로서 데이터를 분산 저장하고 공유합니다.
페더레이션(Federation): ActivityPub은 페더레이션 모델을 채택하여 분산된 소셜 네트워킹을 실현합니다. 페더레이션은 다수의 독립된 서버들이 연결되어 사용자들이 서로 상호 작용할 수 있는 모델을 말합니다. 이를 통해 사용자는 자신이 선택한 서버에 가입하고, 다른 서버의 사용자와 컨텐츠를 공유하며 상호 작용할 수 있습니다.
웹 프로토콜: ActivityPub은 기본적으로 웹 프로토콜과의 통합을 지원합니다. HTTP, HTTPS, JSON-LD 등과 같은 웹 표준을 사용하여 데이터의 교환과 통신을 처리합니다. 이를 통해 다른 웹 기술과의 상호 운용성을 제공합니다.
PubSub(게시/구독): ActivityPub은 PubSub 모델을 사용하여 활동의 교환을 처리합니다. 이 모델은 사용자가 구독하고 있는 활동을 게시하고, 이를 구독자들이 수신하여 처리하는 방식으로 작동합니다. 이를 통해 사용자는 원하는 활동을 구독하고, 해당 활동이 발생할 때 알림을 받을 수 있습니다.

이러한 기술과 표준들이 ActivityPub과 함께 사용되어 분산된 소셜 네트워킹 시스템을 구축하고 상호 운용성을 제공합니다. 이는 중앙 집중식 플랫폼에 의존하지 않고 사용자들이 자유롭게 네트워크를 형성하고 상호 작용할 수 있는 분산된 환경을 가능하게 합니다.

게시물이나 계정 정보가 블록체인처럼 저장되는 건가?

ActivityPub 프로토콜 자체는 블록체인 기술을 사용하여 게시물이나 계정 정보를 저장하는 것을 강제하지 않습니다. ActivityPub은 분산된 소셜 네트워킹의 프로토콜적 측면을 다루며, 데이터 저장에 대한 구체적인 구현 방법은 프로토콜을 구현하는 각 서비스의 선택에 달려 있습니다.

블록체인은 탈중앙화와 불변성을 강조하는 기술로, 일반적으로 데이터를 블록 단위로 체인에 저장하여 변경이 어렵고 검증 가능하도록 합니다. 하지만 ActivityPub은 블록체인과는 다른 방식으로 동작합니다.

일반적으로 ActivityPub 기반의 소셜 네트워킹 서비스는 분산된 데이터 저장소나 분산된 파일 시스템을 사용하여 데이터를 저장합니다. 이러한 시스템은 중앙 집중식 서버와 달리 데이터를 여러 노드에 분산하여 저장하고 공유합니다. 이런 방식은 중앙 집중식 시스템의 단일 장애점을 피하고 데이터의 가용성과 내구성을 향상시킬 수 있습니다.

따라서, ActivityPub 기반의 소셜 네트워킹 서비스는 블록체인에 직접적으로 의존하지는 않지만, 분산된 데이터 저장소를 활용하여 사용자의 게시물이나 계정 정보를 저장하고 관리합니다. 블록체인을 사용할지 여부는 서비스 제공자의 결정에 달려 있으며, 현재 대부분의 ActivityPub 기반 서비스는 블록체인을 사용하지 않고 다른 분산 기술을 채택하고 있습니다.

구체적으로 Decentralized Identifiers (DIDs) 는 어떻게 구현하는가?

Decentralized Identifiers (DIDs)는 분산된 식별자 시스템으로, 사용자와 리소스를 고유하게 식별하기 위한 방법을 제공합니다. DIDs는 다음과 같은 구성 요소로 구현됩니다:

DID 문법: DID는 일반적으로 "did:"으로 시작하는 URI(Uniform Resource Identifier) 형식으로 표현됩니다. 예를 들면, "did:example:123456789"와 같은 형태입니다. "example"은 DID 메소드를 식별하는 식별자입니다. 이 식별자는 DID 메소드 제공자가 정의하고 관리합니다.
DID 메소드: DID 메소드는 DID 식별자를 처리하고 관리하기 위한 특정 프로토콜이나 시스템을 말합니다. 예를 들어, "example" DID 메소드는 DID를 처리하기 위한 특정 방법과 동작을 정의합니다. 이는 사용자가 DID를 생성, 검증, 해석하는 방법을 제공합니다.
DID 문서: DID 메소드는 각 DID에 대한 메타데이터와 식별 정보를 포함하는 DID 문서를 유지합니다. DID 문서는 JSON-LD 형식으로 표현되며, DID의 소유자, 공개키, 서비스 엔드포인트 등과 같은 정보를 포함합니다. 이 문서는 DID 식별자의 유효성 검사와 신뢰성을 제공하기 위해 사용됩니다.
DID 해결: DID 식별자는 DID 메소드에 따라 해결됩니다. DID를 해결하는 것은 해당 DID에 연결된 DID 문서를 가져오는 것을 의미합니다. 이를 통해 DID 사용자는 DID 식별자의 소유자와 관련된 정보를 확인할 수 있습니다.

구체적인 DID 구현은 DID 메소드 제공자에 따라 다를 수 있습니다. 예를 들어, "did:web"은 DID 메소드의 일종으로, 웹 호스팅을 사용하여 DID를 관리합니다. 다른 DID 메소드들은 블록체인 기술, 분산 데이터베이스, P2P 시스템 등 다양한 기술을 사용할 수 있습니다.

이러한 구성 요소를 통해 DIDs는 분산된 식별자 시스템을 구현하고, 사용자와 리소스를 분산 환경에서 식별할 수 있게 합니다. DIDs는 자기주권성, 신뢰성, 상호 운용성 등을 강조하는 탈중앙화된 식별자 체계를 제공합니다.

가능하면 코드와 함께 예시를 보여줘

다음은 Python을 사용하여 Decentralized Identifiers (DIDs)를 생성하는 간단한 예시 코드입니다. 이 예시에서는 DID 메소드로 "example"을 사용하고, DID는 UUID를 기반으로 생성됩니다.

python
import uuid

def generate_did():
    method = "example"
    did = f"did:{method}:{uuid.uuid4()}"
    return did

# DID 생성 예시
did = generate_did()
print(did)

위의 코드는 generate_did() 함수를 사용하여 DID를 생성합니다. generate_did() 함수는 "example" DID 메소드를 사용하고, uuid.uuid4()를 호출하여 UUID를 생성하여 DID 식별자에 추가합니다. 이렇게 생성된 DID는 "did:example:UUID" 형식을 가지게 됩니다.

실행 시 generate_did() 함수를 호출하여 DID를 생성하고, 생성된 DID를 출력합니다. 예를 들면 다음과 같습니다:

makefile
did:example:1a80754b-0fc0-4a49-9d3e-44e55e492bfb

위의 예시 코드는 간단한 DID 생성 과정을 보여주기 위한 것입니다. 실제로 DID를 사용하려면 해당 DID 메소드에 따라 DID 문서를 작성하고, DID 해결 방법을 구현해야 합니다. 또한, DID 메소드에 따라 추가적인 기능과 동작을 구현해야 할 수 있습니다.

DID 문서 예시

DID 문서는 DID 메소드에 따라 구체적인 형식을 가지게 됩니다. 각 DID 메소드는 DID 문서에 포함되어야 할 필수 필드와 추가적인 사용자 정의 필드를 정의합니다. 다음은 DID 문서의 예시로, "did:example:123456789"에 대한 간단한 DID 문서입니다.

json
{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789",
  "publicKey": [{
    "id": "did:example:123456789#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----"
  }],
  "authentication": [
    "did:example:123456789#keys-1"
  ],
  "service": [{
    "id": "did:example:123456789#service-1",
    "type": "SocialWebInbox",
    "serviceEndpoint": "https://social.example/actor/123456789/inbox"
  }]
}

위의 예시는 "@context", "id", "publicKey", "authentication", "service" 필드를 포함하고 있습니다.

"@context": 문서의 컨텍스트를 정의합니다. 위의 예시에서는 DID v1의 컨텍스트를 사용하도록 지정합니다.
"id": DID 식별자를 나타냅니다.
"publicKey": 사용자의 공개키 정보를 포함합니다. 여기서는 RSA 공개키를 사용하는 예시입니다.
"authentication": 인증에 사용될 특정 키 식별자를 나타냅니다.
"service": 사용자의 서비스 엔드포인트 정보를 포함합니다. 예시에서는 SocialWebInbox 서비스의 엔드포인트를 제공합니다.

실제 DID 문서는 DID 메소드에 따라 필드 구성이 달라질 수 있으며, 추가적인 필드나 사용자 정의 필드를 포함할 수도 있습니다. DID 문서는 JSON-LD 형식으로 표현되며, 해당 DID의 소유자와 관련된 신뢰할 수 있는 정보를 포함합니다.

IPFS (InterPlanetary File System) 같은 분산 저장소의 종류?

분산 저장소는 데이터를 분산되게 저장하고 공유하는 기술을 말합니다. IPFS (InterPlanetary File System)는 분산 파일 시스템의 한 예입니다. 그러나 IPFS 외에도 다른 분산 저장소의 종류가 있습니다. 일부 주요한 분산 저장소는 다음과 같습니다:

IPFS (InterPlanetary File System): IPFS는 분산된 파일 시스템으로서, 파일을 고유한 해시 기반 식별자로 저장하고 공유합니다. 파일을 작은 블록으로 분할하고 네트워크에서 중복 제거 및 캐싱을 통해 효율적인 파일 공유를 제공합니다.
DAT: DAT은 Peer-to-Peer 분산 데이터베이스 및 파일 시스템으로서, 분산된 데이터의 저장과 공유를 가능하게 합니다. DAT은 블록체인과 유사한 분산 해시 테이블(Distributed Hash Table, DHT)을 사용하여 데이터를 관리합니다.
Sia: Sia는 분산 클라우드 스토리지 플랫폼으로, 사용자는 Sia 네트워크의 컴퓨터 리소스를 활용하여 파일을 안전하고 개인적으로 저장할 수 있습니다. Sia는 블록체인 기술을 사용하여 파일 조각화, 암호화, 인증 등을 처리합니다.
Swarm: Swarm은 이더리움 기반의 분산 저장소 프로토콜로서, 파일을 네트워크에 분산하여 저장하고 공유합니다. Swarm은 블록체인과 통합되어 이더리움 스마트 컨트랙트를 통해 파일 관리와 인센티브 시스템을 구축할 수 있습니다.
Tahoe-LAFS: Tahoe-LAFS는 안전하고 개인적인 클라우드 스토리지 시스템으로서, 데이터를 암호화하고 분산 저장하여 보안과 개인 정보 보호를 강조합니다. Tahoe-LAFS는 여러 노드 간에 데이터를 조각화하여 저장하고 검증하며, 필요한 시점에 조각들을 복원하여 데이터를 액세스할 수 있습니다.

이 외에도 많은 분산 저장소 기술이 있으며, 각각 다른 특성과 장단점을 가지고 있습니다. 이러한 분산 저장소는 중앙 집중식 저장소의 단점을 극복하고, 안전성과 가용성을 향상시키는 분산형 데이터 관리를 위해 사용될 수 있습니다.

ActivityPub 구현 서비스 중에 오픈소스가 있나?

네, ActivityPub을 구현한 오픈 소스 소셜 네트워킹 서비스들이 있습니다. 이러한 서비스들은 소스 코드가 공개되어 있으며, 커뮤니티의 참여와 기여를 통해 발전하고 개선될 수 있습니다. 몇 가지 주요한 오픈 소스 ActivityPub 구현 서비스는 다음과 같습니다:

Mastodon: Mastodon은 가장 유명하고 널리 사용되는 오픈 소스 소셜 네트워킹 서비스입니다. ActivityPub을 기반으로 구축되었으며, 사용자들은 Mastodon 인스턴스에 가입하여 컨텐츠를 공유하고 상호 작용할 수 있습니다. Mastodon은 다양한 인스턴스들이 상호 연결되어 페더레이션을 형성하고 있습니다.
Pleroma: Pleroma도 오픈 소스 소셜 네트워킹 서비스로, ActivityPub을 사용하여 사용자들이 컨텐츠를 공유하고 상호 작용할 수 있도록 합니다. Mastodon과 유사한 기능을 제공하지만, 더 가벼운 리소스 요구와 높은 확장성을 갖추고 있습니다.
PeerTube: PeerTube은 분산된 동영상 공유 플랫폼으로, ActivityPub을 사용하여 사용자들이 동영상을 업로드하고 공유할 수 있습니다. PeerTube 인스턴스들은 페더레이션을 통해 서로 동영상을 공유하고 사용자들이 상호 작용할 수 있습니다.
Funkwhale: Funkwhale은 오픈 소스 음악 스트리밍 및 공유 플랫폼입니다. ActivityPub을 사용하여 사용자들이 음악을 업로드하고 공유하며, 페더레이션을 통해 다른 인스턴스들과 연결될 수 있습니다.

이 외에도 더 많은 오픈 소스 ActivityPub 구현 서비스들이 있습니다. 이들 서비스들은 자유롭게 사용하고 참여할 수 있으며, 개발자들은 이를 기반으로 자신만의 커스텀 소셜 네트워킹 플랫폼을 구축할 수도 있습니다.

ActiviyPub 관련해 Federation 이 뭐야?

Federation은 ActiviyPub 프로토콜의 핵심 개념 중 하나입니다. ActiviyPub은 탈중앙화된 소셜 네트워크 및 커뮤니케이션 플랫폼을 구축하기 위한 표준 프로토콜입니다. 이 프로토콜을 사용하면 여러 독립된 서비스와 애플리케이션이 상호작용하고 사용자들 간에 정보 및 활동을 공유할 수 있습니다.

Federation은 ActiviyPub 네트워크의 핵심 기능 중 하나로, 다양한 독립적인 서버 및 애플리케이션이 상호작용할 수 있도록 연결하는 방식을 의미합니다. 이러한 서버들은 사용자들에게 소셜 미디어 피드, 팔로우 관계, 좋아요, 리블로그 등과 같은 기능을 제공합니다. 사용자는 한 서버에서 등록하고 활동하더라도 다른 서버와 연결된 네트워크를 통해 사용자들의 활동을 공유하고 상호작용할 수 있습니다.

예를 들어, Alice와 Bob이라는 두 사용자가 서로 다른 ActiviyPub 서버에 가입했다고 가정해봅시다. Alice는 서버 A에 가입하고 Bob은 서버 B에 가입했습니다. 서버 A와 B는 Federation을 통해 연결되어 있으며, Alice는 Bob을 팔로우하고 상호작용할 수 있습니다. Alice는 서버 A에서 작성한 글을 서버 B에 등록된 Bob과 공유할 수 있으며, Bob은 서버 B에서 받은 알림을 통해 Alice와 상호작용할 수 있습니다.

이런 식으로 Federation은 ActiviyPub 서버들 사이의 상호운용성을 제공하며, 탈중앙화된 소셜 네트워크 생태계를 형성합니다. 이는 개인의 데이터와 활동에 대한 통제력을 강화하고, 단일 중앙화된 플랫폼에 종속되지 않고 다양한 선택지를 가질 수 있도록 합니다.

서버 A와 B간의 동기화 주기는?

서버 A와 B 간의 동기화 주기는 ActiviyPub 프로토콜 자체에서 명시적으로 정의되어 있지 않습니다. Federation은 분산 시스템의 개념이기 때문에 서버 간 동기화 주기는 구현에 따라 다를 수 있습니다. 이 주기는 서버 운영자 또는 개발자에 의해 설정될 수 있으며, 네트워크의 규모와 성능, 자원 제약 등에 따라 다양하게 조정될 수 있습니다.

실제로, ActiviyPub 서버는 사용자의 활동에 대한 이벤트를 전파하고 수신하며, 서로 다른 서버 간에 데이터를 공유하기 위해 프로토콜을 사용합니다. 이를 통해 서버 간의 동기화 및 정보 교환이 이루어집니다. 일반적으로, 활동이 발생하면 해당 활동은 송신 서버에서 다른 서버로 전송되어 동기화됩니다. 동기화 주기는 이벤트 전파 및 처리 속도에 따라 달라지며, 서버의 구성과 인프라에 따라 다를 수 있습니다.

따라서, 서버 A와 B 간의 동기화 주기는 구체적인 구현과 운영 환경에 따라 다를 수 있으며, 일반적으로 실시간 또는 최소한의 지연을 가지고 동기화를 수행하려는 경향이 있습니다.

Federation 관련 용어들을 알려줘.

Federation과 관련된 몇 가지 중요한 용어들은 다음과 같습니다:

Actor (액터): ActiviyPub 네트워크에 참여하는 개별 주체를 나타냅니다. 주로 사용자, 그룹, 페이지 등이 액터가 될 수 있습니다. 액터는 자신의 활동을 생성하고 다른 액터와 상호작용할 수 있습니다.
Instance (인스턴스): ActiviyPub 서버를 가리키는 용어로, 독립된 서비스 또는 애플리케이션을 나타냅니다. 예를 들어, Mastodon, Pleroma, Pixelfed 등은 ActiviyPub 인스턴스입니다.
Local Timeline (로컬 타임라인): 인스턴스에서 생성된 액터들의 공개 활동이 표시되는 타임라인입니다. 인스턴스의 사용자들은 이 타임라인을 통해 자신의 인스턴스 내에서 생성된 활동을 볼 수 있습니다.
Federated Timeline (연합 타임라인): 인스턴스와 연결된 다른 인스턴스들의 활동이 표시되는 타임라인입니다. 연합 타임라인은 연결된 서버들에서 생성된 활동들이 모두 모여 표시됩니다.
Follow (팔로우): 액터들 간의 관계를 나타내는 개념으로, 한 액터가 다른 액터를 팔로우하면 팔로우한 액터의 활동을 받아볼 수 있습니다. 이를 통해 팔로잉한 액터의 로컬 타임라인에 팔로우한 액터의 활동이 표시됩니다.
Boost (부스팅) 또는 Reblog (리블로그): 액터가 다른 액터의 활동을 공유하는 행위를 의미합니다. 부스팅은 해당 활동을 액터의 팔로워들과 공유하며, 리블로그는 해당 활동을 액터의 로컬 타임라인에 표시합니다.
Inbox (수신함): 액터들이 받은 활동 메시지를 저장하는 장소입니다. 액터는 자신의 인박스를 확인하여 다른 액터로부터 수신한 활동을 처리할 수 있습니다.

이러한 용어들은 ActiviyPub과 Federation 관련 용어들 중 일부이며, 탈중앙화된 소셜 네트워크 및 커뮤니케이션 플랫폼에서 흔히 사용되는 개념들입니다.

Actor 의 목록은 어떻게 관리 또는 공유되지?

ActiviyPub에서 액터(Actor)의 목록은 분산된 형태로 관리 및 공유됩니다. 각각의 ActiviyPub 인스턴스(서버)는 자체적으로 액터들을 저장하고 관리하며, 이러한 인스턴스들은 Federation을 통해 연결되어 서로 액터 정보를 교환합니다.

일반적으로, 각 인스턴스는 자체적인 데이터베이스 또는 저장 시스템을 사용하여 액터의 정보를 저장합니다. 이 정보에는 액터의 프로필, 팔로워 및 팔로잉 관계, 최근 활동 등이 포함될 수 있습니다. 사용자가 인스턴스에 가입하면 해당 인스턴스는 액터로 등록되고, 사용자의 데이터와 활동은 해당 인스턴스에 저장됩니다.

Federation을 통해 액터 정보는 서로 연결된 인스턴스들 사이에서 공유됩니다. 한 인스턴스에서 액터의 활동이 발생하면, 해당 활동은 다른 인스턴스로 전파됩니다. 이를 통해 인스턴스 간에 액터 정보의 동기화가 이루어지며, 사용자는 다른 인스턴스에 속한 액터들과 상호작용할 수 있습니다.

액터 목록의 관리 및 공유는 ActiviyPub 프로토콜 자체에 내장된 기능이 아니며, 인스턴스들 간의 상호운용성과 데이터 공유 방식은 구현에 따라 다를 수 있습니다. 일반적으로, 인스턴스들은 Federation 프로토콜을 준수하고 서로 통신할 수 있는 메커니즘을 구현하여 액터 정보를 교환합니다. 이는 연합 타임라인, 팔로우/언팔로우 동작, 검색 기능 등을 통해 다른 인스턴스의 액터들을 찾고 상호작용할 수 있도록 합니다.

이 블로그 검색

AI 와의 대화