Blueskyの仕組み

 (steveklabnik.com)
2 ポイント 投稿者 GN⁺ 2024-02-26 | 1件のコメント | WhatsAppで共有
  • BlueskyはTwitterやMastodonに似たマイクロブログアプリだが、より大きな目的は AT Protocol（atproto） の上で大規模な分散型ソーシャルアプリケーションが可能かどうかを検証することにある
  • atprotoはブロックチェーン、DAO、NFTではなく、暗号技術や Merkle tree などを活用し、ユーザーが署名した記録をPDS、Relay、App Viewが分担して処理する連合型プロトコルである
  • スケーラビリティは、ユーザーの Personal Data Server（PDS） がすべてのフォロワーへ投稿を直接送るのではなく、Relayがネットワークデータを集約してfirehoseとして提供する構造から生まれる
  • モデレーションは「speech vs reach」モデルに分かれ、コンテンツの複製と露出制御を分離し、labeler、feed generator、App Viewがフィルタリングやブロックを適用する
  • 安定した DID とドメインベースのhandleはアカウントのポータビリティを提供するが、Blueskyが運営する did:plc 解決サービスは中央集権化の論点として残っている

Blueskyとatprotoの関係

  • Blueskyは現在 マイクロブログアプリケーション として動作しているが、全体構想ではAuthenticated Transfer Protocol、つまり atproto の可能性を実証する初期アプリケーションである
  • BlueskyのWebサイトは「ソーシャルメディアは少数の企業が支配するにはあまりに重要であり、誰もが未来を作れるソーシャルインターネットのオープンな基盤を作っている」と述べている
  • Blueskyは企業であるため、「企業が支配すべきでないものを企業が作っている」という懐疑的な見方もあり得るが、設計の核心はアプリよりもatprotoにある
  • atprotoは大規模な分散型ソーシャルアプリケーションのための 連合型プロトコル である

暗号資産ではない分散プロトコル

  • atprotoは「分散ネットワーク」や「プロトコル」という表現のため暗号資産のように見えるかもしれないが、暗号資産ではない
  • ブロックチェーン、DAO、NFTではなく、一部の暗号技術とMerkle treeのような技術だけを使っている

atprotoの基本構造

  • atprotoは複数の主体がシステムの異なる部分を運用し、相互に通信する 連合型構造 を採用している
  • 大規模なユーザーベースを念頭に置き、負荷を担える主体により多くの役割を持たせ、そうでない主体の負担を減らす方向で設計されている
  • Blueskyは執筆時点のその週に 500万ユーザー を超え、初期のTwitterよりはるかに安定していると評価されている
  • 現在のatprotoは 100%公開 ベースであり、非公開メッセージのような機能はない
    • 連合型システムで非公開機能を適切に実装するのは難しいため、重大な注意点を抱えた機能を出すよりも、きちんと実装しようという選択である
    • 今は公開されてもよい内容にだけ使うのが適している

record、repository、App View、Relay

  • ユーザーは暗号学的に署名された record を作り、この署名で作者を証明する
  • recordは Lexicon というスキーマに従う
  • recordは repository に保存され、このリポジトリはHTTPとWebSocketを公開するサービスとして動作する
    • このようなサービスは通常 PDS（Personal Data Server） と呼ばれる
    • ユーザーは自分でPDSを運用することも、他人がホストするPDSを使うこともできる
  • アプリケーションはネットワークに保存されたrecordを読み、その上で機能を作る
    • このようなサービスは特定の情報の見方を公開するため App View と呼ばれる
    • アプリケーションを作るということは、Lexiconを定義し、そのLexiconを使うrecordを読み、それ以外は無視するという方式である
  • PDS同士が直接通知をやり取りする方式はスケーラビリティ上の問題が大きい
    • 新しい投稿を上げるたびにすべてのフォロワーのrepositoryへ直接送らなければならないなら非効率で、人気のあるrepositoryの運用コストが大きくなる
  • Relay はこの問題を減らすためにネットワーク情報を集約し、firehoseとして公開する
    • 実際のApp Viewはrepositoryを直接見るよりもRelayを見る
    • 投稿者が投稿するとrepositoryがRelayに通知し、フォロワーはApp ViewがRelayの出力をフィルタリングした結果を見る
    • Relayは大きく、運用コストも高くなり得るが、特定のユーザーのサブセットだけを伝播する、より小さなRelayも想定できる

「speech vs reach」モデレーションモデル

  • atprotoはソーシャルアプリケーションのためのプロトコルなので、人をつなぐ方法だけでなく つながりを断つ方法 も考慮している
  • Blueskyのモデレーションモデルは speech vs reach に分かれる
    • speech層は、コンテンツを意味内容とは無関係にネットワークへ複製する役割を担う
    • reach層は、ユーザーが見たくないものの到達範囲を制限するツールを提供する
  • Blueskyが「モデレーションをしない」あるいは「自由な発言だけを重視する」という言い方は正確ではない
    • モデレーションツールはプロトコル自体に組み込まれており、Blueskyではないアプリケーションのコンテンツにも機能し得る
    • ユーザーは他人のモデレーション選択やモデレーション不在に従属せず、自分のモデレーターを選べる

Feed generator

  • atprotoではフィードが別サービスである feed generator として分離されている
  • feed generatorはRelayが作ったfirehoseを受け取り、望む基準でコンテンツをフィルタリング・並べ替えして一覧を表示する
  • ユーザーは自分で作ったフィードを他のユーザーと共有できる
  • フィード例:
    • Quiet Posters: 頻繁に投稿しない人たちの投稿を表示する
    • the ‘Gram: 写真が添付された投稿だけを表示する
    • My Bangers: 自分の人気投稿を表示する
  • Blueskyの強みの一つは、ユーザーが自分だけの アルゴリズムフィード を作り、簡単に共有できる点である
  • feedはatprotoに比較的最近追加された機能なので、まだ完全ではない可能性があり、今後変更されることがある

Labelerとネットワークレベルのモデレーション

  • Labeler はコンテンツやアカウントにlabelを付けるサービスである
  • ユーザーは特定のlabelerを購読し、投稿のlabelに応じて体験を変えられる
  • labelerは運営者が望む方式で動作できる
    • 投稿に自動アルゴリズムを走らせられる
    • 人が直接承認・拒否できる
    • ブロックリストやNSFWフィルターとして使える
  • label機能は存在するが、執筆時点でユーザーが直接labelerを実行できるかは不確実である
    • Blueskyは独自のlabelerを運営している
    • 外部リリースについてはまだ知られているものがない
  • feed、App View、labelerを組み合わせると、ユーザーはアプリケーションの内外で モデレーション体験 を選べる
    • あるフィードではSFWだけを見て、別の場所ではNSFWコンテンツを許可できる
    • ブロックリストを作って共有できる
  • モデレーションツールがアプリケーションではなく プロトコルレベル で動作するため、atproto上の他のアプリケーションにも同じlabelerを使える
    • atproto上にInstagramクローンが作られても、同じブロックリストlabelerを使える
    • ある場所でブロックしたユーザーを、望むならすべての場所でブロックできる

Mastodon式インスタンスモデルとの違い

  • atprotoモデルは、Mastodonのように特定の「インスタンス」に「アカウント」がある方式とは異なる
  • 「自分のインスタンスがdefederateされたらどうなるのか」といった質問は、そのまま適用しにくい
  • 特定のPDSから来た投稿が嫌なら無視する、といった形で似た目的を達成することはできる
  • ただしその選択は、サーバー所有者がユーザーのアカウントに代わって決めるものではなく、ユーザー自身の選択 である

DID、handle、アカウントのポータビリティ

  • atprotoのアイデンティティの核心は DID（Decentralized Identifier） である
    • DIDの例は did:plc:3danwc67lo7obz2fmdg6jxcr のような形である
  • ユーザーが実際に見るアイデンティティには handle も併用され、handleはドメイン名である
    • 例: @steveklabnik.com
    • Bluesky加入者は @username.bsky.social 形式のhandleを受け取れる
  • DIDが安定しているため、handleを @steveklabnik.bsky.social から @steveklabnik.com に変えてもフォロワー側に中断は生じず、UI上のhandleだけが変わる
  • ドメインをhandleとして使うには、PDSが生成したDIDを取得し、そのドメインのDNSに TXT record を追加する
  • DNSを知らないユーザーでも、BlueskyとNameCheapの提携により、技術知識なしにドメインを登録してhandleに設定できる
  • アカウントのポータビリティはDIDと暗号学的署名に基づく
    • 特定のDIDを使う人が作ったコンテンツは署名され、ネットワークに複製される
    • 「アカウント」を終了させるには、ユーザーが持つ鍵の使用を強制的に止める必要があるが、ネットワーク設計上、他の主体はその鍵にアクセスしない
    • PDSが落ちても、ネットワークから内容をbackfillし、新しいPDSへ移動したことを知らせられる

did:webとdid:plcの論点

  • Blueskyは2種類のDID方式をサポートする
    • did:web: ドメイン名ベースの方式
    • did:plc: Blueskyが実装した独自方式
  • did:plcのplcは「placeholder」を意味し、Blueskyはこれを継続してサポートする計画である
  • did:plcには、Blueskyが運営するサービスを通じて正しい情報を解決しなければならないという弱点がある
    • 例の照会は plc.directory で可能である
    • この構造のため、Blueskyがネットワーク設計上本来可能な範囲よりも強くユーザーをbanできる、という批判がある
  • この問題を致命的だと見ない理由もある
    • 望まなければ did:web を使える
    • より良いシステムが生まれれば移行できるように設計されている
    • 将来的に did:plc のガバナンスを合意モデルへ移す可能性がある
    • 他の主体が did:plc サービスを運営し、それを使うこともできる

Blueskyがatproto上に載る仕組み

  • Blueskyはatprotoネットワーク上に作られたアプリケーションである
  • BlueskyはApp Viewと、それを使う Webアプリケーション を運営している
  • Webアプリで登録したユーザー向けのPDSも運営し、それらのPDSが通信するRelayも運営している
  • Blueskyは2種類のLexiconを発行している
    • com.atproto.*: ネットワーク上のどのアプリケーションにも必要な低レベル処理
    • app.bsky.*: Blueskyに特化した処理
  • Blueskyのプロダクト目標は、ユーザーがこうした技術的な詳細を知らなくても使えるようにすることである
    • インスタンスがないため、アカウント作成のためにインスタンスを選ぶ流れがない
    • ホストが落ちても移行でき、フォロワーはそれを意識しなくてよい

atproto上で新しいアプリケーションを作る

  • atprotoアプリケーションは Lexicon を作ることから始まる
  • その後、ネットワーク上のデータのうち、そのLexiconに関連するデータを処理するApp Viewを運営する
  • アプリケーションは、ユーザーが自分のPDSにそのLexiconを使ってデータを書き込めるようにする必要がある

設計上の重要な分離

  • atprotoとBlueskyの役割分離は重要な設計要素である
  • Blueskyのような「killer app」は、ネットワークを使う理由を提供する
  • Bluesky自体も、atproto上に実際のアプリケーションを作れるかを検証する dogfooding の役割を果たしている

関連記事

1件のコメント

 
GN⁺ 2024-02-26
Hacker News の意見

  • とてもよく設計されているように見え、ActivityPub の大きな問題の一部を解決しているようだ
    以前は Bluesky に興味がなかったが、今はアカウントを作ってみようと思っている

    • Bluesky と AT Protocol の主な問題は、技術的な利点よりも強い NIH(Not invented here) 的な姿勢にある
      みんなが使う user@host や WebFinger のような既存プロトコルの代わりに「ドメインをアイデンティティとして使う」ことを選び、証明書で ACME がすでに扱っている方法も参考にしなかったため、誰かが s3.amazon.com ドメインを Bluesky 上で取得してしまうことまで起きた https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
      また、新しいリモート呼び出しプロトコル XRPC を作り、protobuf や jsonld と比べて新しいという点以外に利点がはっきりしない、コード生成ベースのデータスキーマ Lexicon も使っている
      他のエコシステムを尊重したり対話したりしようとしない姿勢を見せ続ける「オープンネットワーク」を信頼するのは難しく、共有知識を拒むことで設計にどれほどありふれたミスが入り込んでいるのかも疑わしい
    • AT Protocol は技術的にはより優れて見えるが、社会的には失敗しやすい構造に見える
      実際のコミュニティから切り離されたリレーやモデレーションサービスを、誰かが設置・維持するだけの社会的インセンティブがないため、残るのは有料サービス、広告挿入、データマイニング、情報操作のような金銭的インセンティブだけになる
      データ配信とモデレーションが中央集権化すると、ホスティング費用も人的コストも大きな事業となり、Bluesky 以外の誰かが独自のリレーやモデレーションサービスを運営することを事実上妨げる方向に進む
      ActivityPub の欠点はあっても、「ゲートのあるコミュニティ」のようなアプローチは、ユーザーにサーバーへの帰属意識を持たせ、運営者やモデレーターにユーザーへサービスを提供しているという誇りを持たせる
      AT Protocol は複数のリレーやモデレーションサービスを技術的には許容しているが、現実にどれほど生まれるかは疑問だ
      ソーシャルネットワークのプロトコルを純粋に技術的・敵対的な観点だけで判断するのは間違いだと思う。サーバーに縛られない代わりに、密接なコミュニティからも切り離され、もはや失うものがなくなる
      データ、アイデンティティ、コミュニティの面で失うものがないというのは、諸刃の剣だ

  • 現時点では リレーが 1 つしかないと理解している
    複数のリレーができれば、それぞれがネットワークを異なる形で見るようになり、より多くの投稿を含むリレーのほうが優れたリレーになるだろう
    単一の支配的リレーではなく、リレーの多様性を確保するのはかなり難しいかもしれず、代替 DNS システムが traction を得ようとしている状況に似ているように見える。そうなると、自分の投稿が支配的リレーに拾われなければ打つ手がなさそうだ
    まだかなり初期段階なのでそうならないかもしれないし、支配的なリレーがあったとしても GitHub もそこまで悪くはなく、代替手段も一応ある

    • 以前は Bluesky がかなり分かりにくかったが、最近になって主に 用語のせいで混乱していたのだと気づいた
      このシステムを [マイクロブログ] -> [インデクサー] -> [クライアント] と呼べば、もっと理解しやすい
      実際にはもっと多くの要素があるが、Bluesky の基本的な動作はおおむねこんなもので、名前の付け方だけが予想と違っていたようだ
      インデクサーが必要なのは、ユーザー ID がシステム内で静的に維持されないからだ。DID:PLC がハッシュの部分文字列として始まり、「鍵ローテーション」のために時間の経過とともに、本人も気づかないうちにユーザー ID が変わってしまうという奇妙な暗号学的再配置が起こる
      LiveJournal のようなシステムなのにハンドルが変わり続け、その変化を追跡する権威が必要な状況を想像すればよい。もちろん、タイトルや Markdown 対応はなく、短いメッセージしか投稿できない
      個人的には、静的な公開鍵を受け取り、その秘密鍵でメッセージに署名する新しい DID:PLC を待っている。追跡すべきものがずっと減り、セルフホスティングやローカルファースト開発がずっと容易になるはずだ
    • 必要なら、クライアントである App View は複数のリレーを並列に使えるはずだと思う
      互いに異なるが重複することもある保存リポジトリ群をホストする複数の GitHub インスタンスからデータを取得する、ローカルな GitHub UI のような構造だ
      複数の NNTP サーバーからニュースグループを集めて表示する Usenet クライアントにも似ている
    • すべてのリレーは、違法コンテンツに対する判断の違いを除けば、全データを持つ構造になると予想している
      なぜリレーごとにネットワークの見え方が変わると思うのか気になる

  • 気になるのは、BlueSky がプロトコルのオープンな部分だけを使うと、どうやって信頼できる形で約束できるのかという点だ
    BlueSky は実際かなり中央集権的に見えるので、ファーストパーティクライアントが必ずしも ATProto クライアントである技術的理由はなさそうだ
    短期・中期的には、そうすればユーザーの信頼を大きく裏切ることになるだろうが、ActivityPub の事実上の分散構造のほうが、ここではより強い安全装置に見える

    • ファーストパーティの BlueSky クライアントが何を意味するのか分からない
      ファーストパーティのリレーと PDS が別のプロトコルで通信できる、という意味なら、何を心配しているのかよく分からない
      ActivityPub クライアント 2 つも、ActivityPub ではないプロトコルで互いに会話できる
    • すべてのコードが オープンソースなので信頼できる
      実際にその通りにしているし、もしそうでない方向に変え始めれば、人々はすぐに気づくだろう

  • 「発言」と「到達範囲」を区別するところまで行ったのは良いが、長期的には単純さの点で Mastodon のほうが賢い選択に感じられる
    短期的には、Mastodon のフィード選別のほうが明らかに難しいため、あまり面白くなかったり、あまり有用でなかったりする可能性はある
    核心的な問いは、仮に裕福だったり権力を持っていたりする悪意ある行為者がここで場をかき回したいとしたら、どうやってそれが可能なのかということだ
    記事では「フィードがどう動くのかよく分からない」といった形でこの部分をあまりに雑に流していて、非常に疑わしく感じる。フィードがどう機能するのかをよく分かっていて、そこに権力と金があることも知っているからこそ、それを握ろうとしているように見える

    • 「フィードがどう動くのかよく分からない」という要約は適切ではないように見える
      筆者はこう述べている。「フィードは atproto に最近追加された機能なので、存在はしているが、まだ機能が完成していない可能性があり、今後変わるかもしれない。見守ろう。私の観点ではうまく動いているが、低レベルの技術的詳細までは追っていない。」
      その直前の段落には、こうした文脈もある。「他のマイクロブログツールと比べて、BlueSky のキラー機能の一つは完全なユーザー選択権だ。自分でフィードアルゴリズムを作りたければ作れるし、他の人と簡単に共有できる。」
    • どの部分からフィードの動作方式を知らないという意味になるのか分からない
      フィードはオープンソースで、現に存在しており、自分で実行することもできる
      「場をかき回す」というのが、どの場をどんな意味で言っているのかもはっきりしない。ここには動く部品が多い

  • ユーザーがホスティング提供者とは独立した モデレーション提供者 を選べるなら、インスタンス選びをあまり気にしなくてよくなるというアイデアは魅力的に見える
    ただし、インスタンスは依然として、その地域で違法なコンテンツをホストしないためにモデレーションしなければならないように思える
    結局、インスタンスを運営する人たちにとってはかなり難しい仕事になり、相当な混乱につながりそうだ。私の理解違いかもしれない

    • コンテンツをホストする人は、自分がホストするコンテンツの 法的帰結 に対処しなければならず、結局それは避けられない
      ただ、これはどのプロトコルを使っていても同じだ
    • 誤解ではない。Bluesky の分散化は見せかけに近いと思う
      PDS はそれなりの Ubuntu ボックスで動かせるが、この記事自体ですらリレーが高価で巨大な 中央統制点 であることを認めている
      Bluesky のスパム対策計画は何だろう？ おそらくリレーでブロックする形になるはずだ
      DID サーバーもまた別の中央統制点だ
      それでも PDS 自体は好きに動かせるのだろうが

  • Bluesky に関する面白い豆知識として、少し前の記事とつなげて考えると、これも人名に由来していることになる
    CEO の名前は中国語で文字どおり blue sky だ

    • 面白いことに、Twitter は私が参加する前からすでにプロジェクト名を bluesky にしていた
      偶然だ。ただ、私のミドルネームは中国語で bluesky を意味する

  • この短い漫画も良い: https://bsky.social/about/welcome-to-bluesky-comic

  • Bluesky が did:plc のサポートを打ち切ったら、既存の PLC アイデンティティ は全部壊れてしまうのだろうか？
    PLC はそのサービスに ping を送る構造なので気になる

    • https://plc.directory はミラーでき、そのようなことが起きれば新しいミラーが 権威サーバー になれる

  • サードパーティラベラー には懐疑的だ
    悪用をどう防げるのか？

    • ユーザーはどの サードパーティラベラー を購読するか選ぶ
      ラベラーサービスがその地位を悪用し始めたら、ユーザーが切ればいい
      Bluesky がラベラーをエコシステムにどう組み込もうとしているのかについての詳細な説明は https://github.com/bluesky-social/proposals/tree/main/0002-l... にある
    • どの種類の悪用を指しているかによって答えは変わる
      見解を述べることはできるが、質問が広すぎてどこから答えればいいのか分からない
    • 近いうちにモデレーションについてもっと多くを公開する予定だが、ラベラーの基本はこうだ
      ネットワーク内の誰でも、他のラベラーを含め、何にでもラベル付けできる
      アプリは、現在の Bluesky のカスタムフィードのように、ユーザーが購読するラベラーを提示できる
      アプリは、現在「いいね」と保存で表される人気度に基づいてカスタムフィードを提示し順位付けしているのと同様に、ラベラーがどう提示され、どう順位付けされるかも選別できる

  • 「モデレーションツールはリーチ層に属する。すべての発話を取り込んだうえで、自分が見たくないものの到達範囲を制限する手段を提供する」というアプローチは、結局のところ「見たくなければ目を閉じろ」式のモデレーションに見える。
    Silicon Valleyで好まれる哲学なのは分かるが、根本的に欠陥があると思う。
    特定の事案について、無関係な他人が発言したり特定のコンテンツを入手したりできないようにしなければならない正当な状況がある。
    典型例がサイバーいじめ、個人情報の暴露、リベンジポルノである。2人以上が第三者を傷つける方法を話し合ったり、私的で侮辱的、あるいは虚偽の情報を公開したりするようなケースだ。
    被害者のフィードからこの情報を取り除くのはまったく無意味で、そもそも被害者のフィードには表示されない可能性が高い。被害は、他人がそのコンテンツを見たり議論に参加したりすることから生じるのであって、その被害は現実のものだ。
    従来のモデレーションシステムでは、モデレーターが投稿を全員から削除したり加害者を遮断したりして、このような行為を止められる。「コンテンツを隠すだけ」のシステムでは、これは不可能だ。
    共有ブロックリストや「ラベル」も機能しない。コンテンツ消費者にはそれをブロックする動機がなく、むしろリベンジポルノを見たがる。
    ブロックしたいのは被害者だが、被害者には全員に特定のブロックリストを使わせる力がない。このシステムの核心が、誰も他人にブロックリストを強制できない点にあるからだ。

    • この領域には今後さらに出てくるものがある。この記事では通常のケースに焦点を当てており、悪いケースは扱っていない。
      チームはこうした問題を検討し、「専門家にも相談」しているが、まだ進行中の作業なので自分が語る立場にあるとは感じていない。
      「人々はそれを防ぐより見たがるのでラベルは機能しない」という点は、チームが明示的に認めている問題領域に含まれている。
      追加でこちらを参照: https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei