でもnos2xでよくわからんのを雑にreject foreverしたらlikeとかできなくなっちゃった
Nostr、数か月ぶりに触ったら全て壊れてるんじゃねーかと思ったけど動いてそう
Nostrあんまり見れてなかったけど、技術書展に同人誌出すんですね。がんばれがんばれ
#[2]
すみません最近見れてませんでした！
質問それぞれ以下のような感じです。
> のす本にあなたの作ったクライアントの記事を載せてもいいですか？
はい、大丈夫です。よろしくお願いします。
> 多くてもざっくり200文字くらいで、記事を依頼してもいいですか？
こちらも大丈夫です。最近Nostrを見れておらずのす本がどういう状況かわからないのですが、スケジュール等共有いただければそれに間に合うよう書き上げます。
そういえば、GARNETはモバイル対応した方がいいのかな～と思ってたけど、Amethystは任意のチャンネルに入れるっぽいのでやらんでええわとなった
bech32なIDのデコードは折角なので @scure/base を使って実装した。別にnostr-toolsでも良かったけど、デコードの失敗が例外として出てくるのはあんまり好きじゃなかったので
EOSE待ちでerrorやcloseになったら擬似的なEOSEを発生させてgracefulに死に、Subscriptionを止めない等
WebSocketを管理するのはどうやっても難しいし壊れるので、WebSocketがどう壊れても(アプリケーション上の)Subscriptionはちゃんと動く、というデザインにする方が多分簡単という見通し
どのリレーに繋いでるかを絶対に意識したくないので、いつどのタイミングで接続先を切り替えても絶対に壊れない接続管理がしたい
ある程度jsで書いたんだけど今tsで書き直していて、tsは慣れてないので時間がかかる。このpushしたやつも、多分全然まだ動かんと思う
盆栽接続管理をとりあえずできてるとこまでpushした
しかし部屋の乱立具合がすごいので、フィルタは必須すね
盆栽コネクションプールが動くようになってきたのでPublic Chatクライアントを作り始めた。
何するか何も決めてないけど、nostrian.net ドメインを取った
少なくともSnortは検索用のリレーを relay.nostr.band でハードコードしていて、これがNIP-50をサポートしてるよ(って前 #[0] さんに教えてもらった)
https://github.com/v0l/snort/blob/main/packages/app/src/Const.ts#L52
Nostrを部分的に利用するサービス(イベントをDBに保持するとか)を考える場合、多分
1. サービスはnote(event)のidのみを持ち、クライアントがリレーに問い合わせて内容を解決する
2. サービスがnote全体(id, pubkey, sig全部)を持っておき、それをクライアントに返して表示する。その際クライアントは署名の検証は行う
3. サービスがnoteの一部を保持する(contentのみとか)
の順で好ましく、これは論理的にどうかというより倫理的にどうかという話で、3の場合署名の検証ができないので、それは耐検閲性をうたっているNostrでどうなんだという話がありますね(サービスが内容を改竄できるので)。
個人的にはまぁやってもいいとは思うけど、署名の検証してないなら一言断るくらいがフェアだと思う。
1と2は別にそんなに差は無いかも。実装のし易さなら2の方が好き勝手できてやりやすかったり。
Nostr勉強会、空きがあったので登壇者登録した
