Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

What is polka?

polkaは、ATProtocolをベースとした、新たな分散型SNSの形です。 ATProtocolは、Twitter規模のグローバルSNSを実現するための設計がされています。しかし、その設計は「大規模Relayの存在」を前提としており、より小規模な、あるいは異なる用途には必ずしも適していません。 polkaは、ATProtocolをベースとしながら、大規模Relayに依存しない新たな活用方法を提案します。

データの配信

polkaでは、Webの基本に立ち返り、自分のサーバーでファイルを公開する、という操作を基本とします。 ATProtocolのリポジトリを、そのまま静的なBlockファイル群としてexport、HTTPで配信することで、必要なブロックをオンデマンドで取得することができます。

この構造の最大の利点は、データのポータビリティと、データを乗せるインフラの選択肢を大幅に広げることができる点です。 polkaのリポジトリはただの静的ファイルであるため、自分のWebサーバー、静的ファイルホスティングサービス、クラウドストレージなど、さまざまなインフラで配信することができ、そのインフラが信頼できなくなったとしてもデータをコピーして配信先URLを変更するだけですぐに移行することができます。

ATProtocolのリポジトリの性質を活用し、同じ公開鍵で検証できるため、データ所有者の同一性も検証することができます。 また、Gitでの管理も容易で、複数のRemoteを設定することで簡単にバックアップを取ることができます。

アイデンティティ

[TODO]

現在、did:webとdid:plcのどちらを採用すべきか検討中です。

did:webはドメインベースで鍵を完全に管理できますが、 Blueskyとの互換性がありません。

did:plcはBlueskyとアイデンティティを共有できますが、 標準的な運用では鍵管理をPLCディレクトリに委ねることになります。

polkaの理念である「完全な自己主権データ」と、 既存ネットワークとの互換性をどう両立させるか、 引き続き検討を進めています。

SNSとしての特徴

polkaは、大規模なRelayに依存しない仕組みを採用する代わりに、ネットワーク全体での投稿の集計機能を持たない設計となっています。

従来のSNSでは、「すべての投稿を一箇所に集めて検索可能にする」ために、強力な中央サーバーが必要でした。これが「集計」です。 一方、polkaは全体の集計を諦める代わりに、自分が興味のある人やトピックを直接購読する「配信」の仕組みに特化しました。

これは、ATProtocolが中央集権的なRelayを必要とした最大の要因である 「集計と配信のトレードオフ」に対するpolkaなりの回答です。

グラフ構造

polkaにおける情報の構造化は、タグによる階層構造を軸としています。すべての投稿はいずれかのタグに紐づけられ、整理されます。

この構造の最大の利点は、従来の「ユーザーそのものをフォローする」という関係性から脱却できる点にあります。polkaでは、あるユーザーが持つ特定のタグ階層のみを自分のグラフに組み込み、購読することが可能です。これにより、「特定の人物の、特定の話題だけを追いかける」というより効率的な情報収集が実現します。

ユーザーが自身のストレージでデータを公開し、そのDIDを共有している相手であれば、この仕組みを通じて自由に閲覧が可能です。しかし、Relayによる全データの集約を行わない以上、「どのようにして新しいユーザーを発見するか」という課題が残ります。

ユーザー発見

この発見における課題を解決するため、polkaでは補助的なネットワークとしてNostrを活用します。

ただし、Nostrのリレーに対して投稿内容や実データそのものを流すことはしません。リレーに送信されるのは、自身の興味関心や活動の傾向を示す、いわば「ユーザーの雰囲気」に限定されます。

このデータを受け取った他のユーザーのクライアント上では、自分と親和性の高いタグを持つユーザーのアイコンが、対応するタグの周辺に可視化されます。これにより、自分と近いグラフ構造を持つ他者を直感的に見つけ出すことが可能になります。

このNostrを用いた仕組みは、あくまで「発見」のための手段に過ぎません。Nostrの構造上このようなケースはあまり考えられませんが、万が一すべてのリレーが停止するような事態に陥ったとしても、新たなユーザーが見つかりにくくなるだけで、既存のつながりやデータの閲覧には一切の支障をきたしません。

データの実体は常にユーザー自身が管理するストレージに存在し、特定のインフラに依存しない独立性が担保されているからです。