-
@ Don
2025-05-19 22:33:33タイトルは釣りです。そんなこと微塵も思っていません。 本稿はアウトボックスモデルの実装に関してうだうだ考えるコーナーです。 ダムスに関して何か言いたいわけではないので先にタイトル回収しておきます。
- NIP-65を守る気なんかさらさら無いのにNIP-65に書いてあるkind:10002のReadリレーの意味を知っていながら全然違う使い方をしているのは一部の和製クライアントの方だよね
- NIP-65を守る気が無いならkind:10002を使うべきではなく、独自仕様でリレーを保存するべきだよね
- アウトボックスモデルを採用しているクライアントからすれば仕様と異なる実装をしてしまっているクライアントが迷惑だと思われても仕方ないよね
- と考えればダムスの方が潔いよね
- とはいえkind:3のcontentは空にしろって言われてんだからやっぱダムスはゴミだわ
- やるとしたらRabbitみたいにローカルに保存するか、別デバイス間で同期したいならkind:30078を使うべきだよね
アウトボックスモデルはなぜ人気がないのか
言ってることはとてもいいと思うんですよ。 欠点があるとすれば、
- 末端のユーザーからすればreadリレーとwriteリレーと書かれると直感的にイメージされるものとかけ離れている
- 正しく設定してもらうには相当の説明が必要
- フォローTLを表示しようとすれば非常にたくさんのリレーと接続することになり現実的ではない
- なるほど完璧な作戦っスねーっ 不可能だという点に目をつぶればよぉ～
余談ですが昔irisでログインした時に localhost のリレーに繋ごうとしてiris壊れたって思ったけど今思えばアウトボックスモデルを忠実に実装してたんじゃないかな…。
現実的に実装する方法は無いのか
これでReadすべきリレーをシミュレーションできる。 https://nikolat.github.io/nostr-relay-trend/ フォローイーのWriteリレーを全部購読しようとすると100個近いリレー数になるので現実的ではありません。 しかしフォローイーのWriteリレーのうち1個だけでよい、とする条件を仮に追加すると一気にハードルが下がります。私の場合はReadリレー含めて7個のリレーに収まりました。 Nos Haikuはとりあえずこの方針でいくことにしました。
今後どうしていきたいのか
エンドユーザーとしての自分の志向としては、自分が指定したリレーだけを購読してほしい、勝手に余計なリレーを読みに行かないでほしい、という気持ちがあり、現状の和製クライアントの仕様を気に入っています。 仮にNos Haikuでアウトボックスモデルを採用しつつ自分の決めたリレーに接続するハイブリッド実装を考えるとすれば、
あなたの購読するリレーはこれですよー - Read(inbox) Relays (あなたへのメンションが届くリレー) - wss://relay1.example.com/ - wss://relay2.example.com/ - wss://relay3.example.com/ - Followee's Write Relays (フォローイーが書き込んでいるリレー) - wss://relay4.example.com/ - wss://relay5.example.com/ - wss://relay6.example.com/って出して、チェックボックス付けてON/OFFできるようにして最終的に購読するリレーをユーザーに決めてもらう感じかな……って漠然と考えています。よほど時間を持て余したときがあればやってみるかも。
あとリレーを数は仕方ないとしてリレーごとにフォローイーの投稿だけを取得するようにした方が理にかなってるよね。全部のリレーから全部のフォローイーの投稿を取得しようとしたら(実装はシンプルで楽だけど)通信量が大変だよね。 rx-nostr の Forward Strategy ってリレーごとにREQかえて一度に購読できるっけ？
常にひとつ以下の REQ サブスクリプションを保持します。
って書いてあるから無理なのかな？ あとReadリレーは純粋に自分へのメンション(pタグ付き)イベントのみを購読するようにした方がいい気がする。スパム対策としてかなり有効だと思うので。スパムはNIP-65に準拠したりはしていないでしょうし。 まぁ、NIP-65に準拠していないクライアントからのメンションは届かなくなってしまうわけですが。