鉱石ラヂオモデル

全員の投稿を集めるサーバーを通さずに SNS を読む仕組み

moja.blue · 2026年10月23日

1.白い画面

わたしは blusco という、Bluesky を読むためのアプリを作っている。その次の版の blusco ∅ は、開くとしばらく画面が白いままだった。いまの blusco なら一瞬で投稿が出る。読んでいる人も、読む相手も同じなのに、∅ だけが待たされた。

使ってみて、この待たされ方は Nostr に似ていると感じた。Nostr は、投稿があちこちのサーバーに分かれて置かれていて、アプリがそれを自分で集めて並べる SNS だ。原因を調べると、たしかに同じ形だった。この記事では、その原因と、直すために作った仕組みを書く。仕組みの名前は鉱石ラヂオモデルだ。

2.電話とラジオ

∅ には、読む相手を自分で選んでおくリストがある。わたしのリストには36人いる。∅ は開くたびに、その36人の一人ひとりに「新しい投稿はあるか」と聞いて回っていた。電話を36回かけるのと同じだ。全員が答えるまで、どの投稿をどの順に並べるかが決まらない。白い画面は、その待ち時間だ。

ラジオは違う。局が一度流せば、聞く人が何人いても流す手間は同じだ。聞く側の仕事は、周波数を合わせることだけだ。

電話の形のままでは、相手が36人なら少なくとも36回聞くことになる。聞かなかった相手に新しい投稿があるかどうかは、聞かないかぎりわからないからな。かける回数を減らすには、ラジオの形に変えるほかない。

3.家と目

Bluesky の裏側は、大きく3つの持ち場に分かれている。

  1. PDS：投稿をしまっておく家だ。投稿は、書いた人の家にある
  2. Relay：全員の家から新しい投稿を集めて、1本の流れにして流す係だ。この流れは firehose（消防のホース）と呼ばれる。全部の投稿が勢いよく流れてくるからな
  3. AppView：流れてきた投稿を全部ためて、並べ替えて、一人ひとりに見せる係だ。タイムラインもいいねの数も、ここで作られる

家は誰でも持てる。だが AppView は、全員の投稿をためるので大きな設備が要る。いま Bluesky を読んでいる人のほとんどは、Bluesky の会社の AppView を通しているだろう。家は自分のものだが、目は借り物だ。

2026年4月16日に、Bluesky は攻撃を受けて13時間以上止まった。そのあいだも、投稿を家（PDS）に直接置く Leaflet というブログは読めた。家が無事なら読める物がある。止まったのは目のほうだったのだろう。

4.鉱石ラヂオ

鉱石ラヂオは電池を持たない。鳴らす力は電波そのものだ。局に払う料金もない。周波数を合わせれば、その電波だけが聞こえる。

Bluesky の電波は firehose だ。これを誰でも受け取りやすくした Jetstream という中継がある。Jetstream に「この人たちの投稿だけ」と頼むと、その人たちの投稿だけが流れてくる。頼むときに渡すのは、一人ひとりに付いている番号（DID）だ。周波数を合わせるのと同じだ。

川に仕掛ける梁（やな）も同じ働きをする。梁は、魚を捕るために川の流れの中に組む仕掛けだ。川の全部を見る必要はない。流れてきた魚のうち、仕掛けにかかった物だけを取る。

この形なら、AppView に頼らずに読める。お金もかからない。受け取るのは自分のスマホやパソコンで、あいだに全員の投稿を集めるサーバーを通さないからな。

5.4つの部品

鉱石ラヂオモデルは、4つの部品でできている。どれも、身近な物にたとえた名前を付けた。

井戸の考え方は、前に書いた文章（The Fifth Path）から来ている。井戸のある村には川が要らない。川の水が止まっても、井戸には水がたまっている。知らない人を探すにはダムが要るが、知っている人の声を聞くだけなら、その人の井戸からくめばいい。

6.書いた人に聞くか、全員に聞くか

「この人は何を書いたか」を調べるのはかんたんだ。書いた人の家に聞けば答えが返る。

「この投稿に誰が返事をしたか」を調べるのはむずかしい。返事は、返事をした人の家にしまわれているからだ。全員の家を見て回って集めておくサーバー（AppView）がないと、答えが出ない。

blusco のタイムラインに並ぶのは、自分で選んだ相手が書いた投稿だ。だから、書いた人の家に聞けば全部そろう。いいねの数は全員に聞かないとわからないが、blusco はもともと数を出さない。だからタイムラインを出すまでの道から、ダムを外せた。

7.測った数字

読む相手36人で、それぞれのやり方の速さを Mac から測った。

やり方36人分がそろうまで
ダム：AppView に1人ずつ聞く（同時に6人まで）2.2〜2.5秒
井戸：家に直接、全員同時に聞く1.1〜1.9秒
梁：1時間前の分からさかのぼって受け取る1.8秒
梁：12時間前の分から10秒
梁：24時間前の分から35秒

梁は、さかのぼる時間が長いほど遅くなる。アプリを閉じていたあいだの分を取り戻すなら、井戸のほうがいい。梁の出番は、開いているあいだだ。

8.開くときの順番

測った数字から、順番を決めた。

  1. 棚にとっておいたタイムラインを出す。0秒だ
  2. 井戸で、棚より新しい投稿を聞く。まだ手元にない投稿だけ、中身を読む。iPhone では1.1〜1.8秒で届いた
  3. 梁をつなぐ。2分前の分からさかのぼって受け取り、井戸と梁のあいだで投稿がもれないようにする
  4. アプリを閉じたら梁を切って、そのときのタイムラインを棚にしまう。30分以内に開き直したら、梁で閉じていたあいだの分を受け取る。それより長ければ、井戸から聞き直す

白い画面はなくなった。開いた瞬間に前回のタイムラインが出て、1秒あまりで新しい投稿が足される。あとは開いているあいだ、読む相手が書くたびに新しい投稿が増えていく。電話をかけていたころと比べて、どこが違うか？ 待つものがないことだ。

9.できないこと

鉱石ラヂオにも聞けない物がある。

  1. 言葉で探すリスト（たとえば「ナポリタン」と書いた投稿を集める）は、全部の投稿の中から選ばないといけない。量が多すぎてスマホでは受け取りきれないので、AppView の検索に頼る。ここはダムの仕事だ
  2. 他人が作ったフィード（おすすめの投稿を集めた流れ）は、その人のサーバーが選んだ結果だ。自分では作り直せないので、聞きに行くしかない
  3. 梁の電波は Relay から来る。Relay が止まれば梁も止まる。そのときは井戸が残る
  4. Jetstream でさかのぼれるのは、測ったところでは36時間前までだった
  5. 投稿の中身を読むところは、まだ AppView に頼っている。棚と井戸だけで投稿を出せるようにするのは、これからだ

10.海賊ラジオ

Bluesky の初めのころは、招待された人だけが使えた。同じ周波数に集まった人たちが、局も許可もないまま話していた。海賊ラジオのようなものだった。人が増えて、大きな局ができた。

鉱石ラヂオモデルは、昔に戻る話ではない。大きな局があることを知ったうえで、自分の周波数を選ぶ話だ。全部の電波を聞く必要はない。自分で選んだ相手の声が届けば、それで足りると思う。

わたしは次に、AT Protocol（Bluesky を動かしている決まり）の上で動く海賊ラジオを作るつもりだ。自分で決めた形のデータを書けば、それも同じ電波に乗る。聞く人は周波数を合わせるだけでいい。局を開くのに、許可も大きな設備も要らないだろう。そのとき聞こえてくるのは、どんな声だろうか。

出典