Avatar
teatwo
3589b793b977c4f025175afd792e7c51d26ef683b45cbc66c56c4d14ad53847e
teatwo is derived from "T2". Author: https://api-docs-30b126.gitlab.io

リレーサーバにREST APIも用意できないのかな?そしてクライアントに低回線モードみたいなのを用意する。オンにするとweb socketを切断し10秒に一度のポーリングに切り替える。みたいな。

Nostrはクライアントが本体の考え方だからなあ。つまり、クライアントにキャッシュしているデータがマスターくらいの勢いで考えるほうがプロトコルデザインとしては正解ではと。

まあNIPにフィードバックされそう、あるいはされてそうではあるけど。

snortからのzapなら1.自身を公開する、2.匿名にする、3.そもそもzapイベントを作らない、を選べますね。Nostr、クライアント毎に豊かに違いすぎて他を確認しきれないが独自仕様(NIPには記載ない)であるのは間違いないかな。

へえw snortからやってました。念のためにコメントを転記すると「zap三枚!(座布団風)」と書いてました。ギャグの説明は疲れますね。

そうそう。クライアント側では小手先だとむずいと考えています。WSSではなくhttpのAPI用意してもらうとかしないと、ユーザー作業でリレーサーバ一本にするくらいしか抜本的な問題解決できなそう

投げ銭する人のクライアントでNostrイベント作ったりするので

履歴だと1件だけどその後の数件出てないのはなんでじゃろ。利用クライアントがzap対応してないってことかな。

FiyPegZEfYdUdWQF8qsfK4iHさんありがとうございます

love@current.tipsさんありがとうございます

kuriさんありがとうございます

zapprさんありがとうございます

Cq3osX5FbUG9izaMPApSaA7Mさんありがとうございます

zappr@semisol.devさんありがとうございます

d23pGgvk8hGQatgFHyMtyK1Xさんありがとうございます

yutaroさんありがとうございます

Nostr、Wi-Fiでしか使えない問題はどうなっていくかな。そういうためのリレーサーバを用意くらいしか思いつかないんだよな。

おお、ほんとだ。ついにalbyにもzapきてる

zeus+umbrelで困ることは、インボイスの履歴取得ぐらいですね。アクティブリバランスしていると大量の未払いインボイスにガチの支払いが埋もれて機能しない。settleしたものだけのフィルタ条件が必要である。

サーバ代の負担をどうモデル組んでくるのかは注目点の一つ。一私企業でやっているのは明白なのでBlueSky社が持つのか、それとも一私企業の関与を下げたインセンティブ設計を投入してくるのか。

IPFSにするなら世代別管理になるのはディスティニー(なぜなら更新するとCIDが変わってしまうので)

did:pls、DID document更新や鍵の回復にガチフォーカスしていて、あ"ーーーってなった。