iqbqioza.com

デックのようなクライアント作っていると、「このリレーから投稿を削除」が欲しくなる。リレー限定で投稿できるから、逆にこのリレーから削除がないと非対称になっちゃう。

うっかりホームから全リレーに配信しちゃうからその対策。

汎用リレーだとなんでも溜め込んじゃってすぐリソース枯渇するのでもうすこしリレー運用うまくなりたい

リレーは目的別にリレーを分けて kind をそれぞれ制限したほうが、運用上エコにはなりそう

NIP-29:
groups.example.com

Blossom:
media.example.com

Inbox:
relay.example.com/inbox

Outbox:
relay.example.com/outbox

Ngit:
ngit.example.com

みたいに。それぞれ専用の kind を保存するような運用が理想で、fiatjaf氏がそう推奨しているっぽい、

まあ、画像も URL が SSL 証明書が無効な場合も変わらんけど、殆どの場合は自作しないで既存のアップローダーに上げて発行されたURLつかうからいいけど、NIP-05 は自分でやるから設定間違える人の数が画像の URL より圧倒的に多い。

引用のメンション先の人のnpub1でウェブクライアントでみるといいよ。理解できるはず。

この人にアドバイスしたのがきっかけ
note1mq9lksput6xmn073qvanrl5fhqk62yh0cpg5vdkkqmjk9n50euyq6jw8km

Picture は Primal だとプロキシしてくれるからなあ

WebSocket 失敗のエラーはまあ全然いいとして、nostr.json 系のエラーがコンソールで真っ赤になるのはいただけない

ブラウザクライアントで NIP-05 はおそらく自作APIでもなんでもいいのでプロキシしたほうがいい。たまに CORS ちゃんとしていなかったり、404だったり、最悪なケースは「SSL検証ができない(SSL証明書を間違えてる)」人のアカウントの投稿がタイムラインに流れてきた時点でブラウザが「安全ではないサイトです」になる悪魔が潜む。だから NIP-05 はサーバーサイドで検証したほうがいい