MastodonやMisskeyが、それぞれ別々に設置されている違うプログラムなのに、お互いに繋がることができる仕組みは、主に『ActivityPub』という通信規約（プロトコル）によって実現されています。
ActivityPubでは、私たち一人一人のアカウントをActorと呼びます。
Actorは、別のActorと、「フォローしたい」「いいよ」というやりとりをします。
投稿に対して「好き！」って反応したり、新しいノートを「作ったよ」、ノートをみんなに「アナウンス」します（ブースト・リノート）
これらのやりとりの語彙があらかじめ定義されています。
先程の例の順番でいうと、Follow, Accept, Like, Create, Announce というActivityとして定義されています。
Activityは、何を対象とするかを伴っていて、Actorを対象とするときもあれば、投稿（短い文章）を表す表現であるNoteや、「フォローしたい」というリクエストを許可したり、送った側が取り消すために、「フォローしたい」というActivityそのものを対象として指定することもあります。
このあたりの約束ごとが共通化されているため、それに従うことで、お互いのやりとりが可能になっています。
Actorは、それぞれがinboxというActivityを受け入れる窓口を持っていて、他のActorから送られてきたActivityを処理します。
また、自分が送ったActivityをoutboxに保持しています（ずっと溜まっていきます）。
フォローしているActorのコレクション following も持っています。
フォローされているActorのコレクション followers も持っています。
これは、フォローを要求して、それが受け入れられた時に、お互いがコレクションに追加することで、その状態を維持します。
新しい投稿（Note）をCreateした時、つまり新規投稿時には、followersコレクションのActorのinboxに対してActivityを送ります。
そうすると、フォロワーのActorは、inboxに届いたActivityを処理して、フォロー相手の投稿が読めるようになります。
Activityを発行したActorが、フォロワーに対してそれを送信することで、お互いが繋がるネットワークが実現されています。
さて、ここまでサーバが説明されていません。存在感ゼロですね！
実は、ActivityPubでは、サーバーを直接表すActorのような定義がありません。
便宜上、サーバーにもActorを割り当てることはありますが、主役ではありません。
とはいえ、サーバーの存在は別の形で表現されていて、効率の改善に貢献しています。
先程のActor毎のinboxがありましたが、この他にshared_inboxという、同じサーバのActorが共有して使うinboxがあります。
このshared_inboxにActivityを送ると、Activityに指定しておいた宛先のActorに対して、相手サーバーに委託してまとめて送ることができるようになります。
「あなたのサーバの、私のフォロワーに対して、Create - Noteしたのでよろしくね！」という感じで、shared_inboxに一回だけ送れば済む仕組みです。
実際の動きとしては、followersコレクションのActorのshared_inboxを調べ、同じものは一つにまとめてしまい、送信件数を最小限に減らしています。
なお、shared_inboxが無い場合は、個々のinboxに送ります。
@noellabo 「分散型SNS」でありながら、あまりに分散するとsharedの意味がなくなってしんどいだけってのは面白いですね。
@kussy_tessy たとえば外部配送をリレーに全部委託してしまって、自分では手抜きをするノードを作るという発想をすることもできるので、実はいろんなやり方があります。（そういう実装はまだ作られていないと思いますが）
@noellabo なるほど。Aサーバー・Bサーバー・Cサーバーへの配送を請け負うABCリレーサーバーみたいなのを作って、そこに押し付けるということも原理的にはできるってことですね。
配送とはうまく言ったもので、郵便局も同じように近い住所のものは束ねて集配局に送りますもんね。
@kussy_tessy そうです。
B1さんが、自分のフォロワーであるA1さん、A2さん、A3さんの、それぞれのshared_inboxを調べると、同じ宛先表現になっています。
この場合は、まとめて1回で済ませてOKです。
実際、相当な節約になっていますので、この仕組みがないとかなり大変です。