洪 民憙 (Hong Minhee)

Hello, I'm an open source software engineer in my late 30s living in #Seoul, #Korea, and an avid advocate of #FLOSS and the #fediverse.

I'm the creator of @fedify, an #ActivityPub server framework in #TypeScript, @hollo, an ActivityPub-enabled microblogging software for single users, and @botkit, a simple ActivityPub bot framework.

I'm also very interested in East Asian languages (so-called #CJK) and #Unicode. Feel free to talk to me in #English, #Korean (#한국어), or #Japanese (#日本語), or even in Literary Chinese (#文言文, #漢文)!

#introduction

安寧(안녕)하세요, 저는 서울에 살고 있는 30代(대) 後半(후반) 오픈 소스 소프트웨어 엔지니어이며, 自由(자유)·오픈 소스 소프트웨어와 聯合宇宙(연합우주)(fediverse)의 熱烈(열렬)한 支持者(지지자)입니다.

저는 TypeScript用(용) ActivityPub 서버 프레임워크인 @fedify 프로젝트와 싱글 유저用(용) ActivityPub 마이크로블로그인 @hollo 프로젝트와 ActivityPub 봇 프레임워크인 @botkit 프로젝트의 製作者(제작자)이기도 합니다.

저는 東(동)아시아 言語(언어)(이른바 #CJK)와 유니코드에도 關心(관심)이 많습니다. 聯合宇宙(연합우주)에서는 國漢文混用體(국한문 혼용체)를 쓰고 있어요! 제게 韓國語(한국어)나 英語(영어), 日本語(일본어)로 말을 걸어주세요. (아니면, 漢文(한문)으로도!)

#툿친소 #연친소 #별친소

こんにちは、私はソウルに住んでいる30代後半のオープンソースソフトウェアエンジニアで、自由・オープンソースソフトウェアとフェディバースの熱烈な支持者です。名前は洪 民憙（ホン・ミンヒ）です。

私はTypeScript用のActivityPubサーバーフレームワークである「@fedify」と、ActivityPubをサポートする1人用マイクロブログである 「@hollo」と、ActivityPubのボットを作成する為のシンプルなフレームワークである「@botkit」の作者でもあります。

私は東アジア言語（いわゆるCJK）とUnicodeにも興味が多いです。日本語、英語、韓国語で話しかけてください。（または、漢文でも！）

#自己紹介

(뒷북) Bridgy Fed를 만드는 비영리단체 A New Social에서 Bounce라는 새로운 도구를 FediForum에서 발표.
https://blog.anew.social/bounce-a-cross-protocol-migration-tool/

ActivityPub의 내 계정을 팔로워를 그대로 유지한 채로 Bluesky로 옮기거나, 그 반대도 가능하다네요. 각자의 프로토콜이 지향하는 바와 해결하는 문제가 다르지만 이렇게 두 세계을 연결해주는 일에 집중하는 단체가 있다는 건 정말 좋은 일이라고 생각해요

「静かなフェディバース」（quiet fediverse）問題を解決する二つのアプローチ：会話バックフィリングメカニズム

https://hackers.pub/@hongminhee/2025/quiet-fediverse-two-approaches/ja

연합우주(fediverse)를 사용해본 사람이라면 한 번쯤 경험했을 것입니다. 흥미로운 토론이 벌어지고 있는 것 같은데, 막상 그 대화를 들여다보면 답글이 몇 개 밖에 보이지 않거나, 맥락을 알 수 없는 답글들만 띄엄띄엄 나타나는 현상 말입니다. 마치 여러 사람이 모여 토론하고 있는데, 그 중 일부의 말만 들리는 것처럼 느껴집니다.

이것이 바로 연합우주 사용자들이 종종 겪는 “조용한 연합우주”(quiet fediverse) 문제입니다. 2025년 2월 브뤼셀 FOSDEM에서 열린 The Fediverse is Quiet—Let's Fix That! 발표는 이 문제를 정면으로 다뤘습니다.

이 글에서는 연합우주의 대화 단절 문제가 왜 발생하는지, 그리고 이를 해결하기 위해 개발자들이 제시한 두 가지 주요 접근법을 자세히 살펴보겠습니다. 각 방식의 기술적 원리부터 실제 구현 사례, 그리고 각각의 장단점까지 풍부한 예시와 함께 설명하겠습니다.

문제의 근본 원인: ActivityPub의 분산 특성

ActivityPub이란?

먼저 연합우주의 기반이 되는 ActivityPub 프로토콜을 이해해야 합니다. ActivityPub은 분산형 소셜 네트워크를 위한 W3C 표준 프로토콜로, 서로 다른 서버의 사용자들이 상호작용할 수 있게 해줍니다.

ActivityPub에서 모든 상호작용은 액티비티(activity)라는 형태로 표현됩니다. 예를 들어, 새 게시물을 작성하면 Create(Note) 액티비티가 생성되고, 답글을 달면 역시 Create(Note) 액티비티가 생성되어 해당 게시물에 대한 답글임을 나타냅니다. 자세한 내용은 ActivityStreams 2.0 스펙에서 확인할 수 있습니다.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "id": "https://alice.example/activities/create-reply-123",
  "actor": "https://alice.example/users/alice",
  "published": "2025-06-09T10:30:00Z",
  "to": ["https://bob.example/users/bob"],
  "object": {
    "type": "Note",
    "id": "https://alice.example/notes/reply-123",
    "content": "정말 흥미로운 관점이네요!",
    "inReplyTo": "https://bob.example/posts/original-post",
    "attributedTo": "https://alice.example/users/alice"
  }
}

분산의 딜레마

ActivityPub의 분산 특성이 바로 문제의 원인입니다. 중앙화된 플랫폼(X, Facebook 등)과 달리, 연합우주에서는 대화가 여러 서버에 걸쳐 분산되어 저장됩니다.

Alice(alice.example)가 원글을 작성하고, Bob(bob.example)이 Alice의 글에 답글을 달고, Charlie(charlie.example)가 Bob의 답글에 다시 답글을 달고, Dave(dave.example)가 Alice의 원글에 직접 답글을 다는 상황을 생각해보세요:

Alice의 원글
├── Bob의 댓글
│   └── Charlie의 댓글
└── Dave의 댓글

이때 각 서버는 다음과 같은 정보만 가지고 있을 수 있습니다. alice.example은 Alice의 원글과 Bob의 답글, Dave의 답글은 알지만 Charlie의 답글은 모를 수 있습니다. bob.example은 Alice의 원글과 Bob의 답글, Charlie의 답글은 알지만 Dave의 답글은 모를 수 있습니다. 결과적으로 어느 누구도 전체 대화의 완전한 그림을 볼 수 없게 됩니다.

해결책을 위한 기반 개념: context 속성

두 가지 주요 해결책을 살펴보기 전에, 핵심이 되는 context 속성에 대해 이해해야 합니다. ActivityStreams 2.0에서 정의된 context 속성은 관련된 오브젝트들을 그룹화하기 위해 사용됩니다. 하지만 스펙에서는 이를 “의도적으로 모호하게”(intentionally vague) 정의했기 때문에, 실제 구현에서는 다양한 방식으로 활용되고 있습니다.

실제 context 값의 형태들

1. 단순 식별자

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "content": "첫 번째 댓글입니다",
  "context": "https://example.com/conversations/abc123"
}

2. Mastodon 스타일 (ostatus:conversation)

Mastodon은 ActivityPub 표준의 context와 함께 OStatus 시절부터 사용해온 conversation 속성을 병행 사용합니다.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "ostatus": "http://ostatus.org#",
      "conversation": "ostatus:conversation"
    }
  ],
  "type": "Note",
  "content": "이것은 답글입니다",
  "context": "https://mastodon.social/contexts/abc123",
  "conversation": "tag:mastodon.social,2025:objectId=12345:objectType=Conversation"
}

3. 해석 가능한 컬렉션 URL (FEP 7888 방식)

이 경우 컨텍스트 URL로 GET 요청을 보내면 해당 대화의 모든 게시물을 포함한 OrderedCollection이 반환됩니다. 이는 FEP-7888: Demystifying the context property에서 제안한 방식입니다.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "content": "스레드 대화의 일부입니다",
  "context": "https://forum.example/topics/technology/thread-42",
  "inReplyTo": "https://forum.example/posts/789"
}

첫 번째 접근법: 답글 트리 크롤링 (reply tree crawling)

개요와 역사

답글 트리 크롤링 방식은 Mastodon의 @jonny 씨가 개척한 방법입니다. 2024년 4월 15일 처음 제안되어 2025년 3월 12일 Mastodon 코어에 병합되었습니다.

이 방식의 핵심 아이디어는 “모든 답글을 가져오기”(fetch all replies)입니다. 답글 트리 전체를 순차적으로 크롤링하여 누락된 대화를 찾아내는 것입니다.

기술적 작동 원리

1. 필요한 전제 조건

이 방식이 작동하려면 모든 ActivityPub 오브젝트가 replies 컬렉션을 제공해야 합니다. 이는 ActivityPub 오브젝트가 받은 답글들의 목록을 나타내는 컬렉션입니다. 이를 통해 특정 게시물에 달린 모든 답글을 탐색할 수 있습니다.

{
  "id": "https://alice.example/posts/1",
  "type": "Note",
  "content": "어떻게 생각하세요?",
  "replies": {
    "type": "OrderedCollection",
    "id": "https://alice.example/posts/1/replies",
    "totalItems": 3,
    "first": "https://alice.example/posts/1/replies?page=1"
  }
}

2. 크롤링 알고리즘

답글 트리 크롤링의 작동 방식은 본질적으로 깊이 우선 탐색(DFS)과 유사합니다. 시작점이 되는 게시물부터 시작해서 모든 답글을 찾아 내려가는 과정을 반복합니다.

구체적인 과정을 살펴보면, 먼저 시작 게시물의 replies 컬렉션을 확인합니다. 이 컬렉션에는 해당 게시물에 직접 달린 답글들의 목록이 들어있습니다. 그 다음 각 답글을 하나씩 가져와서 처리하는데, 여기서 중요한 것은 각 답글 역시 자신만의 replies 컬렉션을 가질 수 있다는 점입니다.

async function crawlReplyTree(postUrl: URL): Promise<Note[]> {
  const post = await fetchNote(postUrl);
  const allReplies: Note[] = [];
  
  const replies = await post.getReplies();
  if (replies) {
    for await (const reply of replies.getItems()) {
      if (reply instanceof Note) {
        allReplies.push(reply);
        const subReplies = await crawlReplyTree(reply.id!);
        allReplies.push(...subReplies);
      }
    }
  }
  
  return allReplies;
}

이 방식의 핵심은 각 노드(게시물)가 자신에게 달린 답글들의 목록을 정확히 제공한다는 가정에 기반한다는 점입니다.

3. Mastodon의 실제 구현

Mastodon에서는 이론적인 알고리즘을 실제 네트워크 환경에 맞게 조정한 구현을 사용합니다. 핵심적인 차이점은 현실적인 제약들을 고려한다는 점입니다.

@jonny 씨의 설명에 따르면, 현재 구현에는 몇 가지 실용적인 고려사항이 포함되어 있습니다. 확장된 게시물에서 시작해서 아래로 진행하며, 트리의 어느 지점에서든 크롤링을 시작할 수 있고, 중복 크롤링을 방지하는 쿨다운 메커니즘을 포함합니다.

장점

• 범용성: inReplyTo와 replies 속성은 거의 모든 ActivityPub 구현에서 보편적으로 사용됩니다. 따라서 기존 인프라를 크게 변경하지 않고도 적용할 수 있습니다.

• 구현 간 일관성: 대부분의 ActivityPub 구현체에서 이 속성들의 사용법이 크게 다르지 않습니다.

• 완전한 트리 구성: 이상적인 경우 모든 브랜치와 리프를 포함한 완전한 대화 트리를 얻을 수 있습니다.

단점

• 네트워크 취약성: 답글 트리의 단일 노드가 일시적 또는 영구적으로 접근 불가능하면, 해당 노드에서 파생되는 모든 브랜치들도 접근할 수 없게 됩니다.

• 선형적 작업량 증가: CPU 시간, 네트워크 요청 등의 작업량이 답글 트리 크기에 비례하여 선형적으로 증가합니다. 대규모 토론에서는 성능 문제가 발생할 수 있습니다.

• 재크롤링 필요성: 새로운 브랜치 발견을 위해서는 전체 답글 트리를 다시 크롤링해야 합니다. 빠르게 성장하는 토론에서는 크롤링 시작 시점에 따라 완전한 트리를 얻지 못할 수 있습니다.

• 불완전한 구현 현실: 현실적으로 모든 ActivityPub 구현체가 replies 컬렉션을 제공하지는 않습니다. Mastodon은 성능상 이유로 같은 서버의 답글만 최대 5개까지 replies 컬렉션에 포함하며, 많은 소규모 구현체들은 성능상 이유로 이를 생략하거나 불완전하게 구현합니다.

현재 구현 현황

현재 Mastodon이 이 방식의 유일한 완전한 구현체입니다. 하지만 이 방식은 Mastodon 고유의 것이 아니며, 다른 구현체들도 채택할 수 있습니다.

두 번째 접근법: 컨텍스트 소유자 기반 방식 (context owner approach)

개요와 배경

컨텍스트 소유자 방식은 여러 FEP^[1]의 결합으로 탄생했습니다. FEP-7888은 “context 속성 명확화”(demystifying the context property)를 다루고, FEP-171b는 “대화 컨테이너”(conversation containers)를 정의하며, FEP-f228은 위 FEP들의 통합 및 확장을 제안합니다.

이 방식의 핵심은 “컨텍스트 소유자”(context owner) 개념입니다. 대화의 원 작성자나 지정된 주체가 해당 대화의 모든 내용을 관리하는 중앙화된 접근법입니다.

기술적 작동 원리

1. 컨텍스트 소유자의 역할

컨텍스트 소유자는 누가 되는가? 일반적으로 스레드의 최상위 게시물(루트 포스트)을 작성한 사용자가 컨텍스트 소유자가 됩니다. 예를 들어, Alice가 “오늘 날씨가 어떤가요?”라는 원글을 작성했다면, Alice가 해당 대화의 컨텍스트 소유자가 되는 것입니다.

그러나 포럼이나 그룹 환경에서는 포럼 관리자나 그룹 소유자가 컨텍스트 소유자 역할을 할 수도 있습니다. 핵심은 누군가 한 명이 해당 대화의 “정규 멤버십”을 결정할 권한을 가진다는 점입니다.

컨텍스트 소유자는 자신이 관리하는 대화의 모든 멤버를 포함하는 OrderedCollection을 제공합니다.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/fep/171b"
  ],
  "type": "OrderedCollection",
  "id": "https://alice.example/conversations/tech-discussion",
  "attributedTo": "https://alice.example/users/alice",
  "collectionOf": "Activity",
  "totalItems": 15,
  "orderedItems": [
    "https://alice.example/activities/add/1",
    "https://alice.example/activities/add/2",
    "https://alice.example/activities/add/3"
  ]
}

2. 두 단계 액티비티 프로세스

이 방식에서는 댓글 추가가 반드시 두 단계로 이루어져야 합니다. 왜 이렇게 복잡하게 해야 할까요?

첫 번째 이유는 모더레이션입니다. 단순히 답글을 작성한다고 해서 자동으로 해당 대화에 포함되는 것이 아니라, 컨텍스트 소유자의 승인을 거쳐야 합니다.

두 번째 이유는 일관성입니다. 컨텍스트 소유자가 관리하는 컬렉션에는 Add 액티비티들만 들어가므로, 나중에 이 컬렉션을 읽는 다른 서버들이 “이것들은 모두 컨텍스트 소유자가 승인한 내용들”이라는 것을 명확히 알 수 있습니다.

세 번째 이유는 확산(broadcasting)입니다. 직접 댓글 뿐만 아니라 대화에 속하는 모든 댓글과 대댓글은 모두 컨텍스트 소유자에게 전송되기에 컨텍스트 소유자는 그 대화에 포함되는 모든 노드를 파악하고 있습니다. 따라서, 모든 대화 참여자들에게 새 댓글이 추가되었다는 것을 통보할 수 있습니다.

1단계: 답글 작성자가 일반적인 Create(Note) 액티비티 전송

Bob이 Alice의 게시물에 답글을 달고 싶어합니다. Bob은 평소처럼 Create(Note) 액티비티를 생성하되, Note 오브젝트의 context 속성에 Alice가 관리하는 대화 ID를 포함합니다.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "actor": "https://bob.example/users/bob",
  "published": "2025-06-09T11:00:00Z",
  "to": ["https://alice.example/users/alice"],
  "object": {
    "type": "Note",
    "id": "https://bob.example/notes/reply-456",
    "content": "정말 좋은 지적이군요!",
    "inReplyTo": "https://alice.example/posts/original",
    "context": "https://alice.example/conversations/tech-discussion"
  }
}

중요한 점은 Bob이 이 액티비티를 컨텍스트 소유자인 Alice에게 직접 전송한다는 것입니다(to 필드 참조). 이는 Alice가 Bob의 답글을 알 수 있도록 하기 위함입니다.

2단계: 컨텍스트 소유자(Alice)가 Add(Note) 액티비티 생성

Alice는 Bob의 답글을 받고, 이것이 자신의 대화에 포함할 만한 내용이라고 판단합니다. 그러면 Alice는 Add(Note) 액티비티를 생성하여 Bob의 답글을 자신의 대화 컬렉션에 추가합니다.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Add",
  "actor": "https://alice.example/users/alice",
  "published": "2025-06-09T11:05:00Z",
  "object": "https://bob.example/notes/reply-456",
  "target": {
    "type": "OrderedCollection",
    "id": "https://alice.example/conversations/tech-discussion",
    "attributedTo": "https://alice.example/users/alice"
  },
  "to": ["https://www.w3.org/ns/activitystreams#Public"]
}

이 Add 액티비티는 “Alice가 Bob의 답글을 자신의 대화에 공식적으로 포함시켰다”는 의미입니다. 만약 Alice가 Bob의 답글이 스팸이나 부적절한 내용이라고 판단했다면, 이 Add(Note) 액티비티를 생성하지 않을 수 있습니다.

3. 백필 메커니즘

개별 구현체들은 컨텍스트 소유자에게 전체 대화 내용을 요청할 수 있습니다.

async function performContextBackfill(contextUrl: URL): Promise<Note[]> {
  const collection = await fetchCollection(contextUrl);
  const notes: Note[] = [];
  
  for await (const item of collection.getItems()) {
    if (item instanceof Add) {
      const note = await item.getObject();
      if (note instanceof Note) {
        notes.push(note);
      }
    }
  }
  
  return notes;
}

장점

• 의사 중앙화(pseudo-centralization)의 이점: 컨텍스트 소유자가 제공하는 “단일 진실의 원천”(single source of truth)을 통해 일관된 대화 상태를 유지할 수 있습니다.

• 효율적인 네트워크 사용: 컨텍스트 소유자에게 한 번의 요청으로 전체 대화를 가져올 수 있어, 답글 트리 크롤링보다 네트워크 효율성이 높습니다.

• 중간 노드 장애 극복: 답글 트리 크롤링과 달리, 중간 노드가 다운되어도 컨텍스트 소유자를 통해 전체 대화에 접근할 수 있습니다.

• 효율적인 중복 제거: 컨텍스트 레벨에서 오브젝트 중복 제거가 가능하여 전체 네트워크 요청 수와 CPU 시간을 줄일 수 있습니다.

• 동기화 최적화: ID 해시섬을 통한 동기화 방법으로 네트워크 호출을 더욱 줄일 수 있습니다.

단점

• 컨텍스트 소유자 의존성: 가장 큰 약점은 컨텍스트 소유자에 대한 의존성입니다. 컨텍스트 소유자 서버에 접근할 수 없으면 전체 대화 백필이 불가능해집니다.

• 제한된 가시성: 컨텍스트 소유자는 자신이 알고 있는 오브젝트/액티비티만 응답할 수 있습니다.

• 상위 전파 누락 문제: 핵심적인 한계로, 루트로 다시 상위 전파되지 않는 하위 브랜치들은 컨텍스트 소유자가 알 수 없습니다.

• 구현체 지원 필요: 컨텍스트 소유자가 이 방식을 지원해야만 작동하므로, 다른 백필 전략과 결합해야 합니다.

현재 구현 현황

NodeBB, Discourse, WordPress, Frequency, Mitra, Streams가 현재 이 방식을 구현하고 있으며, Lemmy와 Piefed가 관심을 표명하고 있습니다.

중요한 논쟁 포인트들

1. 모더레이션 패러다임의 충돌

관련 NodeBB 스레드에서 @silverpill 씨가 제기한 핵심적인 문제점입니다.

두 접근 방식이 서로 충돌하지 않는다고 했지만, 이 ‘스레딩 패러다임’들은 모더레이션 문제에 대해 서로 다른 해결책을 제시합니다.

I don't fully agree with this statement, because these ‘threading paradigms’ suggest two different solutions to the problem of moderation.

컨텍스트 소유자 방식의 모더레이션

Alice가 스팸 댓글에 대해 Add(Note) 액티비티를 생성하지 않으면, 해당 댓글은 대화에서 제외됩니다.

답글 트리 크롤링의 모더레이션

각 답글이 독립적이며, 작성자들이 직접 답글만 모더레이션할 수 있습니다. 원글 작성자가 전체 대화를 제어할 수 없습니다.

2. 상위 전파 누락 문제의 해결책

어드레싱 규칙 활용 (FEP-171b)

FEP-171b에서는 “답글의 audience는 대화 루트에서 복사되어야 한다”(The audience of a reply MUST be copied from a conversation root)는 규칙을 제시합니다.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "actor": "https://charlie.example/users/charlie",
  "object": {
    "type": "Note",
    "content": "Bob의 댓글에 대한 답글",
    "inReplyTo": "https://bob.example/comments/2",
    "context": "https://alice.example/conversations/1",
    "to": [
      "https://bob.example/users/bob",
      "https://alice.example/users/alice"
    ]
  }
}

하이브리드 백필 메커니즘

많은 구현체가 여러 방식을 조합하는 방식을 채택합니다.

async function hybridBackfill(conversationId: URL): Promise<Note[]> {
  const strategies = [
    () => contextOwnerBackfill(conversationId),
    () => replyTreeCrawling(conversationId),
    () => mentionBasedDiscovery(conversationId)
  ];
  
  for (const strategy of strategies) {
    try {
      const result = await strategy();
      if (result.length > 0) return result;
    } catch (error) {
      console.warn('Strategy failed, trying next:', error);
    }
  }
  
  return [];
}

추가적인 백필 메커니즘들

1. 주기적 크롤링 백필: 이 방식은 마치 정기적인 건강검진과 같습니다. 시스템이 정해진 주기마다 활발한 대화들을 점검하여 누락된 답글이 있는지 확인합니다.

2. 사용자 트리거 백필: 사용자가 특정 대화 페이지에 접속하면, 시스템은 즉시 현재 보유한 컨텍스트 컬렉션을 검토하고 실시간으로 누락된 답글들을 탐색합니다.

3. 멘션 기반 백필: 사용자들이 대화에서 다른 사람을 멘션하는 자연스러운 행동을 통해 누락된 답글 체인을 발견하는 메커니즘입니다.

   async function onMentionReceived(activity: Create): Promise<void> {
     const mention = await activity.getObject();
   
     if (mention.context && mention.replyTargetId) {
       const missingChain = await traceReplyChain(await mention.getReplyTarget());
       await addToContext(mention.context, missingChain);
     }
   }

실제 도전과제들

1. 순환 참조 방지: 백필 과정에서 무한 루프에 빠지는 것을 방지하는 것은 매우 중요합니다. 실제 구현에서는 방문한 URL을 추적하고, 최대 탐색 깊이를 제한하는 안전장치를 마련합니다.

2. 성능 최적화: 대규모 대화에서는 수백 개의 답글이 달릴 수 있고, 이를 모두 한 번에 처리하려고 하면 서버에 과도한 부하가 걸릴 수 있습니다. 일괄 처리(batch processing)는 여러 대화를 동시에 처리할 때 작은 그룹으로 나누어 순차적으로 처리하고 각 배치 사이에 짧은 휴식 시간을 두는 방식입니다.

3. 오류 처리 및 복구: 분산 네트워크 환경에서는 다양한 종류의 오류가 발생할 수 있습니다. 실제 구현에서는 여러 백필 전략을 순차적으로 시도하는 복원력 있는 접근법을 사용합니다.

표준화 노력과 미래 전망

FEP 수렴 논의

현재 연합우주 커뮤니티에서는 FEP 수렴 스레드를 통해 여러 FEP들을 통합하려는 노력이 진행되고 있습니다.

이 논의에서 다루고 있는 주요 FEP들은 공개적으로 추가 가능한 ActivityPub 컬렉션을 정의하는 FEP-400e, 애매하게 정의된 context 속성에 대한 구체적인 사용법을 제시하는 FEP-7888, 중앙화된 대화 관리 메커니즘을 다루는 FEP-171b, 그리고 답글 트리의 전체적인 시각화 방법을 제안하는 FEP-76ea입니다.

구현체 간 협력

현재 다양한 구현체들이 실용적인 상호 호환성을 위해 협력하고 있습니다. 이는 완벽한 표준이 확정되기를 기다리기보다는, 현재 사용 가능한 방법들을 조합해서 최선의 결과를 얻으려는 실무적 접근입니다.

NodeBB와 Discourse의 협력 사례

이 두 포럼 소프트웨어는 포럼에 특화된 백필 메커니즘을 공유하고 있습니다. 포럼의 특성상 대화가 구조화되어 있고 장기간 지속되는 경우가 많아서, 토픽과 카테고리 개념을 활용한 컨텍스트 관리가 특히 중요합니다.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "context": "https://community.nodebb.org/topic/18844",
  "audience": "https://community.nodebb.org/category/development",
  "tag": [
    {
      "type": "Link",
      "href": "https://meta.discourse.org/t/activitypub-support/12345",
      "rel": "related"
    }
  ]
}

Mastodon과의 호환성 고려

Mastodon은 가장 큰 연합우주 플랫폼이기 때문에, 다른 구현체들은 Mastodon과의 호환성을 고려해야 합니다. 특히 Mastodon이 사용하는 ostatus:conversation 개념을 함께 지원하는 경우가 많습니다.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "ostatus": "http://ostatus.org#",
      "conversation": "ostatus:conversation"
    }
  ],
  "type": "Note",
  "content": "Mastodon 호환 답글",
  "context": "https://mastodon.social/contexts/abc123",
  "conversation": "tag:mastodon.social,2025:objectId=12345:objectType=Conversation"
}

이런 하위 호환성 유지는 연합우주 생태계의 분열을 방지하고 사용자 경험을 개선하는 데 중요한 역할을 합니다.

향후 개발 방향: 하이브리드 접근법의 표준화

미래에는 단일한 “정답”을 찾는 것보다는 여러 방식을 체계적으로 조합하는 표준화된 접근법이 등장할 가능성이 높습니다. 이는 각 방식의 장점을 살리면서 단점을 보완하는 best-of-both-worlds 접근법입니다.

모범 사례 가이드라인

1. 다중 전략 구현: 절대로 하나의 백필 방식에만 의존하지 마세요. 연합우주의 다양성과 불확실성을 고려할 때, 여러 전략을 조합하는 것이 필수적입니다. 각 전략은 서로 다른 상황에서 강점을 보이므로, 상황에 따라 적절한 전략을 선택할 수 있는 유연성을 확보해야 합니다.

   예를 들어, 활발한 포럼 토론에서는 컨텍스트 소유자 방식이 효과적일 수 있지만, Mastodon의 일반적인 대화에서는 답글 트리 크롤링이 더 적합할 수 있습니다.

2. 리소스 관리: 백필 작업은 상당한 서버 리소스를 소모할 수 있습니다. 특히 인기 있는 대화나 대규모 토론의 경우 수백 개의 네트워크 요청이 필요할 수 있습니다. 따라서 적절한 제한과 조절 메커니즘을 구현해야 합니다.

3. 모니터링 및 로깅: 백필 시스템의 성능과 신뢰성을 지속적으로 모니터링하는 것이 중요합니다. 어떤 방식이 가장 효과적인지, 어떤 종류의 오류가 자주 발생하는지 등을 추적해야 합니다.

결론

“조용한 연합우주” 문제는 분산형 소셜 네트워크의 근본적인 도전과제입니다. 이 글에서 살펴본 두 가지 주요 접근법—답글 트리 크롤링과 컨텍스트 소유자 방식—은 각각 고유한 장단점을 가지고 있습니다.

핵심 통찰

완벽한 해결책은 없습니다. 두 접근법 모두 특정 상황에서 한계를 보입니다. 분산 네트워크의 본질적인 특성상 100% 완벽한 대화 복구는 현실적으로 어려울 수 있습니다.

하이브리드 접근이 현실적입니다. 대부분의 성공적인 구현체들은 여러 백필 전략을 조합해서 사용합니다. 한 가지 방법이 실패해도 다른 방법으로 보완할 수 있는 탄력성이 중요합니다.

표준화가 진행 중입니다. FEP 과정을 통해 상호 호환성을 높이려는 노력이 계속되고 있습니다. 하지만 완전한 표준을 기다리기보다는 현재 가능한 방법들을 실용적으로 조합하는 것이 더 현실적입니다.

사용자 경험이 핵심입니다. 기술적 완성도도 중요하지만, 최종적으로는 사용자가 완전한 대화를 볼 수 있느냐가 관건입니다. 기술적 우아함보다는 실용적 효과를 우선시해야 합니다.

앞으로의 방향

연합우주의 대화 백필 문제는 단순히 기술적인 문제를 넘어서 분산형 네트워크에서의 거버넌스, 모더레이션, 사용자 경험의 복합적인 문제입니다.

특히 모더레이션 패러다임의 차이는 단순한 기술적 호환성을 넘어서는 철학적 문제입니다. 컨텍스트 소유자가 전체 대화를 제어할 수 있어야 하는가, 아니면 각 답글 작성자가 독립적으로 모더레이션할 수 있어야 하는가? 이런 질문들은 연합우주가 어떤 종류의 소셜 공간이 되어야 하는지에 대한 근본적인 고민과 연결됩니다.

2025년은 이러한 문제들에 대한 해결책들이 본격적으로 배포되고 테스트되는 해가 될 것으로 보입니다. 개발자들과 사용자들의 지속적인 관심과 참여를 통해, 연합우주가 더욱 풍부하고 연결된 소셜 네트워크로 발전해 나갈 수 있을 것입니다.

중요한 것은 완벽함보다는 개선입니다. 현재의 “조용한 연합우주” 문제가 완전히 해결되지는 않더라도, 이런 노력들을 통해 사용자들이 더 완전한 대화를 경험할 수 있게 된다면 그것만으로도 의미 있는 진전이라고 할 수 있습니다.

朴露子(박로자) 〈‘높으신 분’ 없는 世上(세상)을 위하여!〉

@kodingwarrior 아직 개발중이라 실리콘 모에에서는 안 될 거예요.

時代(시대)가 흘러서 「閣下(각하)」라는 말을 버렸는데, 요즘 다시 「大統領(대통령) 님」이라는 表現(표현)을 보게 된다…

We're migrating Hackers' Pub to a pretty unconventional tech stack, and I'm honestly excited about it!

Thanks to my friend @xiniha, we're diving into #Solid, #SolidStart, #Pothos, #GraphQL, and #Relay. In a world dominated by Next.js and React, this feels refreshingly different. And yes, we're sticking with #Deno instead of Node.js too.

Some might call it contrarian, but I like to think of it as exploring what's possible beyond the mainstream. Sometimes the road less traveled leads to interesting places.

Accidentally added a few bugs to @hollo leading to three additional releases 🫣

But we fixed them all once we could figure out what was going on

ActivityPub을 만지던 진짜 이유를 언급하자면, 내년 출시를 목표로 ActivityPub 기반의 OTX라는걸 만들려고 합니다.

자세한 설명은 어려우니 간단하게만 말씀 드리면, 각국의 정보기관에서도 사용하는 정보공유 개념입니다.

많은 응원 바랍니다.

디자인은 @druidesse 님이 도와주시고 계십니다.

안녕하세요!

제가 소유하고 있는 아래 두 도메인을 양도받으실 분을 구합니다.

- mastodon.kr
- mstdn.kr

관심이 있으신 분은 디엠 보내주세요.

- 가급적이면 마스토돈 / 페디버스 운영이나 개발에 관여되어 있으신 분이 양도 받았으면 합니다.

- 무상으로 양도 드릴 예정이지만, 도메인 업체에서 명의 이전 수수료같은게 따로 부과되는 경우 별도로 지불해 주셔야 할 수도 있습니다!

감사합니다!

페미위키 개발팀에서 오픈 소스 컨트리뷰터 및 개발팀을 모집한다고 합니다!

RE: https://hackers.pub/@femiwiki/01974b1f-4e46-798c-a36f-e89bb48cc30a

안녕하세요, 페미위키 개발팀입니다. 개발팀 활성화를 위해 이리저리 둘러보다 해커스펍에 대해 알게 되었습니다. 여건이 되면 페미위키 개발에 대해서 얘기할 수 있는 기회를 만들어보려 합니다!

더불어 페미위키 개발팀에서 오픈소스 컨트리뷰터 & 개발팀을 모집합니다! 페미니스트시라면 정체성 불문, 거주국 불문하고 모시고 있습니다. 함께 페미니즘 정보집합체 만들어가요!

Great demo of @encyclia by @julian

Day 3 of #Fediforum starts strong with a great tool for the academic sphere👏

Making #Orcid available for #activitypub via @fedify

Open science communication is very relevant for the future development of the #Fediverse 🚀

@reiver @hongminhee I ran an unconference session at @fediforum yesterday about "Implementing ActivityPub in 2025" but we were a pretty small group of people and went off topic a bunch, so the session notes is mostly just me trying to advertise @fedify. 🙃

Day 3 of #Fediforum is starting up with some demos! Up first, Encyclia, a way to share ORCID data on the fediverse. Follow at @encyclia

https://encyclia.pub/

Julian Fietkay ( @julian ) just said nice things about @fedify at FediForum 2025.

cc: @hongminhee

#FediForum

페미위키 개발팀(@femiwiki)을 환영합니다!

We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.

🌐 Cloudflare Workers support

Fedify 1.6 introduces first-class support for Cloudflare Workers, enabling #serverless deployment of #ActivityPub applications at the edge.

New components

• WorkersKvStore: A key–value store implementation using Cloudflare's KV API for persistent storage in Workers environments
• WorkersMessageQueue: A message queue implementation leveraging Cloudflare Queues for reliable message processing

Key features

• Seamless integration with #Cloudflare's serverless runtime
• Automatic handling of queue message processing through Workers' queue() method
• Support for Node.js compatibility flag required for Fedify's cryptographic operations
• Manual queue processing via Federation.processQueuedTask() method

For a complete working example, see the Cloudflare Workers example in the Fedify repository.

🏗️ Federation builder pattern

Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:

• Deferred instantiation: Set up dispatchers and listeners before creating the federation object
• Better code organization: Avoid circular dependencies and improve project structure
• Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
• Modular setup: Build complex federations piece by piece before instantiation

The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.

🔐 HTTP Message Signatures (RFC 9421)

Fedify 1.6 implements the official HTTP Message Signatures standard (RFC 9421) specification, the final revision of the HTTP Signatures specification.

Double-knocking mechanism

To ensure maximum compatibility across the fediverse, Fedify 1.6 introduces an intelligent double-knocking mechanism:

1. Primary attempt: RFC 9421 (HTTP Message Signatures) for modern implementations
2. Fallback: Draft cavage version for legacy compatibility
3. Adaptive caching: The system remembers which version each server supports to optimize future requests

This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.

Interoperability testing

The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:

• Mitra 4.4.0: Successfully verified Fedify-generated RFC 9421 signatures
• Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)

These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.

🔍 WebFinger enhancements

Dedicated WebFinger lookup

The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.

🛠 Context API improvements

Context data replacement

The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.

🚀 Migration considerations

Backward compatibility

Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.

Node.js version requirement

Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.

New deployment options

For new deployments, consider leveraging Cloudflare Workers support for:

• Global edge deployment with low latency
• Serverless scaling and automatic resource management
• Integration with Cloudflare's ecosystem of services

🎯 Looking forward

Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.

For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.

#fedidev #RFC9421 #HTTPSignatures #HTTPMessageSignatures #CloudflareWorkers

@liaizon @kiwiyou I guess those screenshots are not from a translation website, but from a dictionary.

[페미위키 6월 운영팀 모집]
운영팀은 페미위키를 어떻게 키워낼까 고민하는 개인들의 모임이며 여성혐오자가 아니라면 추가 조건 없이 함께할 수 있습니다.
운영팀 연락에 사용할 구글 지메일로 admin@femiwiki.com으로 지원 동기를 적어 보내주세요. (제목 "페미위키 운영팀 지원")

이럴 수가 이준석 제명 청원 진짜로 30만 돌파?!

이렇게 된 이상 7월 4일까지 최대한 달려 봅시다! 주변에 알려 봅시다!

목표는 이준석의 대선 득표수 292만인 걸로!!

https://petitions.assembly.go.kr/proceed/onGoingAll/327534C853DF2656E064B49691C1987F

「펀쿨섹座(좌)」… 😂

https://mainichi.jp/articles/20250522/k00/00m/030/270000c

이준석 의원 제명 국회청원서명입니다. 많은 참여 부탁드립니다.

https://petitions.assembly.go.kr/proceed/onGoingAll/327534C853DF2656E064B49691C1987F

What client apps do you use with #Hollo?

👀 noted: quick look at what Deno are cooking https://dbushell.com/notes/2025-06-07T07:01Z/

どうやらメインで使ってるクライアントアプリがPhanpyだから、Holloのテストする時もついPhanpyばかりでやってたけど、これからは他のクライアントアプリでもテストしなきゃな。特にリリース前はQAプロセスとして、必ずいろんなクライアントでテストしないと。

🚨 Known Issue: Elk (@elk) login may fail on Hollo instances upgraded from 0.5.x to 0.6.x with 401 Unauthorized errors. Fresh 0.6.x installs work fine. Other clients (Phanpy, Moshidon) are unaffected.

We're investigating: https://github.com/fedify-dev/hollo/issues/167

Workaround: Use alternative clients like Phanpy (@phanpy) for now.

@hollo @kodingwarrior @jihyeok 하스켈 카페 하나 만들어 주세요…