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

分散型SNSとは?

分散型SNSとは、データの所有権や運営の権限を分散させることで、ユーザーに選択肢を提供するSNSの仕組みです。

中央集権型SNSの問題

XやFacebookのようなSNS(中央集権型SNS)では、ユーザーのデータはそのサービスを提供する企業のサーバーに保存されます。 このような形式のSNSには、世界中の情報を簡単に収集することができるなど、メリットも存在しますが、デメリットも存在します。

中央集権型SNSには、ユーザーに「選択肢」が存在しません。 たとえば、XのAPI有料化などがその一例です。XがAPIを有料化する以前は、サードパーティーのクライアントなどをユーザーが選択する権利がありましたが、Xの一判断によってその権利は失われました。 中央集権型SNSでは、ユーザーはSNSの運営企業という1つの組織の判断に従うしかないのです。

分散型SNSは、SNSの仕組みレベルで「選択肢」を提供します。

選択肢の提供

「選択肢」を仕組みレベルで提供するとは、どういうことでしょうか。

ActivityPub

たとえば、ActivityPubという分散型SNSの仕組みが存在します。 これは、MastodonやMisskeyといった分散型SNSで採用されています。 このSNSは、ユーザーに「所属の選択肢」を提供しました。

ActivityPubは、小さなSNSが「連合」という形でつながり、一つの大きなSNSを構成します。 つまり、今まではそのSNSの運営企業という1つの組織の判断に従う必要がありましたが、ActivityPubではどんな組織・個人の判断に従うか、を選択することができます。

しかし、ActivityPubでは、所属の選択肢がユーザーに与えられましたが、データは依然として所属先のサーバーに存在します。 もちろん自分でサーバーを立てることも可能ですが、大きな一つのサーバーが生まれると、それは実質的に中央集権型SNSのような構造となります。

Nostr

ほかにも、Nostrという分散型SNSの仕組みが存在します。このSNSでは、「所属」という概念そのものを廃止しました。 ユーザーのデータは暗号学的にユーザー自身が署名し、サーバーは単なるデータの中継役に過ぎません。 サーバーがデータを改ざんすることも、サーバーが消えてもユーザーのアイデンティティやデータが失われることもありません。

つまり、Nostrは「誰も信頼しなくてもいい選択肢」を提供したのです。

また、特定のリレーに依存することのないように、複数のサーバーに同じデータを送信して、ユーザーが好きなサーバーから取得する冗長化という仕組みがとられています。 しかし冗長化をすることで、SNSの仕組みレベルで不用意な投稿データのコピーを促すことになります。

ATProtocol

[TODO]

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の構造上このようなケースはあまり考えられませんが、万が一すべてのリレーが停止するような事態に陥ったとしても、新たなユーザーが見つかりにくくなるだけで、既存のつながりやデータの閲覧には一切の支障をきたしません。

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

リポジトリ仕様

polkaのリポジトリは、ATProtocolの仕様に基づいた静的ファイルベースのデータストレージです。

概要

ATProtocolのリポジトリ仕様の詳細は、公式ドキュメントを参照してください。

セルフホストガイド

polkaをセルフホストする手順。ファイルを管理するためのGit RemoteやWebサーバー含めて、すべてセルフホストする方法を説明します。

環境

NixOS 25.05

Setup

polkaをセルフホストするためには、ファイルを公開するWebサーバーなどが必要です。 また、投稿の世代管理などを行うため、Gitのようなバージョン管理ツールを使用することを強く推奨しています。

このガイドでは、Git、Webサーバー、Actionsなどすべての要素をセルフホストする例です。 これらの手順はGitHub、GitHub Pagesのようなプラットフォームでも同じように動作します。適宜読み替えてください。

didの用意

polkaでは、did:webという技術を使って、あなたのドメインをidとすることができます。

DIDとは、Decentralized Identifierの略で、ユーザーが自分のアイデンティティを任意の場所に置くことができる仕組みです。

DIDは

did:method:pointer

という構造になっており、pointerの値を使ってmethodごとの方法で、DID Documentというあなたを表すJSONドキュメントをresolveします。

did:webでは

did:web:example.com

という構造になっており、DID Documentはhttps://example.com/.well-known/did.jsonでアクセス可能である必要があります。

polka CLIでは、DID Documentの生成をサポートします。

まず、polka CLIをセットアップします。

git clone https://github.com/marukun712/polka

nix develop
cd polka/cli
bun i

CLIを起動します。

bun run setup

すると、polkaで使用したいあなたのドメインが尋ねられます。 このドメインはあなたを表すidとなるため、慎重に選択しましょう。

ドメインを入力すると、DID Documentと鍵ペアが生成されます。この鍵ペアはあなたのデータリポジトリ全体を署名するための鍵となるため、漏洩するとアカウントが乗っ取られてしまいます。パスワードと異なり、回復することもできません。厳重に保管しましょう。

デフォルトではOSのKeyringに保存されています。 OSごとのパスワード管理アプリなどからご確認ください。

秘密鍵を保存したら、DID Documentを.well-known/did.jsonにアップロードします。

/var/www/polkaを作成します。

sudo mkdir /var/www/polka

.well-known/did.jsonを作成します。

sudo mkdir /var/www/polka/.well-known
sudo nano /var/www/polka/.well-known/did.json

先ほど表示されたDID Documentをコピーします。

リポジトリファイル保存用のフォルダも作成します。

sudo mkdir /var/www/polka/polka

次に、Caddyを有効にします。 configuration.nixに以下を記述します。

services.caddy = {
  enable = true;
  virtualHosts.":9000".extraConfig = ''
    header Access-Control-Allow-Origin *
    handle /.well-known/* {
      root * /var/www/polka
      file_server
    }
    handle /polka/* {
      root * /var/www/polka
      file_server
    }
    handle {
      respond "This is polka server."
    }
  '';
};

リビルドします。

sudo nixos-rebuild switch --flake .#{flake-name}

ブラウザで、

https://${domain}/.well-known/did.json

にアクセスして、DID Documentが返ってくることを確認します。

確認出来たら、CLIフォルダに.envを作成し、

POLKA_DOMAIN=

環境変数POLKA_DOMAINにドメインを入力します。

Git Remoteの用意

次に、リポジトリを管理するためのGit Remoteを設定します。 このガイドでは、Giteaをセルフホストします。

configuration.nixに以下を記述します。

services.gitea = {
  enable = true;
  package = pkgs.gitea;
  stateDir = "/var/lib/gitea";
  settings.server = {
    DISABLE_SSH = false;
    START_SSH_SERVER = true;
    SSH_LISTEN_PORT = 2222;
    SSH_PORT = 2222;
  };
};

リビルドします。

sudo nixos-rebuild switch --flake .#{flake-name}

localhost:3000にアクセスし、Giteaのセットアップを済ませて、SSH経由で接続できるようにしてください。

セットアップを済ませたら、リポジトリを作成します。

POLKA_MAIN_REMOTE環境変数を、以下のように設定します。

POLKA_MAIN_REMOTE=ssh://gitea@{ip}:2222/{user}/{repo-name}

Actionsの設定

次に、リポジトリへのpush時に自動的に/var/www/polka/polkaにリポジトリファイルがコピーされるように設定します。

Giteaの設定から、Actionsトークンを取得し、保存します。

printf "TOKEN=Your Token" | sudo tee /etc/gitea-runner-token > /dev/null

configuration.nixに以下を記述します。

services.gitea-actions-runner = {
  package = pkgs.gitea-actions-runner;
  instances.default = {
    enable = true;
    name = "runner";
    url = "http://localhost:3000";
    tokenFile = "/etc/gitea-runner-token";
    labels = [ "native:host" ];
  };
};
systemd.services.gitea-runner-default.serviceConfig.ReadWritePaths = [ "/var/www/polka" ];

GiteaのAction設定からランナーが見えたら、リポジトリに.gitea/workflows/deploy.yaml を作成し、以下を記述します

name: Deploy Files
on: [push]

jobs:
  deploy:
    runs-on: native
    steps:
      - name: Check out code
        uses: actions/checkout@v3
      - name: Copy files
        run: |
          echo "Deploying..."
          rm -rf /var/www/polka/polka/dist/
          cp -r polka/dist/ /var/www/polka/polka/
          echo "Done!"

runnerがディレクトリに書き込めるようにします。

sudo chown -R gitea-runner:gitea-runner /var/www/polka

これで、push時に自動的にCaddyでリポジトリファイルが公開されます。

ユーザー情報の入力

CLIを起動します。

bun run setup

ユーザー情報の入力を求められます。これらは必須となっているので、入力しましょう。

  • name
  • description
  • iconのURL

デスクトップアプリの起動

次に、デスクトップアプリから投稿をしてみましょう。

アプリをセットアップします。

cd desktop
bun i
bun run build
bun run start

すると、デスクトップアプリが起動します。 入力フォームで使用しているドメインを尋ねられるので、セットアップ時に入力したものと同じドメインを入力してください。

自分のプロフィールが表示されたらセットアップは完了です！