Bluesky 公式クライアント開発リーダーの Paul の、以前作成してた p2p プロジェクトについて振り返り

#

Paul とは

#

• Bluesky 公式クライアント開発チームのリーダー
  • Paul Frazee (hackfluencer arc) 🦋 @pfrazee.com

Paul の突然の昔語りのスレッド

#

2024年03月03日 05:52(JST) から、Paul が自分が以前開発していた p2p システムについての話を始めました。

珍しく、かなり長い2分割のスレッドになりました。

内容を読んでみると、前半のスレッドは、以前開発していた beaker という クライアント p2p システムを、以下に考えて、魅力的だと思い開発していたか、後半は、なぜうまくいかなかったのかの分析でした。

スレッドは長いですが、テキストは長くなく、簡潔に書かれています。前半の beaker の機能についてのスレッドは、スクショも多めなので、一読してみてください。

スレッドの勝手訳

#

Paul が beaker プロジェクトの失敗で何を学び、それが今の Bluesky のシステム設計にどう生かされているかが書かれているので、テキストの部分のみ、勝手訳をしてみました。

2024/03/03 Paul の昔話

#

• 2024年3月3日 5:52

prior to bluesky I worked on a p2p web browser called beaker, and I figure it might be fun to do a mini retrospective on the architecture

#software

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 5:52

ブルースカイの前に、私はbeaker という p2p ウェブブラウザに取り組んでいました。そのことを取り上げて、アーキテクチャについてのミニ回顧展をするのは楽しいかもしれないと思います

• 2024年3月3日 5:53

the basic idea of beaker was that it added a p2p hypermedia filesystem called Hyperdrive (originally Dat)

you could use that to create networked websites, file bundles, code modules, apps, etc - that you hosted from your device

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 5:53

beakerの基本的な考え方は、Hyperdrive（おおもとはDat）と呼ばれる p2p ハイパーメディアファイルシステムを追加したことでした

これを使って、あなたのデバイスからホストして、ネットワーク化されたウェブサイトやファイルバンドル、コードモジュール、アプリケーションなど様々なものを作成できます。

• 2024年3月3日 5:56

it had some crazy power-user appeal (this project was basically a personal 5 year nerd snipe)

you could explore the files of any hyperdrive, and fork a drive that you navigated to

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 5:55

beakerは、何名かのクレイジーなパワーユーザーを引きつけることができました(このプロジェクトは基本的に個人的な5年間のオタクスナイプでした)

任意のハイパードライブのファイルを探索できます, そして、あなたが見つけたドライブをフォークできます

• 2024年3月3日 5:57

actually, because I'm a madman, it had a terminal interface too

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 5:57

実際、私は気違いなので、ターミナルインターフェースもありました

• 2024年3月3日 5:58

actually, because I'm a madman, it had an entire paned windows gui

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 5:58

実は、私は気違いなので、ペーンの中にWindow GUIが丸ごとありました

• 2024年3月3日 5:59

actually, because I'm a madman, it had a web api for driving the paned interface

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 5:59

実際、私は気違いなので、パネル化されたインターフェイスを駆動するためのウェブapiを持ってました

• 2024年3月3日 6:00

some of the really interesting capabilities came from a web api for reading and writing hyperdrive files

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 6:00

本当に面白い機能のいくつかは、ハイパードライブ・ファイルを読み書きするためのウェブAPIから来ました

• 2024年3月3日 6:02

you could actually write websites that self-modified, like this wiki app

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 6:02

実際にこのウィキアプリのように、自己修正したウェブサイトを書くことができます

• 2024年3月3日 6:03

in various versions, there were templates you could start from (or create and share)

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 6:03

さまざまなバージョンの、開始・実行できる（または作成して共有できる）テンプレートがありました

• 2024年3月3日 6:05

hyperdrive had a concept of symlinks that could span hyperdrives, which actually made for a very interesting code-publishing and importing mechanic

on the left screenshot, "profile" was a link

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 6:05

ハイパードライブには、ハイパードライブにまたがるシンボリックリンクの概念があり、実際に非常に興味深いコードパブリッシングとインポートメカニックになりました

左のスクリーンショットでは、「プロフィール」はリンクです

• 2024年3月3日 6:07

one of the most powerful APIs was a filesystem querying interface

with the symlinks, you were able to create some pretty interesting compositional systems. in this snippet here, I'm aggregating all the public files from me and my symlined friends' drives

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 6:07

最も強力なAPIの1つは、ファイルシステムのクエリインターフェイスでした。シンボリックリンクを使用すると、非常に興味深い構成システムを作成することができました。

このスニペットでは、私とシンボリック化された友人のドライブからのすべての公開ファイルを集めることができます

• 2024年3月3日 6:08

we introduced a .view file format which was one of those queries, and would show the results of those queries like a virtual folder

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 6:08

それらのクエリの 1 つである .view ファイル形式を導入しました。そしてクエリの結果を仮想フォルダーのように表示します

• 2024年3月3日 6:11

you could use these queries as the backend for p2p social applications. you'd publish records as files and then query the filesystems for data. a hyperdrive was a user

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 6:11

これらのクエリは、p2pソーシャルアプリケーションのバックエンドとして使用できます。レコードをファイルとして公開してから、ファイルシステムにデータを照会します。ハイパードライブはユーザーでした

• 2024年3月3日 6:12

to help with collaboration, we started to introduce plan9 style layered filesystems and in-app PRs

[image or embed]

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 6:12

コラボレーションを支援するために、プラン9スタイルのレイヤードファイルシステムと、アプリ内PullRequestを導入し始めました

• 2024年3月3日 6:12

so why didn't Beaker work out?

this thread has already gotten long, so I'm going to quote the top post and start separately

— Paul Frazee 🦋 (@pfrazee.com) Mar 3, 2024 at 6:12

さて、なぜbeakerはうまくいかなかったのでしょうか？

このスレッドはすでに長くなっているので、最初の投稿を引用して別々に始めることにします

2024/03/03 Paul の昔話 Part2

#

スレッド変えて、今度はなぜうまくいかなかったのかを、ポストしていっています。

• 2024年3月3日 6:13 なぜbeakerはうまくいかなかったのでしょうか？

• 2024年3月3日 6:15 私たちが苦労した問題には、本質的に2つのカテゴリーがありました

  1. 技術的な制限、および
  2. pmf (訳注：プロダクトマーケットフィット（PMF）とは、商品やサービスが市場に適切に受け入れてられている状態を指す言葉です)

• 2024年3月3日 6:16 これら 2 つの問題は互いに影響し合います。技術的な制限により、私たちができることが実際に制限されていたためです

  元のスレッドで私が列挙したものはすべて、簡単に実現できる成果でした。そこには見えていないものは、大量のマスマーケットのユースケースです

• 2024年3月3日 6:17 技術的な限界はさまざまでした。p2p プロトコルは斬新でした。それはほとんど十分に信頼できるものではありませんでした。常に壊れ続けています。ウェブサイトが読み込まれません。プロトコルエンジニアは優秀でした、そして素晴らしいです。しかし、P2Pは本当に本当に難しい、アプリケーション側からの要求に応えるのが困難でした

• 2024年3月3日 6:17 モバイル（まったく）の話はなく、デバイスのペアリングは完全に未解決でした。コアデータモデルには、マルチデバイスまたはマルチユーザーコラボレーションから説明する方法がありませんでした。P2pソフトウェアは、デーモンとしてバックグラウンドで実行しなければならず、論理よりも多くのリソースを取りました

• 2024年3月3日 6:19 アプリケーションの構築を始めたとき、規模と検出の問題に真っ向からぶつかりました。ほとんどの現代のインターネットアプリケーションは10000人未満ではありませんが、データネットワークとしてはそれ以上の規模にはならず、率直に言ってそれは寛大な数字です。

• 2024年3月3日 6:20 私たちは、サーバーを介さずに検索や発見を行う良い答えを一度も持っていませんでした（通知や見知らぬ人からのコメントなどを配信することは言うまでもありません）。そして、純粋なP2Pがこのシステムの価値の核心であると感じていたため、サーバーを介さないことに非常に固執していました。

• 2024年3月3日 6:21 プログラミングモデルは信じられないほどクールでエレガントでしたが、最も単純なアプリケーションでさえ実装が難しくなり、ある時点で私は「コメントセクションを実装するのはロケット科学であるべきではない」と声に出して言いました。その時、私たちは困った状況に陥っていることに気づきました。

• 2024年3月3日 6時22分 その後の出来事については、この投稿 www.pfrazee.com/blog/why-not… でもう少し詳しく読むことができますが、私は基本的に「サーバー上の P2P 技術」にシフトし始め、ctzn で働き始め、最終的に Bluesky で働くことになりました。 (訳注：ctzn は CTZN というソーシャルネットワーププロジェクト Building in the Open - Paul Frazee - Medium)

• 2024年3月3日 6時25分 ブルースカイチームはP2P分野のさまざまなプロジェクトから参加しており、全員が独立して同じ結論に達しました。プルベースのP2Pデータモデルの核となるアイデアは本当に優れていますが、クライアントではなくサーバー層で実行する必要があります。

• 2024年3月3日 6時25分 以上、私の小さなビーカーの歴史でした

以下、Paul のブログ記事の翻訳です

#

元記事 Why isn’t Bluesky a peer-to-peer network Paul’s Dev Notes

Bluesky はなぜピアツーピア ネットワークではないのですか? | ポールの開発ノート

#

Bluesky での意思決定についていくつかのメモを書き留めておくことをお勧めします。これらのメモは広範囲にわたるものではありません。

このシリーズでも:

• なぜ AT プロトコルで RDF を使用しないのでしょうか?
• Bluesky でリッチテキスト ファセットを使用する理由

2014 世代の P2P

#

2014 年の NodeJS および Web コミュニティでは、インディーズ ハッカーの精神が強かった。CouchDB と CouchApps の可能性に対する関心が一時的に高まりました。WebRTC は安定したばかりで、いろいろいじられていました。

その後、いくつかのことが同時に起こりました。

• 分散システム理論がより主流になった
• ビットコインは、新しいプロトコルが波を起こす可能性があることを示しました
• DJB の NaClが広く利用できるようになり、それによって公開鍵がよりコンパクトになりました

Web に落胆した開発者たちは、BitTorrent に注目し始め、そのネットワーク モデルを他の種類のデータ構造に適用できるかどうか、もし適用できるのであれば、BitTorrent とは異なり、p2p ネットワークは一般的なコンピューティングに役立つでしょうか? と考え始めました。

これにより、ほぼ同時に IPFS、 Secure Scuttlebutt、 Dat、 WebTorrentが形成されました。

BitTorrent の亜種

#

BitTorrent は Merkle Tree を使用してデータセットを表します。これは、Torrent がファイルの 1 つの静的なコレクションを表すことを意味します。各プロジェクトは、より動的なデータのサポートを追加しながら、共有ホスティングと強力な認証の恩恵を受けられる新しいデータ構造で Merkle Tree を置き換えることを検討していました。

IPFS: Merkle DAG

#

IPFS は依然としてコンテンツ ハッシュに焦点を当てていましたが、本質的にはデータの各チャンクをハッシュによって相互参照できる独自の torrent に分割しました。公開キーまたは DNS 名は、ダイナミズムをサポートするハッシュを指すことができます。DHT を使用してマシンを検索し、接続しました。

SSB: 追加専用のログ

#

SSB は、署名付きリンク リストとしてモデル化された追加専用ログを使用しました。後方参照はコンテンツ ハッシュであり、HEAD はローリング ハッシュになります。データを配布するために gossip model を使用し、ピアを接続するために"pubs" を使用しました。

データ: merkle log

#

Dat も署名付き追加専用ログを使用していましたが、リンク リストではなく Merkle Tree を使用してノードを参照していました。これにより、ツリー構造を使用して部分的なデータセットに対して署名付きヘッドを検証できるため、SSB に比べてパフォーマンスが大幅に向上しました。DHT を使用してマシンを検索し、接続しました。

私の個人的なタイムライン

#

私はこれらのプロジェクトの間を行き来し、その過程で多くの教訓を収集しました。これを要約して説明します。

• 2014年

  • 私は 2014 年に Dominic Tarr 氏のご好意でこのシーンに参加しました。Dominic Tarr 氏は、SSB の最初のアプリケーション開発者として参加することを許可してくれました。

• 2016年

  • 私は Electron と Dat プロトコルを組み合わせて、それを「ピアツーピア Web ブラウザー」と宣言しました。次に、p2p ファイルの読み取りと書き込みのための API を詰め込み、それを Beaker ブラウザとして売り込み始めました。

• 2017年

  • Beaker は p2p Web サイトを「フォーク」する機能をサポートしていたため、既存のユーザー サイトをフォークしてアカウントを作成する Rotonde と呼ばれるインディー ソーシャル ネットワークが一時的に登場しました。同時に、Beaker チームは Friitter と呼ばれる技術上で Twitter クローンを作成しました。

• 2018-2020

  • Beaker チームは、Dat ネットワーク上のユーザー データと対話するための組み込み API を徹底的に実験しました。これには、ユーザー データから計算ビューを作成するブラウザーのインデクサーが含まれていました。

• 2021年

  • これまでの結果に落胆し、その理由については後ほど説明しますが、私は別のソーシャル ネットワーキング プロジェクト CTZN に着手し、 ライブストリーミングを行いました。私はハイブリッド p2p モデルとサーバー モデルの実験を開始しました。 訳注: Building in the Open - Paul Frazee - Medium

• 2022年

  • 私は夢が詰まったポケットと膨大なバックログを抱えて Bluesky に入社しました。失敗したプロジェクト 学び。

何がうまくいったのか

#

P2P を使用すると、いくつかのことが非常に簡単になります。Beaker ブラウザは、ワンクリックで Web サイトを作成し、他の人のサイトをフォークする機能をデモしました。アプリケーション全体を、サーバーに依存せずに単にファイルの読み取りと書き込みを行う SPA として作成することもできます。

開発者は、ホスティングや運用を必要としないネットワーク アプリケーションを公開できる機能に非常に肯定的な反応を示しました。FOSS 愛好家は、自分たちの基本理念に合致した配布システムを手に入れることができて非常に満足していました。

各プロトコルによって構築されるデータ構造は大幅に進化しました。各テクノロジーには非常に革新的な改善がいくつかありました。

私たちは、分散されたデータソースに対して大規模なアプリケーションを設計する方法について膨大な量を学びました。

何が悪かったのか

#

人々は仮説上の改善のために機能を犠牲にすることはありません。純粋な p2p モデルは導入の問題 (2 人のユーザーがどのようにして初めて出会うのか?) に悩まされており、返信やいいねなどのイベントの信頼性の高い配信は解決されませんでした。個々のデバイスでは管理できないデータ規模に達するまでに時間はかかりませんでした。

私たちは、テクノロジーの利便性を維持する方法でマルチデバイスの同期を解決したことはありません。キーのバックアップ/同期についても同様です。

DHT は信頼性もパフォーマンスも高くありませんでした。私たちはデバイスの検出と NAT トラバーサルについてあまりにも楽観的すぎました。

ユーザー デバイス上ですべてを実行すると、リソース管理に関して新たな難しい問題が生じます。キャッシュされたデータをクリアしても安全なのはどのような場合ですか? 開いたままにできる接続の数はどれくらいですか? 人々が気づく前に、デーモンはどれくらいの CPU と RAM を消費できるでしょうか? モバイルはスターターではありませんでした。

これが Bluesky 用にどのように合成されたか

#

ジェイが最初に私に連絡をくれたのは、ピアツーピアとフェデレーションのハイブリッドについて話し合うためでした。これは、デバイスホスト型ネットワーキングは実現不可能であると信じながらも、プロジェクトで使用されていたデータ構造に可能性を見出していた彼女が会社に売り込んだ前提でした。彼女は、これらのプロトコルの低レベルの詳細を専門とする Dan Holmgren を採用して、最初のプロトタイプを構築しました (その後、引き続きプロトコル開発を主導しました)。その後、アーロン ゴールドマンと私は、物事を具体化するために参加しました。

p2p/フェデレーションのハイブリッド アプローチは、デバイス ホスト型ネットワーキングが基本であるという考えがあったため、それまではほとんど放棄されていました。Blueskyの主張は、p2p モデルが実際にはフェデレーションが通常直面する問題の解決策であるというものでした。p2p の貴重な属性のほとんどは、サーバーに正しく適用されていれば引き継がれます。合成した様子はこうです。

ホスティングの俊敏性

#

私たちが維持しようとしていた P2P の一般的な利点は、ホスティングの俊敏性でした。ホストベースのアドレス指定 (Web の従来のモデル) は、サーバーの名前で公開されたデータがそのサーバーから移動できなくなることを意味します。リダイレクトは個々のページには適しているかもしれませんが、大規模なデータセットはレコードを広範囲に相互参照するため、ユーザーが新しいサーバーに移動するたびにそれらの参照を確実に移行することはできません。

私たちが開発していたピアツーピア ネットワークは、俊敏性をホスティングできるように設計されていました。パブリッシュされたデータは暗号化識別子でアドレス指定され、読み取り時にホストに解決されます。ホスト解決がユーザー デバイスに接続する DHT 経由でなければならない理由はありません。代わりに、常時オンライン サービスを解決することもできます。これが、最終的に PDS (パーソナル データ サーバー) を使用して AT プロトコルを設計する方法です。

私たちの目標はソーシャル ネットワーキング プロバイダーへのロックインを防ぐことであったため、これは明らかな利点のように思えました。

暗号構造

#

ユーザーデータは、最適なプルーフサイズを実現するために選択された Merkle Search Tree と呼ばれる暗号構造でエンコードされます。これはピアツーピアの作業から直接引き継がれたものであり、ホスティングの俊敏性を推進するものです。

プロトコル用語では、この構造を「リポジトリ」と呼びます。

リポジトリは、キャッシュ可能性が高く、効率的に複製できるように設計されています。暗号化構造により、信頼性の検証が安価になります。PDS に直接話しかけることなく、それが正規データであるというある程度の保証を得ることができます。

このモデルの欠点は、リポジトリ全体がパブリックにブロードキャストされることを意図していることです。選択的に共有されるデータには、プロトコル内に別のチャネルが必要です。

ホストの検出

#

PDS モデルに移行すると、暗号化識別子からホストを検索する要件が緩和されました。DHT は、ボランティア サーバーのメッシュを使用して、未検証の 1 対多のテーブルを維持します。PDS モデルは、特定の暗号化 ID のホストを見つけるために、検証済みの 1 対 1 テーブルにドロップできることを意味します。

DHT のデバッグにかなりの労力を費やしたため、これらのルックアップにもホスティング メッシュを使用しないことにしました。代わりに、 外部監査用に証明書の透明性をヒントにした暗号化ログを使用する did:plc レジストリ サービスを作成しました。 今のところ、私たちは単一のサービス モデルに夢中ではないため、PLC は「プレースホルダー」の略です。このレジストリを ICANN スタイルの組織に移行するか、複数の組織コンソーシアムの運営にクローズドな非 PoW ブロックチェーン¹を使用したいと考えています。データ構造は、どちらの結果でも機能するように設計されています。

集約データモデリング

#

私たちが p2p 時代を通じて洗練させたデータ モデルは、集計ベースのインデックスでした。ユーザーはお互いのデータセットをサブスクライブし、それらをローカル インデックスに取り込みます。これらのローカル インデックスをクエリして、アプリケーションの状態を表示できます。

これは、各ユーザー独自のデータセットが隔離された空間であるという事実を保持するため、うまく機能します。ユーザーは同じプライマリ レコードを処理しないため、ユーザー間で権限を調整する必要はありません。代わりに、各ユーザーをデータセットの唯一の所有者として扱い、インタラクションを生成して累積的なビューを形成します。多くのソーシャル アプリケーションはすでにそのように動作しています。

このモデルは、結果的に整合性のある収束からも恩恵を受けます。共有所有権データにはトランザクション保証が必要ですが、オープン/分散型 WAN では動作の信頼性が低くなります。結果整合性には独自の驚きが伴いますが (PDS が「読み取りスティッキー」であるかどうかについていくつかの会話がありました)、これにより、グローバル ネットワークのパフォーマンス コストがうまく隠蔽され、各ユーザーの独立性が維持されます。

Bluesky の場合、私たちの p2p 作業との主な違いは、これらの集約が各ユーザー独自のインフラ (PDS またはデバイス) ではなく、大規模なサービス (AppView) 経由で行われると決定したことです。これにより、人々がソーシャル体験に期待する大規模なネットワーキングの提供が可能になります。

私たちは、アグリゲーターがホストから分離されており、さらに別の形式の俊敏性を生み出しているため、私たちの使命の観点からこのアプローチに満足しました。誰でも自由に新しいアグリゲーター²を立ち上げることができ、他の人がアクセスできるのと同じデータセットにアクセスできるようになります。これは非常に Webby らしい概念です。

P2P とは言えず、フェデレーションにも程遠い

#

これ以上適切な用語が思いつかなかったため、最終的に AT プロトコルを「フェデレーション」ネットワークと呼ぶことにしましたが、実際には誰もがよく知っているフェデレーションの一種ではありません。ピアツーピアの影響が大きすぎるため、その原型にうまく当てはめることができません。また、現在広く理解されている ActivityPub のフェデレーション モデルとも混同されます。

同僚が残念がってしまったことに、私はこのモデルを「相互接続」のかばん語である インターネクション(Internection) と呼び始めました。私がこの用語が好きなのは、人々が「ハイパーリンク」という用語を目にも留めずに使い始めた 70 年代の気まぐれなオタク心を思い出させるからです。私が止めなければ、チームが私のアパートに火をつけるかもしれないと思うけど。

これを暗号データ Web と呼ぶほうがさらに正確かもしれません。すべてのユーザーのデータ リポジトリは、本質的には Web サイトです。集約アプリケーションは本質的には検索スパイダーです。Web は、さまざまな理由から、構造化データを完全には習得できませんでした。AT プロトコルはそれを基本的に採用しています。サイトからビューを取得するのではなく、ユーザーからレコードを取得します。当社のアグリゲーターは、検索ページではなくデータ インデックスを作成します。

私たちが AT Protocol という名前に落ち着いた理由がわかります。技術的な意味では、AT (認証された転送) は、本質的に認証されたデータである暗号構造の使用を指します。社会的な意味では、「AT」は「@」であり、ネットワークの核となるプリミティブであるユーザーを参照するための記号です。