Note

このドキュメントは2026-02-27 03:39にPLaMo Translation Modelを使用して自動翻訳されました。

FEP-2100: アンバウンド・グループと組織

本FEPは私個人の単独作業によるものではなく、SocialHubディスカッションにおける共同作業、およびそれ以前に行われたGNU social IRC/XMPPチャンネルでのrozzin氏（Joshua Judson Rosen）およびsomeonewithpc氏（Hugo Sales）との議論の成果です。

概要

歴史的に、人気インスタンスが突然閉鎖した場合、そのインスタンス上でホストされていたグループへの言及や、当該グループをフォローしている全ユーザーへの新インスタンス移転通知は不可能でした。もし常に完全なフォロワーリストを完全に把握できる状態であれば（あるいはそれに近い精度で）、より多くのローカルフォロワーを持つサーバーを新たなホームとして自動的に選択することが可能になります。別の選択肢としては、旧グループを自動アーカイブし、ゼロから再スタートする方法も考えられます。

これに対し本FEPでは、アクターをあるサーバーから別のサーバーへ自動的に移行させるという従来とは異なる概念を扱っています。異なるグループや組織間の連携を通じて、関連グループに所属する参加者間で一貫した体験を提供することを目的としています。我々は、このアプローチが単に「特定グループのホーム移転」を通知するだけの方法よりも実装が容易で柔軟性に富み、より良いユーザーエクスペリエンスを実現できると考えています。ただし、両ソリューションは前述のユースケースにおいて同様の結果をもたらす可能性が高いでしょう。

本提案では、あるグループが他のグループをフォローするという概念と、gs:unbound属性について新たな解釈を導入します。これにより、2つのグループ（または組織）が「一つの存在」として機能することが可能になります（厳密な意味ではありませんが、詳細は後述します）。

この仕組みの主な目的はグループに対する中央権限を実質的に排除することにありますが、それ以上の利点も提供します。この方式により、例えば@alice@undefinedhackers.netが"ハッカーズ"という名前のグループに言及したり（!hackers）、活動メッセージを!hackers@instance.gnusocial.test宛てに直接送信し（C2S）、そのインスタンス上の!hackersが他のインスタンスの!hackersに対して告知を行うことも可能になります。

最終的に、この提案は十分汎用的であり、サーバーが同時に以下の状態を実現できる仕様となっています： - !lug@server（リンクなし） - !lug-unbound@server（可能な限り多くのリンクを収集した状態） - !lug-with-some-links@server（一部のリンクのみを保持した状態）また、関連グループ間でpreferredUsernameが同一である必要もありません。

表記法と定義

簡潔に表現するため、以下の形式で記述する場合があります：Activity{Object}。例えばCreate{Note}は、オブジェクトフィールドにNoteを含むCreateアクティビティを意味します。本提案では主にGroupタイプのアクターに焦点を当てますが、これはOrganizationタイプにも適用可能です。

@nickname@serverは人物またはアプリケーション型のアクターを指す際に使用します
!nickname@serverはグループまたは組織型のアクターを指す際に使用します
@#!group@server#collectionは、!group@serverに属するcollectionというコレクションを参照する際に使用します

「MAY」「MUST」「MUST NOT」「SHOULD」「SHOULD NOT」という用語は、[RFC2119]の定義に従って解釈してください。

グループ間リンクに関する用語解説

グループ間リンク概念図

本メカニズムに必要なActivityStreams 2.0要件

本FEPにおけるグループアクターの具体例

{
  "type": "Group",
  "streams": [],
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "gs": "https://www.gnu.org/software/social/ns#"
    },
    {
      "unbound": {
        "@id": "gs:unbound",
        "@type": "@id"
      }
    }
  ],
  "id": "https://instance.gnusocial.test/group/hackers",
  "unbound": true,
  "preferredUsername": "hackers",
  "endpoints": {
    "sharedInbox": "https://instance.gnusocial.test/inbox.json"
  },
  "inbox": "https://instance.gnusocial.test/group/hackers/inbox.json",
  "outbox": "https://instance.gnusocial.test/group/hackers/outbox.json",
  "following": "https://instance.gnusocial.test/group/hackers/subscriptions",
  "followers": "https://instance.gnusocial.test/group/hackers/subscribers",
}

2つのグループアクター間のリンク作成方法

2つのグループアクター間に有向リンクを作成することは、任意の2アクター間で通常行われるフォローリクエストと同様の処理です。

例として、!hackers@instance.gnusocial.testが!lug@gnusocial.netに対してフォローリクエストを送信するケースを考えます。

もしgs:unbound: falseであるか設定されていない場合、!lug@gnusocial.netがこのフォローリクエストを受け入れた場合、自身の受信トレイに当該アクティビティをAnnounce{*}します。

gs:unbound: trueが設定されている場合、!lug@gnusocial.netはフォローリクエストを受け入れると同時に、!hackers@instance.gnusocial.testに対しても独自のフォローリクエストを送信します。

もし!hackers@instance.gnusocial.testと!lug@gnusocial.netの双方が互いをlinksToリストに追加した場合、それらは同じグループとして振る舞うことになります。両者のgroupLinksコレクションが完全に一致している場合、これらのグループは実質的に完全なミラーリング状態にあると言えます。

※「リンク交渉」プロセスは、2つのグループアクター間（S2S）で行われる点に留意してください。

想定されるシナリオ例

1. グループAが`gs:unbound = false`のグループBをフォローしようとする場合

AはBへのフォローを試みるべきではない；
BがAからのフォローリクエストを受け取った場合、拒否すべきである。

2. グループAが`gs:unbound = true`のグループBをフォローしようとする場合

AはBにフォローリクエストを送信するべきである；
Bはこれを承認すべきである；
Bは、Aがgs:unbound = trueの場合、Aに対してもフォローを行うべきである。

3. グループAが`gs:unbound`属性を持たないグループBをフォローしようとする場合

AはBにフォローリクエストを送信するべきである；
Bはこのリクエストを受け入れる可能性がある。

4. 受信トレイからの転送処理

!hackers@C：Announce{Note} TO !hackers@[B]（S2S）
Bは他のグループへこのアクティビティを転送してはならない。もし他のグループがこの活動を受け取ることを期待している場合、それらも!hackers@Cをフォローする必要がある。

参考文献

[ActivityPub] Christine Lemmer Webber, Jessica Tallon, ActivityPub, 2018年
[ActivityStreams語彙仕様] James M Snell, Evan Prodromou, ActivityStreams語彙仕様, 2017年
[RFC-2119] スティーブン・ブラッドナー, RFCで要件レベルを示すためのキーワード使用法, 1997年

著作権

CC0 1.0 Universal（CC0 1.0）パブリックドメイン献呈

本Fediverse Enhancement Proposalの著者らは、法律で認められる範囲内において、当該作品に関するすべての著作権および関連権利を放棄しています。