Concrnt Square

Concrnt Squareは分散型SNS「Concrnt(コンカレント)」の始め方からサーバー運用方法、開発ノウハウまで、様々な情報を集約しているサイトです。

コンカレントとは

コンカレントは、全く新しいタイプの分散型SNS基盤です。この基盤を利用したアプリケーションとして concrnt.worldがサービスされています。

分散型SNSと一言に言ってもその形態は様々ですが、コンカレントはその中でも「誰でもサーバーを建てられる一方で、どのサーバーを利用していても得られる体験がほぼほぼ同じである」分散型を指向しています。

目指しているゴールが既存のSNSとは異なるため、その実現のために独自のプロトコルを用いてコンカレントのサーバー同士は通信を行います。 ほかのSNSとの連携は、モジュールをサーバーに組み込むことでオプションでActivitypub等のプロトコルとの連携が可能です。

コンカレントが目指すゴール

1. インターネット上での「安全なホーム」を提供すること

近年の情報化社会では、「ここに行けばこの人の最新の情報が見れる」というような「ホーム」が必要不可欠でしょう。突然奪われたりしない、安全なホームが。

自分のアカウントを、自分が選んだ国・運営者の元に作成することができる

コンカレントは分散型SNSです。誰でもサーバーを建て、提供することができます。 自分でサーバーを建てられない人も、自分で「管理される」サーバーを選ぶことができます。

自分のアカウントが第三者によって削除・凍結され、回復不能にならない

SNSアカウントが個々人の「ウェブ上での家」であり、ポートフォリオにもなる現代において、自分のアカウントが第三者の意思にのみによって凍結ないしは削除されることはあってはなりません。

中央集権型のSNSや、自身の識別子がサービスのドメイン名に紐づく大部分のActivitypubサービスでは、サービスの運営によって識別子を失ってしまう・無効化されてしまう可能性があります。

コンカレントは、nostr等と同じく「秘密鍵を用いた電子署名」を用いる方法でこれを克服しています。 ユーザーは秘密鍵により自分の投稿を署名し、サーバーに投稿します。 閲覧者はサーバーから受け取ったメッセージの署名を検証することで、それが本当にあなたによって発信されたメッセージであることを確認することができます。

アカウントを自由にほかのサーバーへ引っ越しすることができる

コンカレントでは、ユーザーがリクエストしたDBの変更リクエストがすべてログとして保存されています。このログを他のサーバーに持ち出し、「引っ越し届」を世界に発信することで、あなたのアカウントをいつでも別のサーバーに引っ越すことができます。(変更が世界に一瞬で反映されるわけではなく、しばらく所在不明になる期間もありますが、いずれ収束します)

また、このログデータについてもユーザーがいつでも手動でダウンロードできる上、今後はGoogleDriveやその他ストレージサービスと連携するモジュールを用意し、定期的に保存される仕組みを提供する予定です。

過去の自分の投稿を消去することができる

多くの分散型SNSでは投稿を関連サーバーに転送し、コピーを保管しているため、投稿が削除できないケースが存在します。 コンカレントでは、他のサーバーのメッセージの本文を一切保存しません(利用の監査のため、ログに残るケースはあります)。 他のサーバーに保管されるのはそのメッセージへの「リンク」のみであり、実際にメッセージ本文はそのタイムラインを読みたいユーザー自身がその外部サーバーにアクセスしにいく方式を取っています。 これにより、自分のサーバー上で投稿を削除すれば、他人がその投稿を閲覧することはできなくなります。

繋がりたい人と繋がるのに必要な依存が最低限である

at-protocolないしBlueskyはデータベースのみ分散していますが、依然としてそれを集約し、アプリで表示してくれるサーバー群の管理は中央集権的です。 これにより、at-protocol上でユーザーを完全にbanすることができなくても、blueskyのサービス上でユーザーをbanすることは依然として可能です。

コンカレントはサーバーにデータベースとしての機能も、SNSとしての機能もオールインワンで提供されており、その体験が外部の政治に影響されることはありません。

2. 人と人とのコミュニケーションを支援すること

せっかくインターネットをやるのであれば、楽しくやりたいですよね。

友達が「今、なにしてる？」のかをリアルタイムで知ることができる

タイムラインはウソみたいなXのホームではなく、コンカレはタイムラインで投稿を「時系列順」に並べ、またリクエストすれば新着メッセージをリアルタイムで受信するAPIを提供しています。

自分の投稿の可視性を相手によってコントロールすることができる(鍵垢)

コンカレントはSNSの中でも情報発信・情報収集が主目的である「ソーシャルメディア」は指向しておらず、「コミュニケーションツール」を指向しています。 そのため、Twitterの鍵垢のように「特定のユーザーにのみ」自分の投稿を見せたいといったユースケースがあることを尊重しています。

コンカレントでは強力な「ポリシー」機能により、自分の投稿を見る人が誰なのか、細かく制御することができます。 また、メッセージの本文は他のサーバーに保管されず、許可されたユーザーが直接問い合わせに来るため、外部のサーバー管理者に投稿内容を盗み見られることもありません。

人間にとって自然な「複数のコミュニティに所属した状態」を表現できる

これはコンカレント基盤のゴールというよりは、サービスの1つである"concrnt.world"のゴールであると言えます。

concrnt.worldではソーシャルメディアではなくコミュニケーションツールを目指しています。従来のツールは同時に1つのコミュニティにしか情報発信できませんでしたが、concrnt.worldでは複数のコミュニティに同時に投稿することができます。 また、人をフォローするのではなく、コミュニティをフォローすることで、そのコミュニティに所属する人の投稿を見ることができます。

人間は複数のコミュニティに所属していることが自然であり、そのような状態を表現できるツールがあることは、人間のコミュニケーションにとって非常に重要です。

また、すべての投稿は自分のプロフィールで確認することができ(非掲載にすることもできます)、コミュニティへの発信も自分のポートフォリオの一部として残すことができます。

3. これが持続可能であること

どんなに素晴らしくても、すぐに廃れてしまえば意味がありません。

どのサーバーに所属していても、同じような体験を得ることができる

集中したサービスはその運営方針により多くのユーザーが影響を受けてしまいます。機能が持続可能であるためには、そのサービスが分散されることが望ましいです。

コンカレントでは独自のプロトコルを使うことで、すべてのサーバーで得られる体験が同じになるようにします。分散する直接的なインセンティブはないものの、集中するインセンティブも大してない状態を維持します。

簡単に安全にサードパーティアプリと連携できる

秘密鍵は他人にバレてしまえば一巻の終わりであり、そのアカウントの安全性を取り戻すことはできません。そこで、コンカレントでは「サブキー」という仕組みを導入しています。これは秘密鍵や、有効な他のサブキーから派生させて作ることのできる鍵です。この鍵は秘密鍵の代わりとして認証でき、またいつでも他のまだ有効な鍵を利用してその効力を停止させることができます。 これにより、本体である秘密鍵は金庫などの安全な箇所に保管し門外不出にしたうえで、サブキーを用いてコンカレントを利用することができます。 信頼度が未知数であるサードパーティーアプリに関しても、サブキーのみを渡すことで比較的安全に利用することができます。

また、クライアントアプリではなくユーザーの代わりにカレントを投稿する程度であれば、サブキーを使うまでもありません。 ユーザーのホームタイムラインの書き込み権限は、鍵垢を実現しているポリシー機能と同様の機能で実現されています。 ホームタイムラインのポリシーを編集し、連携アプリのBotユーザーが書き込めるように許可をすれば、それだけで外部ユーザーに自分のタイムラインへの書き込みを許可することができます。また、その際のbotアカウントのアイコンに関しても、サブプロフィールという仕組みを使うことで、一時的に他のユーザーのプロフィール画像を借りることが可能なので、実用上問題ない見た目で、安全にこの許可を与えることが可能です。

サーバーの維持・管理がそれほど大変ではない

誰でも簡単にサーバーを建て、それを維持できるようにするため、次のような特徴を持っています。

a. 使いたい機能だけを組み込むモジュラーな構造

コンカレントはマイクロサービスのような構造を持っており、必要な機能だけを組み込んで有効にすることができます。 例えば、ストレージ機能を使わない場合は、ストレージモジュールを有効にする必要はありません。代わりに、そのサーバーの利用者はimgurなどの外部サービスを利用することができます。

他にもActivitypub等のほかプロトコルとの連携もモジュール化されています。詳しくは モジュールを参照してください。

b. 配送を行うPush型ではなく、必要な時だけデータを取得するPull型

また、外部への投稿の配送も行わないため、休止サーバーに対して配信を停止する等のオペレーションが不要です。 ユーザーがタイムラインを閲覧したときに、効率的なタイムライン構築リクエストが関連するサーバーに送信され、オンデマンドに構築されます。 これは、リアルタイムAPIと連携した高度なキャッシュ機構によって実現されています。

そのため、コンカレントは外部のユーザーの投稿を一切DBに保存しないので、DBの膨れ上がるスピードが緩やかです。

また、リアルタイム通信は、それがリクエストされている間のみセッションが作成され、誰も自分のサーバーの情報を参照していない時間帯は、サーバーは一切の処理を行いません。

Activitypubのような運用性のクセを最低限に、運用しやすいプロトコルになっています。

その他より多くの持続性の為の取り組みは、現在も活発に策定が行われています。

コンカレントがゴールとしていないこと

コンカレントは、上記のゴールを達成するために集中します。そのため、以下のような機能はコンカレントがその内部の機能として提供する予定がありません。

いわゆる個人が情報を「拡散」したり、世界中のトレンドを収集したりする為のソーシャルメディア・プラットフォームになること

コンカレントはあくまでも「人と人とのコミュニケーションを支援すること」「インターネット上での安全なホームを提供すること」を目指しています。

なので、以下の項目は、コンカレントが「本体として」提供する予定がないものになります。 但し、ここにあるものでも「外部サービスとして」提供することを否定するものではありません。むしろ、コンカレントは外部サービスとの連携を推奨しています。

• 世界中の情報を横断して検索できる機能
• リコメンド(おすすめ)機能
• トレンド機能

耐検閲性の担保

コンカレントはその性質から、自然と中央集権的なサービスよりも耐検閲性が強くはなりますが、それが目的ではありません。

適切なコミュニケーションとその維持のためには、適切なモデレーションが必要になるでしょう。コンカレントは自由と検閲の適切なバランスを取ることを重要視しています。

コンカレントの問題点

IDの解決の複雑さ

コンカレントは、ある瞬間において、ユーザーは1つのサーバーに所属しているという状態を持ちます。 あるIDのユーザーの投稿を見たい場合は、まずそのIDが所属するサーバーを見つけ、そのサーバーに問い合わせる必要があります。 ここで、IDからサーバーをどのように解決すればよいでしょうか？

Blueskyはdid:plcという(一時的に)中央集権的な解決専用のサービスを作成ており、それを利用しています。 一方でコンカレントでは、そのような中央集権的な解決サービスを使う代わりに、「それぞれのサーバーが必要なだけのアドレス帳を持つ」という方法を取っています。

具体的には「このユーザーの投稿はこのサーバーのタイムラインから取得したものだから、そのサーバーがユーザーの正しい住所を知っているはずだ」という仮定をはじめ、いくつかの戦略を組み合わせて、IDの解決を行っています。

工夫することで通常利用には問題にならない程度にアドレスの解決が可能ですが、ただほかのユーザーにIDだけを渡した場合、解決できないことがあります。

対処法としては、IDといっしょに現住所を渡してあげるか、ドメイン名によるエイリアスを利用することです。

実際にコンカレントの正規IDは40文字と長い為、IDだけを空で渡すことはあまりなく、QRコードやURLを使うことが一般的になるので、それほど致命的な問題にはならないでしょう。

ドメイン名によるエイリアスは、ユーザーが所有しているドメイン名を使って、そのドメイン名をIDの代わりに使うことができる機能です。 これを利用する場合は、txtレコードに現住所や、それを解決可能なサーバーを指定することでドメイン名だけでサーバーの解決が可能になります。

可用性に関する問題

コンカレントはユーザーは1つのサーバーに所有し、投稿等は簡単さ、プライバシーのために他のサーバーに複製されないため、管轄サーバーがダウンしてしまうと、そのユーザーの投稿は見ることができなくなります。

スケーリング性

コンカレントはゴールとして「複数のコミュニティに所属した状態」を表現することを目指しているため、Xのように膨大なユーザーを同時にフォローするといったことは目標としていません。 設計として高々3000人程度のユーザー・コミュニティを一度にリストに入れてタイムラインを表示することを想定しています。

そのため、非常に多くのユーザーをフォローする(リストに入れる)と、タイムラインの表示に時間がかかるようになるでしょう。これはコンカレントが常にオンデマンドでタイムラインを構築する方式を取っているためです。 それでも、キャッシュ機構が存在するため、同じサーバーを利用しているほかのユーザーが一度でもタイムラインを表示した場合、ほかユーザーはそのキャッシュを利用してタイムラインを表示することができます。

そもそも、3000人以上フォローしていた場合、その全員とのコミュニケーションを取ることは難しいでしょう。また、一見少ないように見えても、個々人をフォローするのではなくコミュニティをフォローすることで、より多くの人をフォローしたのと同じような体験を得ることができます。