List of Nostr [text.Baldanders.info]

RSSHub について調べようとしたら結構おおきな話だった

2026-07-07T10:25:24+00:00

いつものように Mastodon の自 TL に流れてきたポストから。 EFF (Electronic Frontier Foundation) の記事ですな。

Hate “The Algorithm?” RSS Is One of the Tools You’ve Been Looking For

もの凄く端折っていうと，ソーシャルメディア等のアルゴリズムに任せるんじゃなくて，枯れた技術とはいえ RSS があるんだから，これを使って自分で情報管理しようぜ！といった内容。

RSS is one of the best examples we have of the open web, where we can design and customize how we experience the internet, not the other way around. RSS has come in and out of fashion, been declared dead, and has come back, every time. Open systems are the best way forward to a free, equitable internet, and the resilience and continued reinvention of RSS has shown just how creative the web community can be with open protocols.

via Hate “The Algorithm?” RSS Is One of the Tools You’ve Been Looking For

この記事の最後の方に

And even if a website doesn’t have an RSS feed, there are workarounds from tools like RSSHub, RSS-Bridge, and RSS.app that require varying levels of technical expertise or a willingness to pay subscription fees.

via Hate “The Algorithm?” RSS Is One of the Tools You’ve Been Looking For

などと書かれていて，「へぇ。フィードがなくても生成してくれるんだ」と思いながら，とりあえず RSSHub のサイトを覗いてみたのだが，何が書いてあるかよく分からない。 Folo？ RSSHub の話じゃねーの？自前で実装するのか？

というわけで，いつものように Kagi Assistant とやり取りしながら調べてみた。

RSSHub と Folo

RSSHub は「Everything is RSSible（全ては RSS 化できる）」を掲げる「世界最大のRSSネットワーク」らしい。 Kagi Assistant にまとめさせた特徴は以下の通り。

特徴	内容
オープンソース	AGPL-3.0ライセンスで公開，オープンスタンダードとプロトコルに準拠
大規模コミュニティ	1,300人以上のコントリビューター・メンテナーが活躍
豊富なルート	多数の事前設定済みルート（変換ルール）とパブリックインスタンスが利用可能
強力なAPI	様々なシーンに対応するAPIとエコシステムプロジェクトを提供

Docker を使って環境を自前で構築できる他，公式を含むパブリックインスタンスも提供されている。このインスタンスのひとつが Folo ということのようだ。

Folo is an AI RSS reader and discovery platform that works especially well with RSSHub. It offers numerous user-shared instances that you can browse, switch between, and use with just one click inside Folo. These instances are not compatible with external readers. You can also share your own instance on Folo to earn tokens.

via Public Instances

「自身のインスタンスを Folo 上で共有してトークンを稼ぐ」？とりあえず，そこは後回しだ。

直接 RSS フィードを提供する場合

まずは一番単純なパターン。あらかじめ RSS フィードを提供している Web サイトから Folo に直接フィードを提供する場合。

graph TB subgraph "WWW (Site)" RSS_YES[Web2 Site
RSSフィードあり
ブログ，ニュースサイト等] end subgraph "Folo" FOLO[Folo
RSSリーダー] end %% RSSフィードを直接 FOLO に提供する RSS_YES -.->|RSSフィード提供| FOLO

これは分かりやすい。

RSSHub サーバ経由で RSS フィードを提供する場合

古き良き（笑）テキストサイト等や Web 2.0 時代のサービスでも RSS フィードを提供していない SNS サービス等は RSSHub サーバ経由でフィードを生成する。

graph TB subgraph "WWW (Site)" RSS_NO[Web1/Web2 Site
RSSフィードなし
静的サイト，SNS等] end RH_STANDALONE[RSSHub
独立サーバー] subgraph "Folo" FOLO[Folo
RSSリーダー] end %% 独立サーバー（RSS3不要） RSS_NO -.->|スクレイピング/独自API| RH_STANDALONE RH_STANDALONE -.->|RSSフィード提供| FOLO

これもまだ分かる。 RSSHub が頑張って仲立ちしてるってことだよね。

RSS3

ここからだよ，大事 (おおごと) なのは。

graph TB subgraph "WWW (Site)" RSS_YES[Web2 Site
RSSフィードあり
ブログ等] RSS_NO[Web1/Web2 Site
RSSフィードなし
静的サイト，SNS等] end subgraph "Fediverse" AP[ActivityPub
Mastodon等] end subgraph "Web3 (Blockchain)" ETH[Ethereum
トランザクション] NFT[NFT
ERC-721] DEFICH[DeFi
Uniswap/Aave] ARWEAVE[Arweave
分散型ストレージ] end subgraph "RSS3 Node" direction TB subgraph "RSS Component" RH_INTERNAL[RSSHub
内部コンポーネント] end subgraph "Federated Component" FED[ActivityPub
インデクサー] end subgraph "Decentralized Component" DEC[Blockchain
インデクサー] end DSL[DSL
Data Sublayer
インデックス・保存] end subgraph "RSS3 Network" NETWORK[RSS3 Network
分散型ノード群] end subgraph "Folo" FOLO[Folo
RSSリーダー] end %% Web2 → RSSComponent RSS_YES -->|RSSフィード取得| RH_INTERNAL RSS_NO -->|スクレイピング/API| RH_INTERNAL RH_INTERNAL -->|フィードデータ| DSL %% Fediverse → FederatedComponent AP -->|ActivityPubデータ| FED FED -->|インデックス| DSL %% Web3 → DecentralizedComponent ETH -->|ブロックチェーンデータ| DEC NFT -->|NFT取引データ| DEC DEFICH -->|DeFiトランザクション| DEC ARWEAVE -->|分散型データ| DEC DEC -->|インデックス| DSL %% DSL → ネットワーク → Folo DSL -->|統合データ| NETWORK NETWORK -->|Web1/2/3統合| FOLO

なんと RSS3 ノードを経由することで Fediverse (ActivityPub) や Web3 のデータも Folo で閲覧できるらしい。 ActivityPub とか Blockchain とかしれっと出てきて，私は驚いたよ。世の中そんな風になってるんだねぇ。

RSS3 は “An open web, readable again” をビジョンとして（開かれたウェブですってよ，奥さん），「Web1/Web2/Web3 にまたがる情報をインデックス・配信する分散型情報インフラ」だそうだ。分散ネットワークで検閲耐性が高いと言われている¹。 RSS3 のエコシステムにおいて RSSHub および Folo は中核プロダクトと見なされているらしい²。

RSS3 と $RSS3

RSS3 経済圏の通貨が $RSS3 トークンで，以下のように機能しているそうな。

番号	フロー	説明
①	アプリケーション → トークン	開発者がAPIキーを取得し $RSS3 でクエリ料を支払う
②	トークン → Operation Pools	支払いがプールに集約される
③	プール → ノード運営者	データインデックス作業の報酬として分配
④	プール → 委任者	ノードに委任したトークン保有者にも報酬分配

これ，実際にデータを使うエンドユーザはエコシステムの外側にいるし，ユーザから見て直接データを提供するアプリケーション（開発者）も，この流通サイクルの中では $RSS3 トークンを（払うだけで）得る手段がないことになる。トークンがこのエコシステムの外側でも流通すればいいんだろうけど（以下は Kagi Assistant が示した RSS3 エコシステムの外側との関係）。

graph TB subgraph "RSS3 の役割" RSS3[RSS3
分散型情報インフラ] API[RSS3 API
データ提供] end subgraph "取引所の活用" OKX[OKX
取引ボット，ポートフォリオ管理] ARB[Arbitrum
クロスチェーンエクスプローラー] AI[AI DApps
分散型エージェント] end subgraph "$RSS3 トークン" TOKEN[$RSS3
取引所で取引可能] BITGET[Bitget] LBANK[LBank] COINW[CoinW] end RSS3 -->|データ提供| API API --> OKX API --> ARB API --> AI TOKEN --> BITGET TOKEN --> LBANK TOKEN --> COINW

この手のネットワーク通貨の問題って，結局ゼロ年代に流行った「地域通貨」の問題と同じなんだよなぁ。 …まぁ，いいや。ちなみに，一定額の $RSS3 トークンを Staking³ すれば誰でも RSS3 ノードを運用できるらしい。

分散型ソーシャルプロトコル統合

RSS3 は複数の分散型ソーシャルプロトコルを Universal Social API で統合しているらしい。

graph TB subgraph "分散型ソーシャルプロトコル" FC[Farcaster
Ethereumベース] LENS[Lens Protocol
Polygonベース] NOSTR[Nostr
シンプルプロトコル] MIRROR[Mirror
Web3パブリッシング] CB[Crossbell
ソーシャルプロトコル] end subgraph "RSS3" RSS3api[RSS3
Universal Social API] API[RSS3 API
データ統合] end subgraph "アプリケーション" HOOT[Hoot.it
ソーシャル検索] FOLO[Folo
RSSリーダー] DEV[開発者アプリ] end FC --> RSS3api LENS --> RSS3api NOSTR --> RSS3api MIRROR --> RSS3api CB --> RSS3api RSS3api --> API API --> HOOT API --> FOLO API --> DEV

各プロトコルの特徴

プロトコル	ブロックチェーン	特徴
Farcaster	Ethereum	「十分な分散化」，柔軟なネームスペース，グローバル状態
Lens Protocol	Polygon	Aave創設者Stani Kulechovによる，合成可能なソーシャルグラフ
Nostr	なし（リレー方式）	シンプル，検閲耐性，Jack Dorseyが支援
Mirror	Ethereum	Web3パブリッシングプラットフォーム
Crossbell	-	ソーシャルプロトコル

具体的な機能

機能	説明
クロスプロトコル検索	Farcaster，Lens，Nostr のデータを横断して検索
ソーシャルグラフ統合	異なるプロトコルのユーザー関係を統合
コンテンツ相互運用性	プロトコル間のコンテンツ相互利用を可能にする

Nostr もここにかかってくるんだねぇ。これもびっくりした。ただ Blockchain ベースのプロトコルは分かるけど Nostr は（Blockchain ではないので）どうやって統合してるのか分からない。 Kagi Assistant は色々憶測を述べてたけど（RSS Component 経由で RSS フィードとして取り込まれるんじゃないか，とか言ってくさる），実際の技術詳細は公開されてないらしい。

アプリケーション例のうち Hoot.it は「RSS3 が開発したオープン Web 検索エンジン」だそうで Nostr データの閲覧も可能なんだと。

Hoot.it の機能

機能	説明
Nostr アドレス検索	Nostr アドレスを入力してソーシャルデータを表示
ChatGPT 統合	2024年5月に ChatGPT との接続を発表
Web3 コンテンツ検索	分散型ネットワーク上のコンテンツを検索

ActivityPub が Federated Component で，Nostr が Universal Social API で RSS3 に統合されてるとなると atproto が取り残されてる感じかねぇ。でも，以前に紹介した Streamplace/Livepeer なんかは独自のトークンを運用してるって話だし，またぞろ面倒くさいことになってる気がするなぁ。

Web3 はちゃんと “Web” になっている？

Blockchain 周りは NFT が登場したあたりから完全に興味が失せてしまったのだけど，現時点においてちゃんと “Web” としての体裁を整えてきているという印象を受けた。そこに私のようなネットの辺境にいるような人間が入り込めるかは分からないけど Folo のようなサービスはちゃんと触っておいたほうがいい気がする。

まぁ，その辺はおいおい（笑）

参考

情報共有の未来: yomoyomo (著); 達人出版会 2011-12-30 (Release 2012-02-19); デジタル書籍; infoshare (tatsu-zine.com); 評価

同名ブログの書籍化。感想はこちら。

reviewed by Spiegel on 2012-11-03

もうすぐ絶滅するという開かれたウェブについて続・情報共有の未来: yomoyomo (著); 達人出版会 2017-12-25 (Release 2019-03-02); デジタル書籍; infoshare2 (tatsu-zine.com); 評価

WirelessWire News 連載の書籍化。感想はこちら。祝 Kindle 化！

reviewed by Spiegel on 2018-12-31

P2P など，本当に分散化したシステムではデータ（コンテンツ）の「場所」が不定となり遍在化するため検閲が難しくなる。コピーはいくらでもあるし，アクセスの迂回も容易だからだ。 ↩︎
2024年1月に RSSHub と RSS3 との間でパートナーシップが結ばれた，と Kagi Assistant が言っていたが，その説明の Web ページが 404 でなくなってるみたいで，経緯とかは確認できなかった。AI の知識にはあるけど裏付ける情報がない，ということのようだ。これからこういうのも増えそうだな。 ↩︎
Staking とは，トークンを（ウォレットとかではなく） Blockchain ネットワーク上に一定期間預けておくことを指す。 Ethereum のコンセンサスアルゴリズムである Proof of Stake (PoS) はトークンを多く長く預けている人ほどトランザクション承認の権利が得やすくなるため，結果として信用度や貢献度が高いと見なされ，報酬も得やすくなる。簡単にいうと金遣いが荒い人は信用されないってことだよね。この Staking の仕組みを使って投資を行う人も結構いるらしい。 ↩︎

私の Mastodon 遍歴

2024-05-26T05:54:28+00:00

fedibird.com の管理者であるのえるさんが

MastodonやMisskeyは設置されたサーバごとに違うSNSだと思った方がいい、という話をしましたが、それだけに選ぶのは難しい。

fedibird.comから生きたサーバとして認識されているMastodon、Misskey、Pleroma系サーバの合計が約1万2千あります。このうち、500ユーザー以上登録されているサーバにしぼっても、698サーバあります。

とはいえ、いくつかの共通のソフトウェアが使われていて、サーバ同士が連合していて、どのサーバから参加してもお互いにつながることができる、というのもActivityPubの分散SNSの売り文句ではあります。

つまり、ざっくりした情報からとりあえずどこかに参加してみて、そこからいろいろ調べて確かめて、自分がどこからどうやってActivityPubネットワークに参加するか決めていく、という過程を経るしかないのかなと思います。

最初のざっくりした選択肢は、デフォルトのmastodon.socialや、joinmastodon.org掲載のmstdn.jpやmastodon-japan.net、あとは個人の紹介しているいくつかのサーバになるでしょうか。MisskeyにはMisskeyHubがありますが、基本的にmisskey.ioに直接集まるかな。

MastodonやMisskeyは設置されたサーバごとに違うSNSだと思った方がいい、という話をしましたが、それだけに選ぶのは難しい...より

と書いておられて，さらに続けて

そういうわけで、最初のサーバを探す人のことはあえて意識から外して、

もうこちらにある程度慣れた人に向けた情報が増えていく必要があるのではないかと思う今日この頃です。

そういう詳しい情報、最初のサーバを探してる人にも役立つんですけどね。

そういうわけで、最初のサーバを探す人のことはあえて意識から外して...より

と書かれている。んじゃあ，私の Mastodon 遍歴を纏めておくのは多少の意義はあるかな。ということで書いてみる。あと愚痴とかも（笑）まぁ，言うほど大した内容じゃないが。

Mastodon に転ぶきっかけ

最初に予防線を張っておくと，私は2017年春に日本で Mastodon が流行し始めた頃に「GW 過ぎたらみんな忘れてるに100カノッサ」と書いて最終的に賭けに負けた人間である。もっとも私自身は（今はなき Qiitadon を試したこともあったが）2017年が終わる頃には Mastodon について綺麗サッパリ忘れ去っていた。

再び Mastodon を思い出したのは，言うまでもなく，旧 Twitter を買い取って私物 (メタクソ) 化した某マスク氏の暴虐が始まった2022年後半。具体的なトリガーとしては，暗号化メッセージングアプリの Signal が Mastodon アカウントを公開したことだ。

Hello, Mastodon - signalapp@mastodon.world
— Signal (@signalapp) November 18, 2022

もっとも，このときはまだ Mastodon に懐疑的で，放置していた mstdn.jp サーバのアカウントを流用して様子見の状態だった。その後 fedibird.com へ拠点を移している¹。

本格的に Twitter から Mastodon への移住を考え始めたのは2022年が終わる頃。 2022年末は心筋梗塞で入院騒ぎをやらかしていて，このとき

今の Twitter はテレビ並みにつまらない！

ぼちぼち Mastodon への移住を進めようかとより

と感じたのが移住を決意するポイントだった。最終的に 𝕏 (旧 Twitter) アカウントは2023年9月に休眠状態としている。実際には私の関心領域にかかる人が 𝕏 で活動されているので完全放置というわけでもないのだが。

mstdn.jp から fedibird.com に拠点を移した理由だが，標準機能をかなり拡張して細かくカスタマイズできるから。 misskey.io 等の絵文字スタンプもきれいに表示してくれるし引用ポストもできるし全文検索機能もある。ただし（2024年5月時点で）バージョン 3.x をベースにしているようで²，ポストの変更などには対応してない。

ActivityPub と Fediverse

話は変わるが Mastodon 分散プロトコルのベースになっている ActivityPub は Mastodon が発祥ではないらしい。 Mastodon に ActivityPub が実装され始めたのは v1.6 からだそうなので2017年9月頃になる。ちなみに ActivityPub が標準仕様として W3C 勧告になったのは2018年1月である。

ActivityPub の実装は本当に多岐に渡っている。

via File:Fediverse branches 1.2.png - Wikipedia

Web ベースの SNS 分散プロトコルとしては ActivityPub がおそらく最強だろう（最適解とまでは言わないが）。 WordPress の拡張機能として組み込むこともできるし Cloudflare は Wildebeest を使って Mastodon 互換サーバを構築するサービスを展開しているそうだ。

最初に紹介したポストにもあるとおり Mastodon サーバだけでもかなりの数があるし，広く ActivityPub ベースの Fediverse という括りであれば更にバリエーションがある。今のところ私は ActivityPub/Mastodon は 𝕏 の代替ではなく，全く別の生態系（ecosystem）の一部であると認識している。

Bluesky はどうなん？

2023年に入り Nostr や AT-protocol/Bluesky といった分散プロトコルやそのサービスが台頭してくる。

個人の感想として Nostr は（使い捨て ID を使ったデータ交換としては面白いが）人間同士のコミュニケーション・ツールとしては筋が悪いと評価していて，早々に見限った。

一方 Bluesky はプロトコルとプラットフォームの開発を同時進行するというなかなかに難しい運営をしているが，最近になってようやく分散化のロードマップが明確になってきて，実際に bsky.social といったサーバも登場しているようだ。ただ AT-protocol についてはマジで「なにもわからない」状態なので，そろそろ真面目に勉強すべきかなぁ。

私としては 𝕏 の代替サービスを探しているのなら Mastodon より Bluesky のほうがいいんじゃないかと思っている。 Bluesky のほうが優れていると言うつもりはないが Mastodon というか ActivityPub は仕組み上 Fediverse 全体を俯瞰することが難しい。あくまで各ユーザ間のフォロー・フォロワー関係の中でデータのやり取りとその保持を行うので，特にユーザ数の少ない小規模サーバは「離島」状態になりやすい。これでは 𝕏 で大勢のオーディエンスを抱えているユーザは安易に ActivityPub/Mastodon に移行し辛いんじゃないだろうか。

Bluesky が実際に分散化し「連合（federation）」を組むようになったときにこういった問題を上手く捌けるかどうかは分からないが期待感はある。

mastodon.social ボット・アカウントを BAN された話

2023年に入って 𝕏 とIFTTT との連携が有料になったため，自サイトのコンテンツ情報を 𝕏 に自動でアップできなくなった（𝕏 にも IFTTT にもお金を払う気はない）。そこで Web 上のコンテンツ情報を自動で収集し Mastodon や Bluesky にポストするためのツールを自作することにした³。ちなみに IFTTT は完全撤退した。

更にこれを使って自サイトのコンテンツ情報のみならず他サイトのコンテンツ情報を収集・ポストすることも検討し始めた。要するに feed reader を Mastodon/Bluesky で代替する仕組みが欲しかったのだ。そうすれば色んなサービスを渡り歩かなくても済むかな，と思って。

「他サイトのコンテンツ情報を収集・ポストする」アカウントは別に用意した。 Bluesky はまだ招待制だったが紹介状（invitation）が有り余ってたし Mastodon は折角だから mastodon.social にボットアカウントを作った⁴。

しばらくはこれで上手く行ってたんだけど mastodon.social のボット・アカウントのほうがいきなり BAN されてしまった。理由は示されず不明。気がついたらデータのエクスポート以外何もできなくなってたのだ。

この経験から自身の活動を大手 Mastodon サーバで行うのはかなりのリスクを伴うことに気がついた。そこで個人活動用に Mastodon サーバを立ち上げ，最終的に Mastodon での活動拠点を全てそこに移すことにした。

ただ個人サーバはホンマに「離島」生活みたいだよな。フォローしたアカウントしか聞こえてこないから。予備系として大きめのサーバにアカウントを確保しておいたほうがいいかも知れない。私は fedibird.com のアカウントは今も消さずに予備系として残している。

封建時代のソーシャル・ネットワーク

今は本当に色んな Mastodon サーバがある。たとえば W3C や Internet Archive や BBC は自前でサーバを立ち上げてるし，FOSS 関連の Fosstodon や FLOSS.social といったサーバもある。 Mastodon ベースと言われる Threads は最近ようやく ActivityPub 連携を unlock した（ただしオプトインらしい）。

ただ，海外のサーバはルールとして英語での会話を要求しているところが多く，私のように母国語が日本語で英語不得手の人間は利用し辛い。あとモデレーションの基準がどうしても厳しいしよく分からない。たとえば前節で挙げた mastodon.social は言語の縛りはないようだが misskey.io をまるっと拒否している。まぁ misskey.io 側は気にしちゃいないだろうが（笑）単一プラットフォームのようにユーザが支配されていないからといって好き勝手絶頂に振る舞えるわけではないのだ。

前々節で「ユーザ数の少ない小規模サーバは「離島」状態になりやすい」と書いたが，ユーザ規模の大きいサーバは縛りが大きくて窮屈と言える。まぁ規模が大きければ大きいほどユーザを「量」でしか評価できなくなるからね。 ActivityPub/Mastodon と言えども「デジタル封建主義」からは逃れられないのだ。いや ActivityPub/Mastodon の場合は「デジタル氏族制度」とでも言うべきか？

EFF が言っていたが

善き独裁者を選んでも、独裁体制を修正することはできない

フェディバースは（“私たち”次第で）素晴らしいものになる | p2ptk[.]orgより

のである。かつてリベラルが「多文化主義」という名の墓穴を掘ったように Fediverse が「多様化」の墓穴にならないことを祈ろう。

ブックマーク

Fediverse 関連のブックマーク

参考図書

新しい封建制がやってくる―グローバル中流階級への警告: ジョエルコトキン (著), 寺下滝郎 (翻訳), 中野剛志 (その他); 東洋経済新報社 2023-11-01 (Release 2023-11-01); Kindle版; B0CG5R6N2G (ASIN)

「ネオ封建制（NEO-Feudalism）」。ネーミングが胡散臭くて買う気がしなかったのだが，やっぱ読んでおいたほうがいいのか？まぁ，安いし，300ページくらいの量なら（笑）

reviewed by Spiegel on 2023-12-16 (powered by PA-APIv5)

排除型社会―後期近代における犯罪・雇用・差異: ジョックヤング (著), Young,Jock (原著), 秀男, 青木 (翻訳), 泰郎, 伊藤 (翻訳), 政彦, 岸 (翻訳), 真保呂, 村澤 (翻訳); 洛北出版 2007-03-01; 単行本; 4903127044 (ASIN), 9784903127040 (EAN), 4903127044 (ISBN); 評価

感想はこちら。

reviewed by Spiegel on 2015-10-31 (powered by PA-APIv5)

当時は自由にサインアップできていたが，2024年5月現在 fedibird.com は既存ユーザからの招待のみ受け付けている。 ↩︎
fedibird.com では，セキュリティ脆弱性に対してバックポート・パッチを当てることで対応しているようだ。 ↩︎
自作ツールは完全に自分用に特化していて，OSS で公開はしているけど，他人が使うことを想定してない。あしからず。汎用ツールとしては mattn/go-mastodon や mattn/bsky あたりを使って cron 等で運用するのがオススメである。 ↩︎
Mastodon でボットアカウントを作る際にはプロファイルでボットであることを示すフラグを立てる。言い換えると，そのフラグさえ立てておけばボットアカウントは許容されている。 ↩︎

Nostr に旗を立てろ！

2023-02-05T14:54:41+00:00

Twitter を追い出された（言い方！）なんとかドーシーさんが出資したとかいう Nostr (Notes and Other Stuff Transmitted by Relays) が流行りらしい。

GitHub - nostr-protocol/nostr: a truly censorship-resistant alternative to Twitter that has a chance of working

Nostr 自身は，分散 SNS においてメッセージのリレーを行うためのプロトコルだそうで，このプロトコルを実装するためのリレー・サービスとクライアント・アプリケーションが必要らしい。

んで，そのリレー・サービスとクライアント・アプリケーションの一覧が以下にある。

Nostr-Clients-Features-List/Readme.md at main · vishalxl/Nostr-Clients-Features-List · GitHub

最近，私の周辺で Nostr が話題になったのは Damus が iOS アプリとしてクライアントを提供したことがきっかけのようだ。「いや iOS とか関係ないし」とか思ってたが， Android 用のクライアントとして Amethyst ってのがあるそうな。

ほんじゃあ，まぁ，試してみるべ。

サインアップ？

Amethyst

んー。分からん（笑）どうやってサインアップすんだ？

とりあえず「鍵」をつくるらしい。 “I sccept the term of use” にチェックを入れて “Generate a new key” のリンクをタップする。

いやいやいや。何だこれ？ “empty” ってなんやねん？

ここでパニクった私はうっかりサインアウトしてしまったのよ。あとのまつり… orz

“Generate a new key” で公開鍵と秘密鍵の鍵ペアを自動で作るのだが， Amethyst は作成した鍵でそのままサインインして上の画面になってしまう。んで，サインインした状態で（少なくとも）秘密鍵をメモっとかないと二度とサインインできない。まじすか orz

ここでようやく “how to start using Nostr” を読み始める（先に読め！）。ふむむ。 astral.ninja というのがあるのか。こちらは Web ブラウザ・ベースのクライアントらしい。早速アクセスしてみる。

astral

ここで “GENERATE KEYS” ボタンを押す。今度は間違えないぞ！

astral

（一応，鍵情報に目隠ししてます。あしからず）

んー。これはこのまま “PROCEED” ボタンを押せばいいのか？ポチッとな。

astral - settings

（一応，鍵情報に目隠ししてます。あしからず）

よしよし。鍵情報が出てきたな。 nsec で始まる文字列が秘密鍵， npub で始まる鍵が公開鍵である。ちゃんとメモっておこう。

再度サインインする場合は秘密鍵を使う¹。あとは設定画面の profile で Name と Picture URL をセットすれば表示名とアバターが表示される。他はとりあえず後回しでよい。なお nsec の秘密鍵を使えば他のクライアントでもサインインできるっぽい。もちろん Amethyst でも使える。

秘密鍵は秘密のままに

当然ではあるが秘密鍵は絶対に公開してはいけない。秘密鍵を公開するのは，その辺の Web サービスでユーザ ID とパスワードを公開するのと同じである。

逆に公開鍵の方は他ユーザにフォローしてもらえるよう公開しても OK。ちなみに私の公開鍵は

npub1v0yd6fxc0qczjj35rxu0m9gtkhhf4mkzl99tgs49f6e98y2ea6asl5rsxw

である。

ユーザ名には任意の名前を付けられる。他のユーザとかぶっても構わない。どうやら Nostr は鍵情報だけでユーザを識別しているようだ。なので，いくらでもユーザを作ることができるし，なりすましだって可能である。ちなみに某マスク氏の名前とアバターアイコンを使った（多分）偽ユーザとかもあるらしいっスよ（笑）

というわけで，作ったアカウントが自身のものである証明をする必要がある。 Nostr では Web サイトとの連携でこれを行うようだ。これは NIP-05 と呼ばれるプロトコル仕様の中で定義されている。

Web サイト連携によるユーザの証明

Nostr と Web サイトを連携するには，まず Web サイト側のルート直下に /.well-known/nostr.json というファイルを置く。中身はこんな感じ。

{
  "names": {
    "spiegel": "63c8dd24d87830294a3419b8fd950bb5ee9aeec2f94ab442a54eb2539159eebb"
  }
}

JSON 形式で "names" オブジェクト配下に "<username>": "<pubkey>" で記述されたオブジェクトを配置する。 username には任意の名前を記述する（多分 Nostr クライアントのユーザ名と揃えたほうがいいと思われ）。 pubkey には npub で始まる文字列ではなく公開鍵の生値を16進数文字列で記述する。公開鍵データの変換は damus key converter で可能である。

あとはこれを Nostr 側に読み取らせればいいのだが，ここで CORS (Cross-Origin Resource Sharing) の設定が必要になる²。

たとえばさくらのレンタルサーバであればルート直下の /.htaccess ファイルに

Header set Access-Control-Allow-Origin: "*"

の記述が必要（こんなドンブリ指定はちょっとヤバいかもなので，あとで修正するかも）。設定ができたら，ちゃんと取得できるか確認してみよう。

$ curl -sD - "https://baldanders.info/.well-known/nostr.json"
HTTP/2 200 
server: nginx
date: Sun, 05 Feb 2023 13:54:56 GMT
content-type: application/json
content-length: 103
last-modified: Sun, 05 Feb 2023 13:54:43 GMT
etag: "67-5f3f441b5a739"
accept-ranges: bytes
access-control-allow-origin: *
cache-control: no-store

{
  "names": {
    "spiegel": "63c8dd24d87830294a3419b8fd950bb5ee9aeec2f94ab442a54eb2539159eebb"
  }
}

よーし，うむうむ，よーし。 curl コマンドなんて知らねって方は test-cors.org でも確認できる。

Nostr クライアント側は profile 設定の “NIP-05 Identifier” 項目に /.well-known/nostr.json ファイルで指定した username とサイト名をセットする。こんな感じ。

astral - settings

これで

astral - profile

という感じに連携できるようになった。

Nostr は Web3 か？

公開鍵をそのまま ID とする考え方は Blockchain/Botcoin の仕組みに近い。 Bitcoin が公開鍵をそのままアドレス（= ID）として運用できているのは「元帳」である Blockchain が要求しているのが「取引」の一貫性と無矛盾性だから。故に ID = 公開鍵に対しては何も証明する必要がない。それは Bitcoin の責務ではないのだ。

でも Nostr はユーザ間のコミュニケーションを目的として考えられているわけで， ID が「誰」に紐づくのかという証明（certification）が絶対に必要。加えて鍵の生成・配布・更新・破棄（revoke）といったライフサイクルを管理する必要がある。これって PKI (公開鍵基盤) そのものなのよ。

前節で述べたように ID が「誰」に紐づくかを証明する仕組みとして NIP-05 が用意されているわけだが，このままでは ID = 公開鍵を破棄する仕組みがない。 ID を作ったら作りっぱなしで，もし秘密鍵が漏洩してもどうすることもできない。せいぜい NIP-05 の設定を外すくらいだろう（だから NIP-05 によるユーザの証明はけっこう重要？）。

また “how to start using Nostr” を読むと

Create multiple keys if needed: The same key can be used on all nostr clients. If you want to create multiple identities or accounts, you can create new such key pairs.

via What is Nostr, and how to start using Nostr

などと書かれているが，複数 ID を作っても ID に紐づくメタデータを移行する仕組みがない（もしくは手動で再構築するしかない）。いわゆる「離脱の自由」がないのだ。

本当は「公開鍵を ID とする（is-a 関係）」のではなく， ID と公開鍵を分離して「ID が公開鍵を所有する（has-a 関係）」のが正しいのだろう。それをしたら Nostr じゃなくなるかもしれないけど（笑） Nostr を Web3 実装のひとつみたいにみなす人もいるみたいなので，そういう意味でも「ID = 公開鍵」の仕様は外せないのかな。

替えの効かない ID を使って失敗するってのは，かつての住基番号や今の個人番号を彷彿とさせる。漏洩やなりすまし（あるいは乗っ取り）は絶対に起きるんだから，起きた後にどうリカバーするかというのは最初に考えておかないと，後付けにはできない。これを怠ると，いざというときに詰むことになる。

Nostr に旗を立てろ！

ともかく，これで最低限の設定ができた。とはいえ，今のところあんまり使う気にならないんだよなぁ。微妙に分かりにくいし使いにくい。それに，やっぱ SNS は相手がいてはじめて成立しうるものだし？

まぁ，今回は “Plant Your Flag, Mark Your Territory” ってことで，旗を立てるだけにしておこう。

ブックマーク

厳密には Nostr には「サインイン」という概念はないようだ。あくまで鍵 = ID に紐づくメタデータや投稿を取得できるというだけ。秘密鍵を使えばメタデータを変更できるし投稿もできる，ということらしい。投稿を削除する仕様はあるが，実際にどう機能するかはリレー・サービス次第のようだ。投稿には電子署名が付くので，基本的に変更はできない。これだけ聞くとコミュニケーション手段に向かないのでは？と思ってしまう（笑） ↩︎
つまり CORS の設定ができないサイトでは NIP-05 による証明ができない。なお GitHub Pages では特に何もしなくても通るらしい。 ↩︎