他プロトコルとの比較

ActivityPub

Push vs Pull

ActivitypubとConcrntとの大きな違いは、ActivityPubがプッシュ型のプロトコルであるのに対して、Concrntはプル型のプロトコルであるということです。

Activitypubでは、あるサーバーのユーザーが新しい投稿を行ったとき、そのサーバーはその投稿をフォロワーのサーバーに配送します。

これはシンプルな仕組みである一方、受信サーバーのユーザーがもうそのサービスを利用していない場合でも、投稿は送り続ける必要があるという問題があります。 また、送り先サーバーがダウンしている場合、送信元サーバーはそのサーバーが復旧するまで投稿を保留し、サーバーが復帰した際に再送信を行う必要がありますが、 これは復活直後のサーバーが高負荷に陥る原因にもなりますし、また送信元サーバーとしても配送ジョブを保持し続けるのはコストがかかります。

一方Concrntはプル型のプロトコルであり、ユーザーがタイムラインを読む際に、そのサーバーががほかのサーバーからデータを取得します。

この方法は、リクエストからユーザーにレスポンスを返すまでの時間が長くなるという欠点がありますが、Concrntでは高度なキャッシュ戦略により、この問題を緩和しています(あくまでも遅くなるのは事実です)。 ただプル型にすることで、自身のサーバーがダウンしていもほかのサーバーに迷惑をかけることがないという利点があります。ユーザーがサービスを利用してない間、なんのリクエストも発生しないため、効率的です。

リアルタイム性

Activitypubでは、push型であるため自然とリアルタイム性が獲得されます。

Concrntは基本的にPull型であるため、そのままではリアルタイム性が失われてしまいます。ほかのサーバーで投稿が発生したときに、それをすぐに検知することができません。 そのためConcrntでは、ユーザーがリアルタイムを要求した場合には、サーバー間にその情報を配信するためのwebsocketのコネクションが確率されます。

これにより、ConcrntはPull型のプロトコルでありながら、リアルタイム性を確保しています。

IDの扱いと引っ越し

ActivityPubでは、ユーザーのIDはそのサーバーのドメイン名を含む名前で表現されます。例えば、@[email protected]のようになります。 そのため、ほかのサーバーに引っ越すときにはIDも変わってしまいます。また、投稿などはそのまま引っ越すことができません。投稿を指し示すURLが変わってしまうためです。

(※ActivityPubでも、解決を転送するサーバーを用意するなどの方法でIDを維持することも可能ですが、現在のところあまり一般的にはなっていないようです。)

また、IDがドメイン名を含むということは、ドメイン名の持ち主がそのIDの生死を握っていることでもあります。ドメインの持ち主がIDをBANした場合、それは覆せません。 しかし、IDがドメインの持ち主の管理下であるということは悪いことだけではありません。裏を返せば、自分がパスワードを紛失してしまっても、メールアドレスや任意の本人確認の方法を使ってドメインの管理者によしなに復旧してもらえる可能性があるというメリットもあります。

Concrntでは、ユーザーのIDはユーザーの持つ「マスターキー」から生成される「CCID」によって表現されます。(例えば、con1t0tey8uxhkqkd4wcp4hd4jedt7f0vfhk29xdd2)

このIDは長く、人間が覚えるのは難しいという問題がありますが、これによってサーバーを引っ越してもIDが変わらず、またフォロー関係・投稿・リアクションなどすべてがそのまま引っ越し可能になります。

また、CCIDそのものは長くても、後述するBlueskyのようにドメイン名を使ってこのIDを短く表現することも可能です。

しかし、Concrntは「ユーザーが責任を持ってIDを管理する」という方法を取っているため、ユーザーが「マスターキー」を無くしてしまったり、他人に知られてしまった場合、そのアカウントは復旧することができません。Concrntでは「サブキー」というものを使い、マスターキーを使わなければならない場面を減らしてはいるものの、それでもマスターキーの重要性は変わりません。

AT Protocol (Bluesky)

Blueskyは次の図のような構成を取っています。

PDSにデータを書き込むと、Relayが新着データを受け取り、AppViewへと転送します。AppViewがいわゆる「サービス」であり、Blueskyと呼ばれる部分もここに当たります。

PDSやRelayは複数増やせますが、AppViewはほとんどのケースで1つだけです。これにより効率的に「全世界の」データを処理し、非常に多くのユーザーに提供することを可能にしています。

Blueskyを利用して、フォロワーの発言を見る場合、このようなデータの流れになります。

※厳密には、自身のPDSを介してAppViewのデータを取得する場合もありますが、ここでは省略します。

この手法のデメリットは、BlueskyがあなたのアカウントをBanした場合、残されるのはPDSに保存されたデータだけです。これは引っ越しても、BlueskyからBanされていることには変わらないため、別にBlueskyのフォロワーに投稿が引き続き表示されることはなく、「Blueskyとは別の」AppViewから見ることができるというだけです。

ConcrntはBlueskyとは構成が異なり、全てのサーバーが対等な関係を持っています。

この方式ではBlueskyのように全世界のデータを処理し、トレンドなどを把握することは難しいです。ですが、フォロワーとの繋がりを維持するために大企業へ依存する必要がなくなります。

nostr

nostrはConcrntと同じくプルかつwebsocketによるリアルタイム性を持つプロトコルです。 サーバーはリレーと呼ばれていて、ユーザーは複数のリレーに接続し、自分の投稿を同時に投稿したり、また複数のリレーからデータを取得し合成します。

これにより、1つのサーバーがダウンしても、継続してサービスを利用することができます。

一方で、違法性のある投稿が行われた場合、その投稿を取り除くためには、すべてのリレーにその情報を送信する必要があります。リレーの運用者は知らない人物の投稿を取り除くことになるため、運用が難しくなります。

Concrntでは、1ユーザーは1つのサーバーに所属し、そのサーバーからコンテンツを配信します。 この方法では自身が所属しているサーバーがダウンしている間は利用ができなくなりますが、違法性のある投稿を取り除く際には、そのサーバーに対してのみ対応すればよく、運用が容易です。 またこうした形式を取ることで、サーバー運用者はユーザーと利用規約による契約を結ぶことができ、法律に基づいた対応を行うことができます。

また、nostrでは全ての情報がパブリックであり、隠すためには暗号化を施したり、ほかの認証の仕組みを導入する必要がありますが、Concrntではデータが一か所にしか存在しないため、データの公開範囲を簡単にコントロールすることができます。