ryo_grid Nostr posts

NostrのGitHubリポの説明、斜め読みしたけど、この手のものにしては筋良い方かなーと思った。
リレーサーバをホストしたとした時にどの程度リソース食うのか気になったけど。
Drums公式のもユーザ増えてったらどんどん増やすのかな。

気になりポイント
https://mobile.twitter.com/ryo_grid/status/1622400938899279872

Nostrというか、その上で分散Twitte的なことをして、どの程度のユーザ規模までスケールするかなー、という話を読んで考えてみたが、現時点の仕様だとリレーサーバがどれだけのユーザとWebsocket接続を維持できて配信ができるのか、かなと。
全体のユーザ数が増えた場合、フォローするユーザも増えていく傾向にはなるだろうし、何万ユーザとかにフォローされるユーザも出てくるはずで、そうすると配信先クライアントは傾向としては増加していくはずで。
リレーサーバを増やしてユーザが主な住処にするサーバを分散させたら緩和はできるかもだけど、クライアントの負荷は増すし、そのリレーサーバ誰が立てんの？ってなりそう。
（そもそもの使用に誤認があったらすまそ）

リレーサーバはユーザのメタデータ持ってたり、いくらかの時間は受け付けたポストをキャッシュしてるっぽいけど、そこらへんもどこまで耐えられるか、という話はあるだろう。

っていうか、Nostr（雑）だと250文字制限ないんすねw

ワイも認証して青バッジみたいなのつけるか。後で。

いや、既についてるな。んんん？

Vの人もいるのかー

Nostrのシステムをスケールさせようとすると、モバイルデバイスではこういうこと（バッテリ消費）も問題になるんだよなー多分。
https://iris.to/#/post/note1nlaknpt8l5mprztxvp4r7kp0fwvjdtlsxxxckyke33sxpnmarpvsy7cdju

Nostrのプロトコルの上で可能なのかは知らんけど、そのうち、ここらへんのログ持ってるやついたらくれやーみたいなメッセージがリレーサーバを介してクライアント間でやりとりできるようになって、元気玉方式で過去ログが集められる、みたいな風になったりして。
多分、破綻するけど。

リレーサーバが保持しきれないってなったポストのデータは、しれっとBitTorrentのDHTにぶっこんじゃうとか・・・
（Torrentのクライアントからは、Magnetリンクやらの情報に見えるようにエンコードして）
で、遅いけど、手に入らないログがあるクライアントはそっちから引っ張ってくるとか・・・。

尚更よくわからんアーキになるなー

既にあるかもしれないけど、クライアントの代理で登録してるリレーサーバから流れてきたデータを集めておいてくれるデーモン（クライアントからはリレーサーバに見える）みたいなのを作って、自鯖とかで起動させておけば、メッセージの抜け落ちとか避けられそうだし、クライアントが接続するリレーサーバは、そのリレーサーバプロキシみたいなの一つでOK（投稿の中継もよしなにしてくれる）とすれば、クライアントの処理負荷も減って良いのでは、とか思った。

誰かが作ってくれれば、それを動かすぐらいのことは、Twitter嫌ってNostrに移ってくる、ないし将来の懸念からサブで使っておくか、みたいな人ならやるでしょ。多分。

別にこれといって変わったアーキではなかったからじゃないですかねえ

接続してみました！

Amethyst なる Androidでもまともに動く Nostr クライアントを導入したので、捗る。
（ iris.to は泥のChromeで使ったら、投稿が固まってできなかった）

NostrだDamusだ、かとツイしてるとツイアカ凍結されるのでは・・・
((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

Nostrのポストって普通はクライアント経由じゃないと見られないよな・・・。
さて、そのうちGoogle先生は力業でクロールしにかかってきたりするかな？

wss://nostr-relay.google.com 快適ー、みたいな未来が来たら笑うな

まあ、それをやるかって話ですねw

wss://nostr-relay.twitter.com が来た方が笑うな。イーロンならワンチャン・・・

システムアーキからするとそうなるんじゃないでしょうかね？
リレーサーバ間でPostをリレーするわけではないはずですし。

そうなんですよね・・・。
とはいえ、あるユーザが主な住処にしているリレーサーバを変える、もしくはリレーサーバが死んだとかで変えざるをえないケースはあるはずで、ある公開鍵を持ったユーザが接続してるリレーサーバを問い合わせる、とかはアーキ上、できるんじゃない・・・かな・・・。
ただ、自動で見つかったリレーサーバへの接続を追加してくれるほどクライアントが親切かは知らないですが・・・。

日本Nostrユーザオフ会を開催する機運？

ウェブクライアントはChromeのデベロッパーツールとかでどんな通信してるか簡単に見られるのが技術者視点だといいね

デベロッパーツールでの出力
https://nostr.build/i/nostr.build_2c01e8438bb815d1993e110292131429893f5de38651dce1c7096b7d3dd13bb1.png

Chromeデベロッパーツールで解析し放題やー

Damusでデフォルトで接続してるリレーサーバの実装ってどれなんやろ？
リレーサーバのOSS実装は複数あるようだけど。
OSSなやつではなかったりする？？？

情報ありがとうございます!

あ、でですね、それらのリレーサーバの実装はどれなんだろうなーとか思ったんですね。
ここなんかには複数のリレーサーバの実装が載ってたりするわけなのですが。
https://github.com/aljazceru/awesome-nostr

しょうがない。俺が考える最強のリレーサーバを作るか（いつかは言っていない

TwitterではPublic Timelineが日本での黎明期の途中あたりだったかな、になくなりましたが、それでもワークしているわけなので、globalとか別にいらんのだと思っています

Damusというのが出てきたというツイを見かけた時は、はいはい、またWeb3.0とか曖昧なこと言って、ブロックチェーンでTwitterもどきやりますみたいな胡散臭いやつやろ？
って思ったけど、Nostrの考案者は思いのほか、リアリストで驚いた。
（全てクラサバのノードでP2Pでやる、みたいなのを一蹴しているあたりは特に）
私は、全ノードがクラサバみたいなモデル好きなんだけどね。
でも、モバイルデバイスで使えるようにしようと思うと無理筋だよね。頑張ればやってやれないこともないかもしれないけど。

自分が把握している限り、クライアントはリレー間の中継はしてないんじゃないかなー。
リレーサーバに対しては一方的にポストやらメタデータよこせって言うか、自分のポストやらメタデータを送り付けるだけ、という認識。
あるリレーサーバから手に入れた他人のポストを他のリレーサーバに送り付ける、とかしてればリレー間の中継をしてると言えそうだけど、そういうことはしていないはず。
でも、そういうことをクライアントが（分別をわきまえて）やるようにする、というのは何らかの課題の解消にはなるかもで、面白そう。

Nostr側に投稿したPostを自動でツイターにも投げてくれる何かが欲しくなってきたな

Amethystもiristもそれぞれ良いところがあって、悩ましい。
まあ、PCでAmethystは使えんけど（頑張れば使えるとか、使える環境とかもあるかもだけど普通は）。

Damusだと認証されていると表示されるが、iris.toだとバッジみたいなのが黄色にならんなー。
.htaccessも置いたのだが―。

なるほどー。情報あざます！

黄色いバッジみたいなのが出ている人はNIP-05認証をしている人で、フォローしていない人、という意味であったようだな。

検閲がないなら、エチチ画像とか貼り放題では！

Nostrなのか、その上のアプリのレイヤなのかしらんけど、ビットコインを送れるようにした理由が謎。
うさんくささ増すのでやめて欲しい。

リレーサーバって、over Nastr でTurnサーバの代わりに使うとか、いけないことできそうな気がするのだけど、さすがにサーバ側からBANされるかな。
どうしても、そういう活用法を考えてしまうんだなあ、私は。

時価一万円くらいのBTCもらえるなら、ワイも乞食する

おはようございます

DamusなんかのクライアントもOSSなのか。
それならカスタマイズし放題やな。

Twitterでの投稿ってInternet Archiveでもさすがにさほど残らんのかな？

Nostrクライアントを改善したい、というか、自分の欲しい機能を持ったクライアントが欲しい、と思ったら iris にプルリク送るのが一番手軽かな？
https://github.com/irislib/iris-messenger

Amethystでもいいか（I am Androidユーザ）
https://github.com/vitorpamplona/amethyst

プロフに追加しておいた。
----
Nostr関係なく、曖昧にWeb3.0とか言ってる人たちは嫌いです．
誰でもいいですが本当のWeb3.0を見せて欲しいです．
----

仮にNostrで200ユーザくらいfollowしてて、それらの全ユーザが自分用のリレーサーバ立てていて、Postをそこにしか投げてなかったら、200台？のリレーサーバに接続しとかないと、followしているユーザ全員の投稿を取得できない、というのがNostrのアーキなのだと思ってるのだけど理解あってる？
（普通は耐故障性を意識して複数のリレーサーバに投げつけるようにしてるだろう、というツッコミはさておき）

NostrでTwitterオルタナティブをやるとして、スケールさせようとしたら、クライアントサイドでロードバランシングする、みたいな仕組みがあればいいのかな、とか妄想した。
主な住処にするリレーサーバを負荷に合わせて自動で切り替えて、冗長性確保のためにPOSTとか投げつけるリレーサーバもよしなに切り替えるようにしてもろて。
リレーサーバは増えすぎると接続しないといけない数が増えてクライアントが死ぬので、サービスレベルが一定水準を下回るまでは、みんな接続先の切り替えで勝手に集約されていってもらう方向で。
GlobalのTLとかいう機能は捨てる。
有料サーバとか使いたい人らはそんな出てくるとは思えないので、好きにしてもろうて。

リレーサーバ間の接続ってあるんでしたっけ？
ある公開鍵に対応するユーザがPOST投げてるサーバを探したりするのに必要？
（そういう機能が存在するのか自体、ちゃんと把握してないですが）

クライアントが橋渡しをしているという認識も私は無いですね。
あくまで、
・followしているユーザのPOSTを、そのユーザがPOSTを投げつけているリレーサーバにリクエストする
・自分が投げる先として指定したリレーサーバ（複数可）に自分のPOSTを投げつける（プロフィールやフォロー・フォロワー等のメタ情報も投げつけているはず）
の２つしか基本的にはやっていないはず。

followしている相手のユーザがPOSTを投げつけているリレーサーバが分からなくなった際にどうするのかは良く分かっていません。
（当該ユーザが投げつける先のサーバを変えてしまった場合など）

前に書いたモバイルデバイス等で複数のリレーサーバと接続してあれこれするの辛いから、自分用のリレーサーバお束ねプロキシみたいなのを用意したらよくね？って話だけど、irisの重たい処理するところだけバックエンドサーバみたいなものに切り出して、フロントはそれのAPIをよしなに呼びだすだけみたいな構成にすりゃそれで済むのでは、とか思った。
irisの更新に追従していくのもうまく書けばよしなにできる・・・かもだし。
とか妄想したryo_gridでした。
誰かお願いします！

NFTはごく限られた真面目なユースケースを除いて詐欺だと思っている種の人類です。
信仰で買うのは好きにやってくれりゃいいけど、儲かるからとかいって売りつけてるのはすべからく詐欺です。

Nostr以外の話をするなら別に私はTwitterでいいので、みんなNostrの話をしているうちがNostrの旬かな、とか思っている。

リレーサーバを一つだけにしたらどうなるか試してみるので、投稿が見えなくなったりしたら後で教えてください～

むむっ、irisでリレーサーバを1つにしてみたが、disconnectしたやつが徐々にconnect状態に戻っていったぞ。
どういうこっちゃ。

followしてるユーザがいる（POSTを投げている）サーバには勝手に再接続してくれる仕様なのか・・・な

なるほど。てへぺろ。

リレーサーバ戻してみた

というか、リレーサーバ減らしたらfollowしてるユーザTLの流量落ちたので、まあ、そういうことなんだな。

私をfollowしてた方で下のPOSTが抜けてる方いますか？

https://nostr.build/i/nostr.build_5d5efa8fc582c4a8dec983f938bdc97adf11ec118d1cc12d1a7cbcae9f5eb99a.png

画像がでかい・・・

どもども。
ふーむ。私が上のPOSTを投げたリレーサーバにZaorikuさんが接続していないために抜けた、と解釈すればいいのかな。

フォローしてるユーザが、自分が接続しているリレーサーバのいずれにもPOSTを投げなくなったら、そのユーザが現在POSTを投げているリレーサーバを知る手段は無いし、当然POSTも受信できなくなる、という理解であってるかな。

そういうことを避けるためにも、1つだけでなくいくつかのリレーサーバにPOST投げつけておく必要はあるんだろうな。

そうですね。主要なリレーサーバは限られていますし、多くの方はそれらに接続してますからね。

まあ、リレーサーバがサービス停止したりしていっても、いきなり丸っと死んだりしなければ、コネクティビティは維持されるだろう、という想定だと思えばいいのか。

Nostrのある意味で良いところは、リレーサーバがただのWebsocketサーバで、プロトコルもテキストベースでJSONのやりとりしてるだけ、という単純な仕様なところだと思っている。
パフォーマンスを考えれば良い選択かは怪しいけれど、技術者にいろいろいじってみようかな、とか、リレーサーバやらクライアントを作ってみようと思わせるには都合が良かった。
そこらへんが個人的には今のムーブメントの面白いところだと思っている。

まあ、現状の仕様でもアーリー+αぐらいの規模ぐらいまでは多分スケールするんじゃないかな、と個人的には思うし。
（今の仕様だとTwitter規模のユーザのサポートは多分無理）
スマホなんかのモバイルデバイスでの利用は通信料やバッテリ消費等で既に課題があるが、そこらへんはクライアント側の工夫で、まあどうにかなるだろう。

推奨リレー・・・。なるほど、そういう仕様を実装することもできるんですね。

報告あざます！

クライアントがブラウザ（ブラウザJS）で実装しやすい、というところもあるかな。
Nostrはそのあたりを元々意識していたのかもしれないけど。

さすが手が早いなぁ

おはようございます。

私もNostr上で動くアプリケーション書いてみたくなってきたぞ！
しかし、自作RDBMSの実装も進めたいしなあ。
むー。

Nostrなアプリケーション（というかは怪しい）だけど、デモ的に都合が良いものという制約をつけると、
ただただ、主要リレーサーバに流れてるPOSTをクロールして、言語判定して、日本語のものだけアグリゲートして垂れ流すWebサイト、とかぐらいしか思いつかないな。。。
今日のNostr（日本）みたいなやつ。
データ集積したら、どれぐらいの勢いでストレージ食うかな。。。
こういうの作ったらGoogle先生もインデックスしてくれるかもね！

リレーが返すイベントが何のアプリケーションのものなのか判別する方法ってあるのかな。
例えば、リレーサーバは専用に立てたのかもしれないけど、仮に立ててなかったとして、掲示板もどきのイベントとTwitterモドキのイベントは区別可能？

どんな実装がいいか考えてみてるけど、サーバ負荷的に検索まではサポートするの辛いかな・・・。多分。
（Bigtablesとか富豪的なソリューションを使わない場合、）DBが死んじゃう・・・。

なるほどん。
うーむ。ただ、気になるのは既存のアプリケーションがちゃんとタグつけてくれてるのかってとこだなー。
Twitterもどきとか、つけてるとしたらどんなタグなんやろ・・・。

お外でNostrなう。なおアメジスト。
パケ死が怖いにゃん

タイムリーな情報あざます！

アメジスト更新したけどグローバルの無効化の設定かわできなあ。。。
むーん？

刻々と消費されていく通信量

あれか、野良ビルドじゃないとまだ対応してない的なやつか！

アメジスト。GitHubから最新ビルド入れたら、グローバルがshow moreっての押さないと流れなくなったから、これで切れてるのかな。

リレーサーバを設定する画面で地球のアイコンを非activeにすればいいのか！
理解したぞ！

私のポスト見えてますかー？

ファボってもらえたので大丈夫っぽいな

報告あざます！

うわああああ。（グローバル切る前）
https://github.com/ryogrid/ryogrid.github.io/blob/3dfb07f9e236a6acc05bd4ba638ac8ffff00e86b/Screenshot_20230208-082924.png

昨晩の充電し忘れもありバッテリ残り4%....
Internet addicted な person としての死が近づいている

アメジストで、フォロワーのポスト読めて、自分のポスト投げられて、ファボとかが機能すれば良いだけだったら、リレーサーバの設定のとこで、4つあるアイコンの一番左の家の形したアイコンだけアクティブにしておけばいいのですか？

確かに工夫の余地がたくさん残されているといえ見方はできますねw

LinuxサーバにCLIで動作するクライアント入れてSSH接続してNostrやればいいのでは！
ひらめき！
Linux環境かつCLI環境で動くクライアントあったか忘れたけど。

それ知ってて、使うこと考えたけど、最初からCLI想定のクライアントの方がいいかなw

そういえば、わたくし、気づいてすぐ消したけど、ツイターに秘密鍵貼ったツイ投げたりしちゃったので、自分はそんな馬鹿なことしないって思っている人ほど気をつけた方がいいと思います。
自動車とかで運転慣れたなーって調子乗ってるやつの方が初心者より事故ったりするのと同じ。

10さとしって日本円で大体時価いくらぐらいなのん？

0.00000001 BTC=1 Satoshi なのか。
今のBTC相場は3,036,788.79JPY あたりらしいので
10satoshiで約30銭？
これでウォレットやら取引所やらLightning Networkのユーザが増やせるなら安い出費だね。
（私はBTCを保有していた時期もありますし、仮想通貨も否定しないですが、微々たる額を配る・もらうことに何の意味があるのかはよく分かりません）

そうっぽいですねー

333万satoshiぐらいください

このアカウント（？）も、そろそろ精読のNostrアカウントに整理していくか。
（一部の人は覚えているかもしれないネタ）

面白そうなことしてるなーと思ったのですが、このような構成をとることのメリットはどういったところなのでしょうか？
自身の使うクライアントはVPS内に置いた自前のリレーサーバだけに接続すればよく、複数のwss接続を行うことが避けられる？
それとも、イベント情報を自前のリレーサーバに集積できる？

なるほどー。
ご回答あざます！

Nostr、テキストベースのプロトコルなのに no str とはこれいかに。

再びアメジストでお外Nostrなう。
CLI環境かつLinuxで動くクライアント探すか。

私ほどのハッカー()になると、スマホからでも自鯖にDSHできるようにしてあるのでね（謎のドヤ顔

/nostr_console_linux_amd64: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by ./nostr_console_linux_amd64)

　　終
制作・著作
━━━━━
　ⓃⒽⓀ

SSHです。
ハズカシー（頬を赤らめながら

確かに人的リソース的に辛そうかもw
でもまあ、AWSに移行してたはずなので、負荷が増してもよしなにインスタンスとか増えてオペレーションコストはさほど変わらないんじゃないかという気もする。
あるとすれば、ユーザのサポート対応のところでしょうかね。

あー、いい加減いらついてきたので、こんな時間からだけど自鯖 at VPSの再構築するかー
（ディストリのアップデートやらなんやら）

結局、今はサーバのディストリ何にするのが安定なんやー

Lets's Encryptの設定がうまくいかねー

鯖の最低限の移行はできたので寝よ・・・

nostr-tools（JS）が色々揃いすぎてて、フロント不要なもので何か作るならgolangかな、と思っていた心は少なくとも折れそうになっている。
（絶対にに何か作る、と決めたわけでは無いし、やるかもわからん話ではあるけど）

ちょろっと調べたり、VPS業者が提供してるディスクイメージのラインナップから判断してRocky Linux にした。
まあ、そんなのが出てきたって話はだいぶ前に耳にして知ってはいたが。
なんかパッケージシステムのコマンドがdnfとかいうのになってるけどyumも使えるし、ただのyumのラッパーかな？と思ってセットアップの大半では普通にyum使ってしまった。

ただ、一本にまとめればいくらかクライアントの負荷は減るだろうけど、ただ束ねるだけだと通信量はあまり変わらないし（クライアントから見たアウトバウンドの通信は減るだろうけど全体に占める割合は少ないはず）、プラスαで気の利いたことしてくれるようなものでないと、例えば、モバイルデバイス死亡問題のソリューションとかとして考えるとしたら不足な感じはしますね。

いいと思います！

パスワードを定期的に変えられないというのは確かにそうですね。
慧眼だ。

DM、せっかくE2EEしてくれるのに、秘密鍵が漏洩したら怖いから、とかの理由で使われないとしたら寂しい感じはあるな。

自鯖をなんぼか整理したので、NIP-05認証をそちらの鯖 ( ryogrid.net ）でやるようにしてみた。
まあ、私の場合、どちらも意味合いとしてはさほど変わらないけど、本人認証という意味ではスッキリ感あるね。
ちな、GitHub Pagesじゃない場合、確かに .htaccess を適切に置いてあげないと Damus以外は認めてくれなかった。

MisskeyとかBlueskyとか存在すら知らなかった。
ここは勉強になるインターネッツだなあ。

これ。
NostrのGitHubレポのトップに書いてある文言とか読むと、結局ボランティアがリレーサーバ立てとるやん、というツッコミはあるけど、とはいえ、リレーサーバを提供する側の心理的な障壁が格段に低いという点は着目すべき点だと思う。
（いつやめても、そんなに迷惑がかからない）
で、クライアントがそもそもどのリレーサーバもいついいなくなるか分らんという前提で自前で冗長性を確保する仕様がそれを成立させていると。

既に、NostrでDiscordモドキを作るというプロジェクトは見かけたことあるので、二番煎じ感あるけど、Slack的なグループチャットモドキモドキをNostr上で作ってみたりしようかな、とか思った。
（日本語話者による投稿と思われるPOSTをアグリゲートするようなものを考えたりもしていたが、既に別の方が作られていたので、それはやめるかなと）

Web3というバズワードが氾濫しているが、そもそも多くの人が同意する定義ってあるのだろうか？
Web2.0ですらかなり怪しいと思うのだけど。
誰が提唱し始めて、皆がその人物を知っているとかいう話なら、まあそれが定義でもいいと思うが、そういう話なのかな。

Web3、イーサリアムの人が言い始めたのか・・・。
以下、"Web3"のWikipediaのページ (JP）冒頭を抜粋。

----
Web3（ウェブスリー）とは、次世代のワールド・ワイド・ウェブとして提唱されている概念である。分散化・ブロックチェーン・トークンベース経済などの要素が取り入れられており[1]、一部の技術者やジャーナリストは、「ビッグ・テック」と呼ばれる大手IT企業にデータやコンテンツが集中しているとされるWeb 2.0とこれを対比させている[2]。「Web3」という用語は、2014年にイーサリアムの共同設立者であるギャビン・ウッドによって作られ、2021年に暗号通貨愛好家や大手IT企業、およびベンチャーキャピタルなどから関心を集めた[2][3]。Web 3.0とも呼ばれる[4][5][6]。

一部の評論家は、「Web3は、ユーザーにより優れたデータ・セキュリティ（英語版）、スケーラビリティ、プライバシー（英語版）を提供し、第三者が簡単にアクセスできる方法でデータが保存されなくなる為、ユーザーは民間および政府の監視からより適切に保護される。」と評価している[7]。一方、分散型ウェブ（英語版）について、モデレーションの低下や有害なコンテンツの拡散[8]、少数の投資家や個人への富の集中[9]、より広範なデータ収集によるプライバシーの侵害[10]などの可能性を懸念する声もある。また、イーロン・マスクやジャック・ドーシーなど、Web3は単なるバズワードやマーケティング用語でしかないと主張する者もいる[11][12][13]。そして情報の双方向性を特徴としたWeb2.0では、ブログやwikiやBitTorrent（P2P）などの日常的に利用するウェブサービス群があったが、Ｗeb3にはそれらが見当たらないという指摘もある[14]。

単に分散したWebでいいなら、ガチ勢が検閲耐性とか持たせて設計・実装して実際にワークしているFreenetというのが2000年には現れてますよ。
https://ja.wikipedia.org/wiki/Freenet

ひとまずNIPs斜め読みするぞ！
https://qiita.com/gpsnmeajp/items/5f22b7a96422fecc7ece

考えてみたらグループチャット機能、元からあるやんけぇ！
（作ってみようかな、とかほざいていたがNIPsを斜め読みしていて気づいた）

ほほう。
情報あざます！

Nostrのリレーサーバのストレージを、よろしく自前のアプリケーションでストレージというかファイルストアというかとして使っちゃってもいいよなーとか悪いこと考えていたが、既にやっている人がいた。
https://github.com/cmdruid/nostr-storage
（GitHubの nostr タグをつけているリポジトリを眺めている）

みんなでお絵描きできるアプリ作ろうと思ったけど思いのほか面倒で、点描画が描けるだけのものができました・・・。
遊んでみてね！
https://ryogrid.net/dist/nostr-paint/index.html
HTMLファイル一つに全て収まっているので、実装も丸見え！

なお、GitHubリポジトリはこちら。
https://github.com/ryogrid/nostr-learning
プルリク歓迎。

しかし、今の実装だとページを開いて以降に他の人が打った点しか見えないんだよなー。
なんかページ開きっぱなしでも、時間が経つと他の人が打った点が反映されなくなるような気がするし。
面白みを増そうと思ったらまだ工夫が必要であるな。

同時にいじっている人がいないとコラボレートできないクソ仕様なので、2つのタブで開いて試すか、知人・友人と一緒に遊んでみてね♪

さておき、現仕様だと、接続してるクライアントらにメッセージををブロードキャストtするWebsocketサーバが1つあればできることなので、Nostr使ってみた事例としてはかなり微妙なんだよなー。うーん。

異なるアプリケーションが同じリレーサーバ群を利用しているときに、個々のアプリケーションが自身があつかうべきイベントであるか区別できるようにする考慮がNostrプロトコルの仕様の中にあるのか？というお話でしょうか。
それであれば、私としてはある、という認識です。

もし、Nostrプロトコルを用いる個々のアプリケーションの中でのことをおっしゃっているのであれば、それは別途仕様をまとめて合意をとるしかないですよね。基本的には。

XMLスキーマ的なNostrプロトコル専用の仕様記述のフォーマットがもしあればなんぼかラクにはなるでしょうが、まあ限界はありそう。

なるほどですー

余談ですが、ブラウザの開発者向けツールのコンソールに受信したイベントのオブジェクトをデバッグ出力してるので、今回利用させてもらっている nostr-emmiter という便利ライブラリが何しとるのか見えたりして、それはそれで面白いです。

少なくとも今の実装だと、何分か放置しておくとリレーサーバとの接続が切れるっぽいなー。
ブラウザ側が切ってるのか、サーバ側が切ってるのかは分からんけど。
うーむ。
もしかすると、event-emmiterライブラリが、イベントのkindにTwitterモドキが使うものとは異なるIDを指定しているようなので、サーバ側がなんやこれ、切ろ、ってなったりしてるのかもしれない。

みんなで点描画（）アプリ、一定時間でリレーサーバとのコネクションが切れているのは確かなようだったので、使ってるライブラリのコード読んで再接続するようにしてみた。
その他、コラボレートできるようになるかな・・・という感じの修正を入れた。

https://ryogrid.net/dist/nostr-paint/index.html

https://nostr.build/i/nostr.build_f6e3bb942cd08afc3dd6e8a7601fe6819524e52e840a174c80fe73cfd792e06e.png

メンション先のpostの要旨からは離れてしまうのですが、このBBSの書き込みというのはどの程度の期間、消えずに残る想定なのでしょうか。
リレーサーバがイベント情報をどれだけの期間保持しているかに依存するのかな、と思っているのですが、何か特殊な特殊なギミックが仕込んであるのでしょうか？
（例えば、書き込まれてから一定期間経った書き込みは内容の同じ別イベントとしてとしてリレーサーバに投げつけて保持し続けさせるとか）

単純に技術的な興味からの質問であって、他意はありません。

なるほど！
回答あざます！

おはようようございnostr

BlueSkyが気になり始めている私。
アーキとプロトコルだけでいいから早く公開して欲しい（ほとんど全部やんそれ

Nostrのコンセプトを下敷きに、俺が考えた最強のTwitterオルタナティブ用プロトコルを提案するか。
凡庸なものにはなりそうだけど。。。
さておき、BlueSkyはマスト丼とそんな変わらんやん、みたいなものでないことを祈る

クラサバ一体のTwitterオルタナティブのプロトコルないし、仕様化すっ飛ばして実装だけありますみたいなのって結構あるのかな。
存在を聞いたことないが。
モバイルデバイスの存在を考えると無理筋なのは分かるとして、その手のものでの他の課題ってなんだったんだろ。
メッセージ届くのが激遅とか抜けるとか、そんな感じだったのかなぁ。
（NATの問題はその手のものでいつもあるけど、グローバルIPを持ってるノードがいくらかいれば、リレーしてもらったり、UPnPやらホールパンチングやらでどうにかできなくもない。。。と思うんだけど）

掲示板だけど、新月というクラサバ一体型のP2P方式でちゃんとワークしてるものもあるのよね。
（新月がリファレンス実装で、他の実装もメイン開発者の人がいくつか作っている認識）
2ch閉鎖騒動の時に、移行先になるか？と少し話題になったりした。

新月
https://shingetsu.info/

ああ、Webゲートウェイから閲覧はできるので、クライアントが一体になっていると言うと語弊があるのか。

クライアント一体型というのは嘘でした。失礼。
（サーバを提供するインセンティブとして一体となっている点は重要）
ただ、マスト丼とかNostrと違って、サーバがNAT内のPCなんかでも立てられるというのは割と異なる点かと。

NATのポートを自分で開けないとだめだったわ・・・。
それだったら、グローバルIPを持ってるサーバと本質的にはさほど変わらんな・・・。
嘘情報ばっかり発信してしまい申し訳ない。

実装があるか分からんけど分散ソーシャルメディアプラットフォームの提案的な論文探すか、その手のもののサーベイ論文を探すのが良い気がしてきた。

NostrのTL見続けるの時間的に無理なので、Nostr関連で何か動きがあったかなーとチェックするのはネタフルさんとか見ておけばいいのかな？

おはようございnostr

Nostrの特徴の一つはサーバではなくクライアントが苦労するようなアーキなところだと思っているのだけど、それを推し進めて（？）...

・リレーサーバはBitTorrentのトラッカーサーバ（&HTTPサーバ）の機能も持つ
・リレーサーバは直近のデータは普通に保持する
・一定期間を過ぎたデータは何らかうまい単位でファイルにまとめてBitTorrentの仕組みの上でHTTPサーバ上のファイルとして配信する
　=> クライアントもBitTorrentクライアントの機能を持つ必要あり。またファイルをバラシて自分でフィルタなどする必要あり
・ある程度のクライアントにデータを渡したら、リレーサーバはHTTPでアクセスできるファイルは消して、既にデータを持っているシーダが他のクライアントにデータを渡してもらうようにする

とかどうだろう・・・？

トラッカーサーバとしての役割は、マグネットリンクを生成してBitTorrent DHTが提供するそれ（BEP-0005: https://www.bittorrent.org/beps/bep_0005.html）に任せるというのもありだと思うけど、過去にそこいらの動作を調べてみた時はトラッカーサーバの代用としては少し心もとない挙動な時も多かったんだよなー。

通信量とかクライアントの負荷とか増すので、モバイルネットワークで使うとか、スマホで使う、とかはしんどい形になるとは思うけど・・・。
　
そこらへんはなんかNAT内のPCでデーモン動かしておけば、Twitterクライアントなんかと同様に必要なデータだけ受け取れる仕組みなんかも併せて入れてもろうて。
（本当にNATはこういう時に邪魔）

（トラッカーサーバとしての役割をリレーサーバに追加で担わせることがどの程度の処理負荷の増加になるかも正直良く分かっていないところはある）

今のところSTUNサーバ（NAT越えをする時に必要）はGoogleが提供しているものを使うことができるので、ホールパンチングが通れば、NAT内PCで動かしているデーモンと通信することもできるはず。
Googleが提供をやめてしまったら、リレーサーバにSTUNサーバの役割も載せる感じかな・・・？

ついでに宣伝しておくと、わたくしパンチングが通れば割とラクにNAT越えしての通信ができるようになるツール&ライブラリ for Pythonとか作ったことがあって、Qiitaに紹介記事あるのでよかったら読んでみてね♪

"異なるNAT内のPC間でP2P通信をしてファイル転送したり、パイプをつないだりできるツールを作ってみた"
https://qiita.com/ryo_grid/items/651486649f116700bdae

（共用サーバは、VPSの移行やらで一旦止めてそのままになってるので立ち上げなおさねば）

共用サーバ立ち上げ直しておいた。
over SSL化してあるので証明書回りのセットアップがいつも面倒である。

おはようございノス

えっ、NIP増えてるの...
まあ、それはそれでユーザの要望を取り入れているということで、悪いことではないのだろうけど、あまりペースが早くても考えものであるなあ

最強のNostrクライアントってどれなの？（宗教戦争勃発

スマホ（泥）ブラウザのsnortからの投稿テスト

Nostrのクライアントぐらいのものであれば、プラットフォームネイティブなもの（クロプラ対応のもの含）よりブラウザ向けのSPAとして作ったほうが、最初からクロプラだし、ストアの審査とか待たなくていいから良い選択な気がする。
まあ、泥なら野良ビルド配れるからいいじゃん、という話もあるが。

ブラウザアプリとして作ったときのディスアドバンテージって何かな。
マルチコアを活かしにくいという話はありそうだが...、スマホブラウザでWebWorkerとかServiceWorkerとか動くんかな？

ジムリーダーは草w

クッ、satoshi投げ合うのとか意味分からないとかいって散々disってきたけど、なんか楽しそうだからワイもやりたくなってきたぞ...

まあ、それはさておき、なんでかわからんけど仮想通貨が元々使いやすい環境なら、クライアント開発者やリレー運営者に積極的にdonateできる（すると）いいのかなーとか思う。
donateするならもっと大きな額でやったほうがいいけど、投げあってるレベルのsatoshiでもチリツモでいくらかの額になるかもだし、それでもないよりゃマシかも？

確かにWebベースだと開発がだるいというのはありますね...
HTMLとCSSを駆使できないといかんし。
私も正直、開発者体験としてはあまり好きではない...
　
とはいえ、一昔より、React、Vue、Angularあたりのフロントのフレームワークあるし、TypeScrptなんかのaltJSな言語使えば、型付けもできるしで、大分マシにはなってると思います。
DOM操作もある程度の範囲（制御構文で書けるようなもの）はフレームワークが提供するテンプレートの機能で簡便に行なえるようにはなったと思います。

特定の要素にあれこれする、とかいう操作の本質的な面倒臭さは変わってないですが...
（jqueryを使わずにフレームワークのAPIを使う形で基本はやるようになってます）

satoshiは送れるように設定しようと思いますが、まあ、まずはチョコ送ってください（無理

フリマアプリの匿名配送（お互いの住所や電話番号は隠して物を送れる）みたいなのって、単独で利用できるサービスとかあるのかな。

私も妻からおとといもらいました！

しかし、真面目なことを言うと、対面であったこともない人から送られた食べ物を口にするのは怖いという話はあったりするんだよなw
男性アイドルとか毎年山のようにチョコが（事務所に）贈られてくるが、送り主の髪の毛とか、血とか入ってるケースもなくはないらしいし、気持ち悪いだけで済めばいいけど、命に関わる場合も想定されるので、基本的には廃棄してるって話だったはず。
量的に全部食うのはそもそも無理だろうけどw

LN対応のウォレットをノス垢に設定したでござる！

試しにちょこっと送ってみてもらえるとうれしいでござる！

#[0]
投げ銭あざます！
ちょんと受信できました！

む、そういえば今日は午前中にMTGがあるのだった。
（フルフレックスなのでまだ出勤してない）

投げ銭してくれたかたがた、あざますー

あれ。自分では見えてますし、他の方からの投げ銭もできたんですけどね・・・。
なんでだろう。

おはようございノス

そういえば、どのクライアントでだったか忘れたけれど、フォローしてる人がフォローしてる人か、フォローしてる人がメンションしてる人、を芋づる式に辿ってフォローしたら、新たにフォローしてる人がポスト投げてると思われるリレーサーバがよしなに接続先に追加された記憶があるのだけど、考えてみるとどういう仕組みで実現されてるのだろう。

新たにフォローした人が、自分が元々接続してるリレーサーバにプロフ情報とか置いてなかったらそもそもプロフすら見られないはずだしなあ。

とかいうことを、堀さんの寄稿記事を読んで思い出した。

Nostr、今の仕様のままだと、スケールするのは難しいと思っているので、そこらへんがどうなっていくか次第かなーという感じですねえー。

アメジストのアプデ来てるみたいだから更新するかー

あー、フォローしてる人が登録してるリレーサーバの情報は手に入るので、それらに照会をかけるのかな？

Nostr関連のサービス作っている方にsatoshiを送るなどしてみた。
こういうことが簡単にできるのは素直に良い仕組みだと思う。

Amethystのコードでも読んでみようかなー。
で、なんか改善できそうなところがあればPRでも送るべか。

すみません、私はそのあたりの情報疎いですね。。。
おすすめ度の情報まで分かるかは不明ですが、ウェブ上にリレーサーバの情報をまとめたサイトとか、サービスとかはあった気がします！

Amethystは普通にブラットフォームネイティブな言語での実装のようだな。
（Kotrin。Javaではないがほぼ同じだし、GoogleもKotrinでの開発を現在は推奨してたはず）

私は自鯖でKagoya VPS クラウド、というところを使っているが、VPSなのに時間単位課金で、それ、もはやIaaS型のクラウドでは？と思ったりするけど、その手のものより安いし、通信量での課金とかないし、ロードバランサだCDNだの周辺サービスが必要ないのであればおすすめできるかな。

随分前はさくらのVPSだったけど、移行した。

ナカーマ。

あースペック足りなかったわーとかいう時に、もっと強いのに変えたりできる、というのが分かった上で契約できるのは安心感ありますね。
サービスの質が悪ければすぐ使うのやめられるし。

Snortって、サーバとかで使う侵入検知のソフトウェアのことでしょ？
入ってきた通信パケットのチェックとかできるやつ。

おはようございノス

IPFSは頑張ってると思う。
まあ、仕組み上仕方がないが、データに永続性を持たせるためには暗号通貨でお金払わないといかんけど。

リレーサーバ、ほぼ最初に始めたときのものから増やしてなくて7つぐらいしか接続してないのだけど、フォローしてるユーザの投稿とか、Likeの通知とか、ちゃんと受信できてるのか不安になるな（疑心暗鬼

IPFSもそうだけれど、非中央集権的なアーキテクチャで何等かのアプリケーションを実現しようとした場合、計算資源なり、ストレージ資源なり、ネットワーク資源なり、オペレーションコストなりを提供しないといけない者を必ず要するはずで、その者に対するインセンティブ設計が難しい。
技術的なところでのアーキはそこの設計の後に考えれば良いぐらい。

Bitcoinだのの暗号通貨や、Winnyなんかで知られるファイル共有ソフトなんかはそこらへんがうまくいっているので、システムとして存続している。

ちなみに、Winnyに関しては、Poenyという、実装が公開されているWinnyのプロトコルを実装したポエム共有ソフトがあって、それを用いて少し前にWinnyのネットワークに接続してみたが、今でもネットワークは存続していて、アレげなファイルの情報などが行き交っていたいた。。。

（続
で、Twitterなんかではユーザは広告を見せられることをある意味対価として支払うことで基本的には無料で使うことができている。
Google先生とかもそう。
　
なので、今は一部の有料のものを除いてボランティアで運営されているリレーサーバを利用することで我々は無料でサービスを享受できているが、仮にユーザ数が増えていったとすると、ボランティアの数が今と変わらないとすればいずれ無料提供ができなくなる限界がくる。
ボランティアが増えてリレーサーバが増えることでどうにか、という話もあるかもしれないけれど、今のNostrのアーキではクライアント側の負担が大きくなりすぎるので、やはり限度がある。
（クライアントの問題は特にモバイルデバイスや、モバイル回線でのユーザでまず出始める。というか既に来ている説もある）
リレーサーバに関してはボランティアでなく、ユーザ自身がリレーサーバを立てるといったことをしても同様。

というところで今後のNostrはどうなっていくのか、というところは興味深く思っているところである。
（アクティブユーザ増えてないっぽいから大丈夫では、みたいな突っ込みは悲しいのでやめてください）

（続
要するに非中央集権的なアーキで構成されたアプリケーションで未来永劫何の対価も支払わずに使えるようなものは、本質的には存在しえないという話ですね。
（どこかの金持ちが金払ってるとか、地面から何等かの資源が湧き出ていてそれが利用可能とか、そういう話であれば別）

お外Nostrタイム襲来

（続
【補足】
本質的には何らかの対価の支払い、もしくは何らかのリソースの提供が必要である、という話は、中央集権的なシステムでも同様ですね。
何故か、非中央集権的なシステムだけの話みたいな書きっぷりをしてしまった。

（クライアント側が頑張ることで、）冗長構成になるようには設計されていますし、自身のポストを投げているリレーサーバ（3台程度を想定）が運悪く一気に皆死ぬことは稀でしょうし、それが起きてしまったとしても、秘密鍵さえ手元でちゃんと管理していれば、新たなリレーサーバにPOSTを投げるよう設定することで過去の投稿を行った人物と同一の者として、利用は継続できるはずです。
NIP-05認証をしてあればさらに良し。
（クライアントが、接続していたリレーサーバの情報やプロフィール情報などを保存していなかった場合、そこいらの情報の入力し直しは必要になるはずですが）
　
系全体としてリレーサーバを増やせばスケールするかというと、ある程度はするでしょうが、同時にクライアントの処理負荷や通信量が増えてしまうというのが今の仕様の課題だと認識しています。

とはいえ、グローバルのTLの受信を止めてしまえば、フォローしているユーザのPOSTやLikeの情報ぐらいしか多分流れてこないか、少なくともクライアントがリレーサーバへの最初の受信リクエストを送る際に適切にフィルタ（条件にマッチするデータのみが流れてくる）を設定すれば、通信量の問題はどうにかなるのでは？とも思っています。
（Websocket接続=リレーサーバとの接続、が大量になった場合に、通信量がさほど多くはなかったとしても、クライアントの処理負荷が増大する、といったことがあるのかもしれませんが、そのあたりはまだ私には知見がありません・・・）

仮に有料のリレーサーバを運営しようと考えた場合、どれぐらいのユーザ数までさばけるようにできるのかなー。

AWSで構築するとして、ロードバランサ（ELB）はWebsocketにも対応しているので、EC2のインスタンスで水平方向にスケールアウトするような構成にすることはできる。
データはプロフィールなんかのメタデータはずっと保持して、他のイベント情報は1日か2日分保持するとして、DynamoDBにでも突っ込むとかして。
（EC2インスタンスをスケールアウトさせると単純には個々のインスタンスが持つデータは異なるので受信リクエストに答えられなくて困ってしまうことになるが、DynamoDBのところでインスタンス間のデータは共有される、という構成）
　
まあ、1ユーザあたり平均でどの程度のイベントを送ってくるか、送り出す必要があるか、1イベントのデータの平均サイズがどの程度か、とかちゃんと仮定をおかないと、推定もへったくれもないけど。
（そこまで考える気合はない・・・）
その上、そこらへんを真面目に考えたとしても、ある程度実測（ユーザ数は少数で良い）した場合の諸々の測定データがないと考えられないよなー。
さらに、DynamoDBが、実測したワークロードでどの程度スケールするのかもようわからん。
　
システム設計一般でこんな感じのことを考える必要があることはしばしばあると思うのだけど、大変ですね。

自鯖のVPS鯖を再構築してCLI環境で動くNosttクライアントの nostr_console にリトライしたが、SSLのバージョン回りのバグとかで動かず・・・。

ヤケクソでCLIで動くChromiumなCarbonylをSSH接続で動かして iris を動かしたらなんか表示はされたが途中で操作できなくなった。

で、コンソールだと? マウスで操作できたりするらしいので、あまり意味はないけどローカルのLinux環境（WSL）だとどうなるか試しているなう

WSL環境だとcarbonylに sandboxが使えないから kernel をアップデートしろ！って怒られた。
ふええ。

もういいもん、VirtualBox上で動作するよう構築してあるUbuntu環境があるから、それで試す！

post from snort running on carbonyl (chromium fork which can run on CLI environment)

おー、postできた・・・・。（これは普通のChrome上で動くirisで書いている）
マウスで操作できたし、carbonyl恐るべし・・・

snort on carbonyl はこんな見た目

https://nostr.build/i/nostr.build_f9e5e00d173057a66c2dbaae9501f548e9cad63fc0e5db060afa149a11e6853d.png

むむっ。coracleなるWebクライアントだと泥のTerminusでSSH接続して Carbonyl で開いた状態で、画面タッチでマウス操作できるぞ!

秘密鍵を気合で手入力したが途中から先に進まなくなってしまった・・・

TL眺めてたらYoutube貼ってる書き込みがあったのでクリックしたら再生できたw

どなたか投げ銭して下さった方、あざます！
引き続き役に立つのか経たないのか分からないカキコしていきます！

お仕事でクラウドやら使っている感覚でいうと、Damusがある程度ユーザいるであろうと考えたら、逆にそれぐらいの額で済んでるんだな、と思いました。 >　300$/month

ほほう。これは貴重な情報。

Nostrクライアントの通信量や処理負荷を減らせる、リレーサーバとの通信アグリゲートプロキシ（クライアントからはリレーサーバに見える）、的なものをどうやればスマートに作れるかなーと考えてるのだけど、下のような感じでどうかしら。
なお、スマホなどのモバイル端末を、電源がない、もしくはモバイル回線で通信している環境で利用している場合にのみ利用する運用を想定。

有識者の方のコメント求む。

【仕様・設計】
・クライアントに修正は入れないで済むようにしたい
　（プロキシに繋ぐ時だけリレーサーバを切り替える程度は許容）
　プロキシの通信先は、クライアントがリレーサーバに保存してあるメタデータを取得剃ることで分かる・・・と思う
・クライアントに不要なデータがあれば削って落とし、クライアントが行う処理のうち、下処理としてやっておけることがあればやる
- 削れるかもなものとしては、Likeのイベント情報などがあるはず（落としてもプロキシとの接続を外した後で、後から受信することもできる・・・はず）

【課題】
ポストを投げつける先はリレーサーバから得ておいたメタデータで判別できるのでないかと思うが、一方で...

・クライアントからサブスクライブするためのリクエストが飛んできたときに、それをどのリレーサーバに転送すれば良いか分からないはず？
・他にも同様のリクエストがある気がするが把握できてない
・over SSL/TLSでアクセスできないといけないはずなので、証明書周りのセットアップは面倒なものになりそう（クライアントがオレオレでも気にしなければそうでもないかも）

【余談】
・クライアントに手を入れられる前提なら元々の通信先のリレーサーバの情報をクライアントがよしなに送れば、上に書いた、どのリレーサーバに転送すればよいか分からない、という課題は生じない

おはノスからのお外ノス。

アメジストでグローバル切ってれば、通信量はそんなでもないのかなあ。
まあ、今日の結果を後で確認するかあ。
（泥の"設定"のなかにあるモバイル通信量の推移、的なやつのグラフを見る）

あーなるほど。
ある意味、（プロキシの立ってるマシンのリソース消費の観点で）富豪的に解決してしまうということですね。
確かにそういう手があるかー。

大変参考になるコメントありがとうございます！

Lightning Network、仕方のない妥協だけどオフチェーンで解決するのもなあ、とか曖昧な理解で思っていたが、ググってみたところ、オフチェーンとはいえ、まあ割と筋の悪い方法でもないかな、と認識を改めた。

ちなみに、Lightning Networkのノード立てたら手数料の分け前もらえるんかいな？
（トランザクションが自分のノードを通った場合）

まあ、（ネットワークの構造上で）インターネットで言うところのISPやらIXみたいなのがいて、今更立てても自分が送金したり、送金を受けたりという時にしかトランザクションが通ることはない、みたいな話はありそうだが。
　
あとはWallet of Satoshi なんかの事業者が自身の中で完結させちゃってたりとか。

こまめに終了させてるのもあるかもだけど、今のAmethystはグローバル切ってればそんなに通信量食ってないように見える。

が、回線自体、月の使用量リミットに達しているような気もするので、ただ帯域が細くなって大した通信ができていないだけ、という可能性もあり。

なるほど。
そういうものなんですね。
情報あざます！

確かに。

Let's Encryptは私も自鯖で使っていますが、Unix系の環境についてある程度明るくてもはまったりするので、今考えているものを手軽にセットアップして使えるソフトウェアにしたいと考えた場合、ちょっと気がかりではあるんですよねw
まあ、自鯖持ってるような人はそれぐらい難しくもないかもですが。

無料プランがなくなったことで最近はあまり見かけなくなった気もしますが、herokuにデプロイするボタンみたいなもので、PaaSプラットフォームに簡単にデプロイするルートも用意できたらなおいいかもなーとか、レス書いてて思いつきましたw

情報あざます！

Lightning Network（LN）について、いくらか深堀りしてみたのだけど、結構複雑な仕組みなんだなーということを知った。
あと、即時決済とは言うが、オフチェーンで送金が完了したからといって、その時点でオンチェーン（通常のBitcoinのブロックチェーン）における送金が完了したことは意味しない、ということも知った。

解説しているサイトの中で金本位制ではなくBitcoin本位制という例えがあったが、なるほどその通りで、LN上でやり取りしているBitcoinは、BitcoinではあるがLNを信用する者の中でなら受け取ったBitcoinを他の者に送金、とかいう形で通用するが、LNを信用しない者に対しては、通常通りオンチェーンに反映された後でないとLNで受け取ったBitcoinは使えない（オンチェーンでの送金はできない）と。

LNで受け取ったBitcoinがオンチェーンに反映される前にLN上で別の者に送金するケースとか、すごいややこしい話だなあとか思った。
（こういうことは、多分できるのだろうと理解したが自信はそんなにない）

積極的にデジタルタトゥーを刻んでいくスタイル
（ツイターでもちょくちょく無意味につぶやいているが）

セイウチ演算子ですね!（違
（Pascal系言語では代入がデフォでこの記法だったりしますが）

分からない事があって、とにかくささっと知りたいという時、chatGPTさんに聞くと割とちゃんと教えてくれるので、マジで便利だなって思っている。

そういえば、謎のSlackやらでつるんでいる友人らや、フォローしているツイ垢は自身の職業や関心もあって、ソフトウェアエンジニアが多いのですが、Nostrは驚くほど言及されていませんし、試してみたみたいな話も見ません。
私としては、えっスルー？って思ったりするんですが、残念ながら現場からは以上です。

Clubhouseの時は食いついてたのになー

正直、興味ある。

マスト丼は特定のコミュニティでマイクロブログするには悪いシステムではないとは思うので、あれはあれで良いのだと思う。
とはいえユーザ数が増えたらサーバの運営者が大変であるという問題はあるけれど、まあ、donationとかでなんとかなってるんじゃないかな・・・きっと。
インスタンス間の federation とか、他のインスタンスを follow できたっけか、というあたりは忘れた。
（ちょうど流行った時期、私もマスト丼に貼り付いていたが、その後のActivityPub?やらなんやらは良く知らない。あまり技術的に面白いと思わなかったので）

正直、分散システムにある程度明るいエンジニアが、NIPs眺めて、ちょこっと使ってみれば、（少なくとも現在の仕様では） Twitter alternativeとかムリだし、その数分の1、数十分の1のユーザ規模でもワークしないであろうな、というのは分かる。
　
でもまあ、なんかみんないろいろ作ったりしてるの面白いし、仕様の見直しとかワンチャンあるかもなので自分は残っている。
　
順当に？流行らずに消えていくとしても、その推移を中から眺めるのはそれはそれで趣がある。

失敗は成功の母というし、失敗事例も人類が先に進む糧だと思えばNostrは十分役割を果たした。

後は、自身がどれだけ頑張れるか。

ここでNostrに関するstutsを見てみましょう

https://nostr.band/stats.html

BlueSkyはどんな仕様で出てくるんだろうなー（脅威

な、なにぃ
（情報ありがとうございます）

ざっくりでも仕様が公開されてるなら、BlueSkyeクローンもう作れるやん!（適当）

でも、仕様眺めた感じ、対応した実装を作るのは大変そう・・・

Twitter初期もこんな感じの展開があったりしたんだよ。きっと。
これからキャズムを越えるんだよ。Nostrは。

そういえば、Nostrを使ってみてデータベースシステムに興味を持った人がいたら、当方、下のようなGitHub Pagesの管理人をやっているので、よかったら寄っていってね♪（そんな奴はいない

"自作RDBMSやろうぜ!"
https://ryogrid.github.io/dbms-jisaku/

#自作RDBMS

NostrGramなんてWebクライアントもあったのかー。初めて使った。

危険なのでログアウトした

onload属性・・・・

むっ、利用するにはinvitationなり、waitlistで順番来たで、みたいなのでログイン用コードみたいなんもらわないとダメとかあるが、BlueSkyのアプリ自体はAppStoreに公開された？
リバースエンジニアすれば詳細仕様も分かるやん！

ずっと思っていることではあるのだけど、NostrはSNS的なものを意識して作られているプロトコルではあるものの、TwitterもどきはNostrプロトコルを用いたアプリケーションの一つに過ぎないので、Twitteもどきを指してNostrと言うのは誤ってると思う。
だがしかし、そうだとして、じゃあNostrプロトコルを用いて動いているTwtterもどきのアプリケーションは何と呼ぶのが適当なのだろうか？

そこらへん、みんなで統一しようぜ、みたいな動きも把握している限りでは無くて、個人的には不思議だな、とエンジニアとしては感じる。

掲示板やらWikiやらだってあるわけですしおすし。

ほとんどの用途はTwitterモドキだから別にええやろって？
まあ、そうかもなー。（自己完結）

誤:リバースエンジニア
正:リバースエンジニアリング

inviteでいけるならツイターとFBでinvitationしてくれる人探そ！

アカウントを作るところでinviteコードを入れろと出てくるな

BlueSkyは（invitation受けられたとしても）偵察してくるだけなので...（震え声

なんだかんだ言ってもNostr村にいる村民たち

zap、日テレの朝のニュース番組の名前みたいだな、というぐらいの知識しかない（知識とは言わない

割と同意ですね

関口さんがNostr村を去られてしまったようだが、御仁がいらっしゃらないとなると、グローバルを眺めて分けわからんってなっている難民が村に辿りつけずに息絶えてしまうのでは

WebRTC使って？ブラウザ間で張ったP2Pのコネクションを使った分散ハッシュテーブル（DHT）の実装とかすでにある（2014に開発が止まっているのでそのままで動くかは謎）ので、それをベースに、ブラウザ上で動くSPAをクラサバにしたTwitterもどきのシステムでも作ってみようかなあ。

UDPホールパンチングが通るマシン間（※）でWebRTCでのコネクションを張ろうと思った場合、STUNサーバ（ICEプロトコルを喋る）と、シグナリングサーバという2つのグローバルIPでアクセス可能なサーバが最低限必要で、前者はひとまずGoogleがテスト用ということで提供しているものが使えて、後者は自前で用意する必要がある。
　
※: UDPホールパンチングが通らないネットワークにいる端末や、それを許さないようになっている端末は残念ながら、参加不可・・・。
TURNサーバという2者の通信を丸っと中継してくれるサーバを用意すれば、参加不可な端末も救えるけど、ネットワークリソース使いまくるものになるのでそこまではやれない・・・。
（STUNサーバとTURNサーバを合わせてICEサーバと呼ぶ場合もあったりするが、WebRTCの標準化された仕様、もしくは、それが参照している仕様でどうなっているのかは確認したことはない。ICEプロトコルというものがあってSTUNサーバはそれを喋るはずなので、自分は上に書いたような理解でいる）
　
んで、シグナリングサーバは、WebRTCの仕様だと、雑に言うと、2者がコネクションを張る際に必要な情報交換の仲介ができればよいとだけなっていて、どう実装するかは自由なのだけど、認証だとか特に難しいことしないのであれば、Websocketなサーバとしてサクッと作れる。

というか、シグナリングサーバは下の記事で紹介してるやつで既に作ったことがあるので、それをほぼほぼ流用できるんじゃないか説もなくはない。

"異なるNAT内のPC間でP2P通信をしてファイル転送したり、パイプをつないだりできるツールを作ってみた - Qiita"
https://qiita.com/ryo_grid/items/651486649f116700bdae

みんな大好きWebsocket。

長文失礼。

そんなもん既にあるわ！
と言う感じだったら教えてにゃんまげ。
（車輪の再発名は基本的には好きじゃないので）

件のDHT実装はPeerJSというライブラリを使っていて、それを介して接続を確立する場合はPeerJSサーバというものを立てる必要があるようだが、自鯖に立てることもできるようだし、シグナリングサーバの役割もやってくれるっぽいので、それでいけるか。
（STUNサーバとしての仕事もするのか、TURNサーバとしての仕事もするのかまでは未確認）

ふと思い立ってChromeのデベロッパーツールでirisのリレーサーバとのWebsocket通信を眺めている。
うん。デベロッパーツールだと表示領域が小さすぎて何が何やらだね（白目

メッセージ選ぶと下部にJSONオブジェクトとして表示してくれるのでそうでもなかった。
ついでに投稿した時のメッセージを貼ってみる。

["EVENT",{"kind":1,"content":"ふと思い立ってChromeのデベロッパーツールでirisのリレーサーバとのWebsocket通信を眺めている。\nうん。デベロッパーツールだと表示領域が小さすぎて何が何やらだね（白目","tags":[],"created_at":1676783713,"pubkey":"eb119234c467ac9d2ffea5b7284f3a74bd04287a12cfd58a22d19626434cddf2","id":"8e61292f79bbf83ee7e8ec5c3c1cd3473c30dfb55d4344d2a9af62b6ab3b4f5d","sig":"f6ed2cb1209eb657bed2e54d034b6f9420aa96b9087f279e4f2d25af06d26f57cc99bd585c9eff42cd347b94d9a1b0473a448849469b84ad06c1503b9dae7a5c"}]

リレーサーバから wss://relay.damus.io/ をなんとなく外してみた。
（デベロッパーツール眺めてたら流量すごかったので）
だ、大丈夫かな・・・。
フォローしてるユーザが行方不明になったら分かるような仕組みが欲しいな。
なお iris。

公開鍵と自分がPOST投げてるリレーサーバのアドレスを1つ入力すると、フォローしているユーザの情報を解析して、それらのユーザのPOSTを受信するために最小限必要な台数かつ、サービスの質の高いリレーサーバを選択してそのリストを教えてくれるサービスが欲しい。
（リレーサーバの質はそのサーバがレスポンスタイムやらなんやらを定期的にチェックしている）

なるほどー。
それなら安心。

情報あざます！

リレーサーバをjp系の3つのみにしてみた。

ふと気になってChromeのデベロッパーツールで iris がブラウザにどんなデータ持っているか見てみたのだけど、

・irisのapiサーバがあってその特定の呼び出しのキャッシュ？をIndexedDBに入れてる
・自分の鍵か何かだろうけど極めて少量のデータをlocal storageに入れている

他には特にローカルストア的なものは使っていないみたい。

これってNostrクライアントだと一般的な作りなのかしら？
容量に制限は持たせるにしても、IndexedDBとか使ってローカルに一度取得したデータは持っておけば良いと思うのだけど、そうしない（できない）理由がプロトコル的にあるのだろうか？
（IndexedDBが使えないブラウザとかがまだたくさんあるとかかしら）

ページをリロードしたら毎回、TLを構築するためのイベントデータとか、通知ページ見た時に表示する内容をリレーサーバから取得しなおすの？？？
手元のデータと重複を確認した上でレンダリングするのが面倒とか効率が悪いから？？？

irisのAPI呼び出しの結果は普通のWebキャッシュとして残っているようなので、そこで何かうまくいくようになってる？？？

んー。
（認識違いだったらすみません）

30人はすごいなあ

https://iris.to/post/note14u7hgvhdzc3ggwculnzs5p6mfc9vd6vjnwq2t7rpjk7l58yx7e7swuu3sl

ツイターでは引用RT魔な私なのですが、irisで引用RT的なことするのどうすればいいのん？

私がこういう運用を知らないだけだったら申し訳ないのですが、5分刻みで、間も空けずにtalkしてもらうというスケジュールはライトニングトーク的なものでもかなりしんどい（結局スケジュールがどんどん押す）ことになる可能性高かなーとか思いました。
（なんだかんだ質疑応答とかも発生しそうだし）

あくまで1つのコメントとして〇刀乙

Service Workerとかうまく使ってるのか気になってました！

自分はアカデミックにいる人間ではないので書かないけれど、Nostrの各種統計データを整理して、時系列でどんな推移をしたか、課題は何であったか（すでに過去形w）、参加していたユーザの特徴、ムーブメントとしての特徴はどうであったかなどなど、まとめたら、レベル低めの海外ワークショップくらいだったら査読通る程度の論文になったりするかもなー。

類似のシステムとの比較なんかも入れてもろて。

かかってこいやぁ！

Nostrの新しいCLIなクライアントが来たか!

algia、jsonが吐けるようなので、ちょっとしたラッパーなサーバ書いて、ちょっとしたフロント書いて、受け取ったJSON使って小奇麗にレンダリングしたりすれば、手元の端末のリソース消費を抑えてNostrできるのでは？
と思ったりした。

誰かそういうの作ってくれないかなー（他力本願時

あー、バックエンドサーバ化するのはすぐできそうだけど、フロント書くのが面倒くさいな・・・。
サーバサイドレンダリング（ただのCGI）でひとまず作ってみるか。
ハッカソンやー。
明日は普通に仕事だけど今から始めて明日までにできるかな。

GitHubリポジトリを作って気分の高める
https://github.com/ryogrid/algia-web

日本語がおかしくなってしまった

よし。JSON出力、からだとユーザ名直接分からないようなので、stdoutをそのまま読もう!

Golangで行こうかと思ったけれど、（開発の）スピード重視でPythonに方針転換。

$ algia tl
を実行した結果をちょいと整形して表示するだけのものはできた・・・

【デモ（？）】
http://ryogrid.net:8080/
(ryo_gridこと私のTLの最新のところが表示されるだけ）

コードはこちら。出力のサニタイズは行われている認識。
https://github.com/ryogrid/algia-web

現時点だと、SSHでサーバに接続してコマンド実行した場合と変わらないというか、postとかできないので、post、like、repost はできるようにしたい・・・。
あとリンクがあればaタグで囲んで飛べるようにする（ヘタにやると危険そう）

構成としてはただのCGIという今の構成はUX的にも通信量的にもアレなので、やはりバックエンドとフロントという形にしたい。
SQLiteなんかの組み込みDB使って取得したポストの情報突っ込んで、フロントで更新された分だけ取得して表示的な。
　
プルリク歓迎!
特にスタイルシートとか苦手なのでそのあたりフォローしてもらえたらありがたし。

ちなみに、https化はされていません。

今の algia-web と名付けた何かの見た目。

https://nostr.build/i/nostr.build_9bbdd2ce143572d2ca21d4d83680bcdac552ffc8cb1bb69f17e140a58c5b1f2e.png

algia の tl コマンドって当然サブスクライブのリクエストを行うはずなので、相当数の取得を行うよう指定しないと直近のPOSTまでたどり着かないのではないかという気がしてきた。
（表示されている内容が大分前のもののような気がする）
　
あと、時系列的に新しいものが上に表示されるようにしたいが、今のalgia-webの実装だと、逆順に表示されているはず・・・。

おはようございノス

algia-web の説明 at リポトップをそれっぽくまとめてみた

https://github.com/ryogrid/algia-web/

ずっと、やるやる詐欺だったリレーサーバアグリゲーションプロキシと同じ目的を達成し得るであろう algia-web をただのビューアとしてだけなら一応使えなくはない・・・、というところまで作った（※）ので、satoshiください（古事記

※:まだプロトタイプですし、さらなる作り込みはするつもりですが

GitHubリポ
https://github.com/ryogrid/algia-web

【デモ】
http://ryogrid.net:8080/

#[0]
しょうもないもので勝手にalgiaの名前を使ってすみません・・・ ○刀乙
これから、もっとまともにしていく所存ですので、なにとぞご容赦いただきたく ○刀乙

謎の送金DOSアタック笑う（別にサービス？に影響はない

な、なんですとー
WoSのアドレスを設定してあるんですが、なんでじゃろ。

ああ、WoSだと駄目とかって話ですかね・・・・

メールアドレスみたいなやつの方を設定してみました！

1000sats投げてもらってありがたやなのだけど、fundが足りねえぞこらぁ、とWoSに怒られて泣く泣くcanselした。

情報あざます！

もし1000sats送ろうとしてくれたのがロクヨウさんだとしたら、私のウォレットに十分な額がなくてfund足りねえぞ、と怒られてキャンセルしたためかもしれません。
小さな数字ならいけるのかも。

おとといLNの仕組みを調べたのでfundが足りないと言われて、まあ、なんとなく意味はわかったが、いきなりそんなこと言われてもパンピー（失礼）だったら、わけわからんで終了するのでは...

wss://nostr.walletofsatoshi.com
もリレーサーバに追加してみた

10sats送ってみましたー

ハーベスト（スタンド）で作ったが使い捨てられたウォレットに残っているsatsを集めたら小金持ちになれるのでは！（そもそも他人のウォレットに触れない
しげちぃぃぃ！

WoSの画面。
なんやなんや。

https://i.imgur.com/CKfvDVR.png

普通の？Bitcoinのウォレットも持っているが、少額でもいいから残ってたかな。。。
残額があって、手数料やらこみで送金できるならWoSにfundできるがー

ちなみに、私はBitcoinのFXで割と笑えない額を溶かしたことがありましてね。
LNはまだ当時、出てきたばかりぐらいで運用に載ってなかったと思うのでようしらんのですが、Bitcoin自体についてはまあまあ知ってたりするんですよ。
怖さも含めて。。。

ボラが高すぎるんだよなー。

The DAO の一件やら、BitcoinがSegwitだったか、高額を盗まれたトランザクションを無効にする修正を適用するか否かだかで暗号通貨自体がforkしてしまった件とか、も追ってたりしました。
The DAOは戦犯。

EthereumがThe DAOの一件のせいでフォークしたんだっけか。

WoSが軽率にリレーサーバ立てたら負荷が、想定以上にかかって、本業用のシステムをダウンさせてたりしたら笑うな（笑えない

あらやだ、しったかしてしまいましたw

自身が趣味で作ってたソフトウェアの関連で、2001年ぐらいにはBitcoinなるものは見かけたのですが、意味が分からなかったので、スルーしたんですよねー。
その時にいくらかでもマイニングしていれば。。。

お仕事したくないでござるうううう
からのお仕事開始。

algiaのtlコマンドであまり最新のnoteが取得できていないようなので、使い方を間違っているのか、そういうものなのか、実装を読んでみる。

followしているユーザのリストを定期的に更新しているが、設定ファイルに書いておいたリレーサーバのうちおそらく最初に接続できたものから取得するものの、古いものしか持っていなかった時に、何度更新してもfollowしているユーザが最新のものにならない、というようなことが起きていたぽい。
安定したリレーサーバを書いておきましょう、ということですね。

はろーわーるど5

algia-webでページ遷移しちゃってるけど、投稿もできるようになった・・・

もうこれでいいや・・・

あと、通信量を減らすために何気に文字数食っている公開鍵の表示を無くした。

https://i.imgur.com/X4dLoxi.jpg

あとはアイコン表示displayネームがあったら表示

あとはアイコン表示、displayネームがあったら表示、replyぐらいできればいいかな・・・。

XMLHttpRequest を自前で書くとという、フロントのフレームワークが整備された今ではもうあまり書くこともなかろう、うんコードを書いた。

あー、投稿時刻の表示は欲しいな。

そういえば、手動更新チェック（実際はただのリロード）ボタンも置かないとだった。
（クライアントが自動でというか、ユーザから見えないところでやたらと通信やら受信データの処理やらするから、通信量だバッテリ消費だとかが想像つかないことになるわけで）

ワイもいつのまにかsatz投げbot?からsatzを受け取っていた！
ちょっと嬉しい。

そこ気になりますよね。

algia-web，内部でalgiaをexec、的なことしてるのだけど、投稿するときの文字列をコマンドライン引数として渡すときにサニタイズ的なことしてあげないと、デモとか公開しようとすると、テクいことされて任意のコマンドを実行されちゃう可能性あるのでどうにかしたい。
（自分用に立てて、他人が知り得ないパス（FQDNなんか以降のパス）を設定できて、そのアドレスでアクセスするようなものにすることを考えているので、デモする時以外はあまり重要なことでもないのどけど）

こういう時のベストプラクティスってなんなんじゃろ。
そもそもコマンドライン引数で渡すのが筋悪という気もするが、algia側の都合もあるしなあ。
んー。

sats投げbotとかから投げ銭もらっても、微々たる額なので正直普通には使い道がない（※）のだけど、チリツモという話もあるので、もらったら、Nostr界隈の開発者やリレー運営者に投げてあげるのが唯一有用な使い道な気がする。

※:私の知る範囲では。もしかしたら、Ethereumのgusの支払い的なものに使えるとか、何らかの用途がある人にはあるのかもしれない

ガチE2EEチャットアプリのSignalとか同名のSignalプロトコルではそんな雰囲気（少し似ているだけ）のことしてますねー。
ただ、そのまま適用はできないはずですし、どうにか拡張して頑張ったら頑張ったで、各クライアントの計算コストとか大きくなりそう。

Double Ratchetアルゴリズムというのが肝なんですけど、高コスト。

まあ、Signalはさておき、大本の秘密鍵を晒さずに、そこから派生したものでどうにかする、というアルゴリズムは、探せばありそうだし、そういう技術を普通に使っている界隈とかもありそう。
使い捨てる前提がとゃんと成り立ってないと、盗まれたら結局、なりすましされちゃいますけど。

https://signal.org/docs/

Sats配りボット、Nostr村民をシャブ漬けにするのが目的では？（表現

まあ、真面目な話、LNが普及すれば得をするプレイヤーはいるはずで、そこいらが動いているという可能性はまあ考えられるわな。
投げてるsatsはそのための広告費みたいなもん的な。

ググってた時に見かけたニュースだと、国内の大手取引所がLNに対応するとかなんとかってのも見かけたし。

広告と見なしたときのターゲティングとしては、まあ間違ってない気はするし。
数がそんなに多くないのは難点だけれど、まあ、ネットワーク効果みたいなのを期待してまずはこのあたりから、と考えたのだとしたら、理解できないことはない。

ネットワーク効果というより、ただのバズか。

難しいところですよねー。
取得できたものはさっさと見せろ、という人も多そうですし。

ツイターもバズったツイのスレッドに広告出すようになってて、その広告収入は元のツイをした人に入るようにする？（なった？）とかって話があったような。
マイクロブログでも秀逸な内容を生み出したものは利益が得られるようにしよう、というのはNostrなんかに限らず、ある模様？

lain氏、どこかのクラスタでお見かけしたような。

Amethystの開発者さんのポスト見かけないなーと思ったが、リレーサーバをJP系に絞ったからやんけ！（自爆
sats送ろうと思ったのにな・・・

damusのリレーサーバを戻したら、フォローリスト少なくともで、Amethystだとロボ表示になっちゃってた多数のユーザのアイコンとID?が表示されるようになって、無事に、Amethystさんに、投げsatsできた。

余談だけれど、共通のリレーサーバがない場合、followerの数も半分くらいに減っていた模様。
そころへんの情報ってどうやって管理されてるんだっけか。
　
まあしかし、それらのfollowerの人たちはワイのポストが突然見えなくなったのであろうと思われるので、リレーサーバの切り替えも慎重にやらんといかんのかもな、などと思ったりした。

ただ、平文でデータをリレーするサーバでも、その上で通信している者同士が申し合わせてE2EEのプロトコルなんかで暗号化したら、リレーしてるサーバからは見えないんだよなー。
というところで、E2EE通信の存在はクライアントに責任のある話では、という気がする。

インターネットでの通信も通信事業者のコンピュータの上を少なくとも通っていくけど、over SSL なプロトコルとかで通信されてたら中身見えないのと同じですね。

いや、そういう通信があった時（※）の通信しあっているホストのIPアドレスを提出できる、とかいうのが大事なのか。

※NIPsで決められている仕様で行われていない場合も判別するのは困難だろうけど・・・

誤:場合も
正:場合は

ちょっとNostr的に面白いことを思いついてしまった。
それをやるためには algia-web の作りこみをもう少し進める必要がある。

どういう理屈か分からないのだけど、iris（on 固定回線に接続しているPCのChrome）でデベロッパーツール開いて、disable cache を有効にした状態でリロードしたら、ページの表示がいつもよりずっと速かった・・・。
キャッシュとは・・・。

私もその手のやつ経験しましたw

'ほげほげほげほげ'

'げほげほげほげ'

'マスクメロン'

'ボヘミアンラプソディー'

ああああ　いいい

'ああああ　いいい'

aaa; echo hoge > hoge.txt

リロードされるかな

algia-webのデモページを更新しました。
投稿も可能です。

投稿したポストは "algia-webちゃん♪" のポストになります。
彼女はalgia-webの宣伝担当ということになっています。

公開鍵
#[0]
irisの垢サイト
https://iris.to/npub1tm05psxvxc6serfqh82hu90et37djsa3v3t5wcpd3ev0cvpxaqlqr6awnq

入力フォームは改行がそのままだとできないですが、\nとか入れたらできるかも？

【デモサイト】
http://ryogrid.net:8080/

【GitHubリポ】
https://github.com/ryogrid/algia-web

ご愛顧のほどお願いいたします。

https://nostr.build/i/nostr.build_8eeb0afef5b31d085038affd2bd5a397086fbb85a1e3cbd3e9b839a79fc025f6.png

なお、アイコンは自身のPCで動かした画像生成AIなプログラムで作ったやつなおで、著作権的な問題は侵していません。

みんなで適当にしゃべらせたら面白いかな、と思うので法的に問題があったり、人に迷惑かけない範囲でいろいろ喋らせてあげてくださいー。

もう、皆さんお外Nostrはバッテリつらーとか、ギガ使いまくり―とか、そういう問題は乗り越えた感じなのかな？
（algia-webとかニーズが無いのでは・・・という雰囲気を感じており、開発にコミットするか悩み中）

むっ、Nostr勉強会、今日か！

cimpassの勉強会のページ、いきなりイベント名と併せて、

Nostr勉強会 #0
そして伝説(Bluesky)へ

とか書いてあってワロタ。

さておき、開催場所ってどちらになったのでしたっけ。

はっ！私もそれ持ってます！
一番安かった爵位。
私も男爵だったかなw

それなりに立派に見える表彰状みたいなのが届きますよw

いやー、貴族同士の会話は洗練されているなー（白目

シーランド公国というイギリスの領海にある石油採掘拠点か何かだったところを占拠して、国家であると宣言している人たちがいて、まあ、当然のように国家として承認している国は無いのだけど、よくよく考えてみると、台湾なんかも、どこか国際政治に影響を与える力は無い程度の国が1つ2つ承認していたかもしれないけれど、ほとんどの国は国家として正式に承認はしていないんだよなー。

そこの点だけ見たら、2つの存在は残念ながら同じようなものだと言える。

Amethystをgithubに置いてある最新pkgにアップデートした。

引用ポストのテスト

#[0]

準備運動 #nostrstudy

サーバのセットアップ方法を書いた

https://github.com/ryogrid/algia-web

カップラーメンとノンアルビールとチーズを用意した。

分散システムガチ勢のとある友人も勉強会の配信を見るために帰宅中だとか言っているので、鎌投げてもらおう

ノスターだろ（怒

git とか英語圏でも確か読み方の見解が分かれて、公式が "ギット" だ、ってアナウンスしたんじゃなかったっけ

ツイターでNostrがトレンドキーワードに入っちゃうのでは!（さすがに無い

おっ、もうそろそろ闘いの幕が開く時間か
#nostrstudy

Youtubeでも配信されるんだよね？
#nostrstudy

安牌なのはdiscordのイベント配信チャンネルで観る方法なのだと思って居座っているけど、正しいムーブなのか自信が無い
#nostrstudy

heguroさんのトークのノート

https://github.com/heguro/nostr-meeting-20230222/blob/main/start-nostr-protocol-with-devtools.md

#nostrstudy

A100って、VRAMサイズにもよるっぽいけど、100万Yenとか200万Yenとかする製品の模様。
超ハイエンド帯か。

#nostrstudy

Nostrプロトコル内で、よしなに広告を挿し込む方法を開発して一稼ぎしたい（妄想

クライアント側で弾くとかムリなやつ

おはようございノスター（宗教戦争

確かにリレーサーバで使うDBには時系列DBが相性良さそう。
基本的更新はappendとdelete（時系列で一番古いものから消せればいいだけ）のはずだし？
フォロワーのリストとかプロフ情報なんかをユーザが更新するときは、レコードのupdateが必要？appendだけだといけない？

まあ、時系列DBまでいかんでもOLTP系DBより、OLAP系DBの方が相性は良さそう・・・かな？
ちなみに、組み込みDBでOLAP系だとDuckDBとかいうやつが今、熱いらしいです。

algia-webちゃん♪にダイバーシティを持たせてあげてもらえるとありがたく。

http://ryogrid.net:8080/

で、投稿するだけでやんすのでー

#[0]

時系列DBというと、Prometheus、InfluxDB、Timescaleとかなのか。
最後のは、今ググって初めて知ったけど、昨日の勉強会の前あたりにNostrでキーワードとしては見かけた気がする。

さておき、DBはワークロードに合ったものを選ぶことで小さく見ても数倍程度は性能変わったりするようなので、そこらへんがボトルネックになるレベルなら、使うものを変えることを考えたほうが良いのかも。

まあ、リレーサーバの開発者レベルの話だとは思うけど。
（SQL互換だったりして、RDRの中での選択として、時系列DBなんかを使うこともできるのかもだけれど、それだと性能引き出せないとかいう話はありそう）

ナイス多様性

#[0]

そういえば、Amethystを最新版に入れ替えたら5つしか設定してなかったリレーサーバが15まで増えているのだけど、これいかに。
フォローしてる人のうち、行方不明の人がいたらよしなにリレーサーバを追加してくれたとか？

いや、自分が設定してたリレーサーバは飛んでるな。。。

送受信するデータを設定できるAmethystはまあ、大丈夫だろうけど、PCで使ってるirisちゃんは膨大なメッセージ受信してるんじゃないかな。。。
リレーサーバ数20とかだし、今。

snortは送受信するデータのリレーサーバごとの設定を考慮するようなので、PCで使うクライアントはそれができないirisから乗り換えるか。

私のポスト見えてますか？

今更だけど、自分もNIP-07認証の拡張機能とか導入するかー。
個人的には（現時点での）Nostrの秘密鍵の機密性とかそんなに気にするほどのものでもないかと思っているのだけど、長いものには巻かれておく。

NIP-05認証はしてあるから、なりすまされても一応対応手段はあるはずだし。

ただ、唯一の懸念は、こちらが手を打つ前に犯罪予告とかを投稿されてしまった時に面倒なことになりそうだなー、ぐらい。

リポスト？ができないっぽかったので、Snortを使って見たがirisに出戻りした。

価格は固定なんでしょうかね？（米ドルで）
固定なのだとすると、当然、価格変動は米ドルで見れば起きないので、Bitcoinなどの暗号通貨で、という形だと話が変わってきてしまうのかなーとか思ったりします。

algia-webを作っていて思いつつあることは、皆が求めているのはクライアントとしてまともで、かつ、ネットワーク消費やバッテリ消費の少ない、モバイルデバイスで動作するクライアントなのではないかということ。

つまり、algia-webのアプローチは、作ってみました、で終わってしまって使われないのではないかと。
　
そして、使われるとしたら、当初から考えていた賢いリレーサーバアグレ―ションプロキシ（クライアントからはリレーサーバに見える）、みたいなものなのではないかと。。。

HTMLとかスタイルシート書くのだるいし、やるとしたら、まだプロキシサーバの方が自分には合ってる気がするというのはある。
　
面倒なのは、NIPsのおおまかな理解が必要なのは当たり前としても、標準仕様？として固まっていない個々のクライアント固有の仕様とかを考慮しないといけない可能性があることかな。

よし決めた。algia-webのエンハンスはストップしよ。
デモサイトも止める！
　
今リポジトリにあるものでも、見た目も機能もへちょいけど使えないことは無いので、使いたい人がもしいたら使ってもらえばいいし、同じコンセプトのものが必要だ、と思う人がいたら、forkでもして開発を継続してもらおう。
　
うん。
　
で、ひとまず自作RDBMSの作業に戻る！

っぽいですねー

algia-web、せっかく作ったので awsome-nostr に載せてもらえるようプルリク投げた
https://github.com/aljazceru/awesome-nostr/pull/191

複数のリレーサーバとのWebsocketコネクションを1つに束ねるプロキシの実装は既にあるようだ。

https://nproxy.cc/

outoubdもinboundも全て素通しするだけみたいだけど。。。

https://twitter.com/ryo_grid/status/1628885987144396800

一応ツイターオルタナティブを目指してるっぽいNostrで、ツイターの自分の投稿リンクだけ貼るのギルティ感あるなw
こんなことしてたら村八分にされちゃうw

ツイターの投稿をNostrに流すbotやらなんやらあったはずだからセットアップするか。

まあ、それこそalgiaとか使えば一瞬でできそうな気もするけど、ツイターはAPUの制限きつくなったんだっけ？

SegmentさんのATプロトコルのアーキの図、わかりやすくてためになったし、大変ありがたい仕事だと思っているが、海外の有識者の人（Segmentさんも十分有識者と言えるだろうけど）というか、分散SNSガチ勢みたいな人らで図とかまとめてる人おらんのかな？

ギルティなbotセットアップするか

ググってたら、おもしろそうなQiita記事見つけた

https://qiita.com/ZOI_dayo/items/693e289bf5edd6628353

IFTTT連携テスト2 (via Twitter https://twitter.com/ryo_grid/status/1628900701656199168)

Twitter -> IFTTT -> Google Spreadsheet -> GAS -> 自作デーモン -> Nostr (via Twitter https://twitter.com/ryo_grid/status/1628909626917019649)

上の構成でTwitter to Nostrできた。
algia-webのサーバがpostできる口を持っていたので、少し手を入れるだけで流用できたw

これでTwitterが死んでもNostrで生き延びられる! （本当か

前からNostrにかきこしてる内容をツイターでも発信しておきたい。
が、めんどいという話があったのが、これでようやく解決。
ただし、150文字制限（）

日本人は大体集まっているのではないかという限界集落で関口現象という謎のミームが生まれているの興味深い。
関口さんは別に悪いことしたわけじゃないので、そういう含みがないように使われるといいけれど。

仮にBlueskyが twitter alternativeとして覇権を握ったとしても、Nostr と Blueskyを繋ぐゲートウェイ（技術的に可能かは謎）とかを誰かが設置してくれて、Nostr村民も生き延びられるという展開があったらいいですね。
そもそも仮定の話であるというのを再度枕詞として置いた上で、Nostr側はNostr側でやる、というのでもいいかもしれないけれど、そのままだと絶滅しないか心配。
なんとなくNostrは、マスト丼が一部では使われ続けている、とかっていうのと同じような展開は歩まなそうな気がするのよな・・・。

ふば (via Twitter https://twitter.com/ryo_grid/status/1628917945224290305)

投げてたプルリクがアクセプトされて、algia-webが awsome-nostr のリストに追加されました。
めでたい。
（それなりに使っている人がいる、閲覧している人がいるというGitHubリポにプルリクして、それがアクセプトされたのって何気に初めての経験かもしれない）

https://github.com/aljazceru/awesome-nostr

algia-web、ちんけなソフトウェアではあるけれど、PoC的なものとして見れば一応作れはしたし、awesome-nostrとかで、モバイルデバイスはつらいだコラ、だから、その解決策の一案としてこんなの作ってみたぞ、というコンセプトが伝われば、それはそれで作った甲斐はあったといえると個人的には思っている。

既存のWebクライアントに少し手を加えて手元では省リソースで使えるようにする、と考えた場合、今どきのSPAがやってるDOMの書き換えの時の差分だけ、サーバに置いてある本体が送ってくれて、手元のガワだけのクライアントは自分の持ってるDOMにそれを反映する、みたいにできたらいいんだけどなー。
あとは、クリックイベントとかをサーバに置いてある本体に送れるようにしないとダメか。
お遊びレベルかもしれないけど、Nostrとか関係なくそういうことを試したとか、そういうことができるライブラリ、とか探せばありそうな気もする。

あー。
確かにSSRを使うという手はありますね。
情報あざます！
（差分だけくれや、ってこともできたらいいなー）

これからお外Nostrやー。
自鯖に一応立っている、algia-webを使う時が来たか！
ドッグフーディング大事！

algiaを知った時、嬉々とSSH経由で使ってみたのだけど、watchコマンドに単純に algia tl とか指定するとまっさらになる時間が発生して微妙だな、と思ったのが実はalgia-webを作ってみた動機の一つであったりした。

が、ちょっとしたシェルスクリプト書いて、それをバックグラウンド実行することで重複排除済みのポストだけ書き込まれるテキストファルというのができるようにして、それを tail -f とかで見れば別にいけるのでは、とか思いついた。

これなら、algia-webのように重複したポストを再度受けとってレンダリングすることもないし、HTMLの文字数もかからんから、通信量はさらに減る・・・はず。
（SSHがKeepAliveのためにデータ送ってたりしたらあれだけど）

over SSL/TLSで膨らむデータサイズというのもたかが知れてるだろうし、サーバから受信するテキストの量が少なければ復号処理によるバッテリ消費も大したことなかろう。

いや、私もそれほど詳しいわけでは無いので適当言ってます...
サーバサイドレンダリングと言っても、JSまったく使わんケース（SEOのため）と、使うケースとか、あるんじゃないかな、とか漠と考えています。

ただ、SEO対策を目的とするものは静的ファイルをあらかじめサーバでダーっと生成しておくJamstack?とかの話で、私の勘違いかもです。

Webフロントエンドの話とか基本そんなに興味がないのだけど、サーバサイドレンダリングについてちと知っておきたいと思ったので、Next.js について軽くお勉強してみる。 (via Twitter https://twitter.com/ryo_grid/status/1629067209652998144)

ふばば？ (via Twitter https://twitter.com/ryo_grid/status/1629069462866628610)

NostrendsのJP/Dailyのタブ、日にちも遡れるようになるといいなあ。
https://twitter.com/ryo_grid/status/1629105574913925122)

どうもツイターでの投稿をNostrに投げる時に併せてツイター投稿へのリンクを貼ると、ヘイトを集める（ている）気がするので含めないようにしょ

はろーわーるど

おはようございノスター

IFTTTの方もいじったけど、修正完了! https://t.co/taqYZC0VvU

WebhookでNostにポストできるサーバとかって案外無かったりする？
ざっとググっても見つからなかったので、結局似たようなものを自分で作ったのだけど。

正確にはサーバのソフトウェア。

IFTTT経由でツイターのツイをNostrにもポストするようにすると、引用RTのRTしてるツイートはツイターの短縮URLで流れるのだけど、クライアントで展開されて表示されないんやな。
まあ、 t.co ドメインの短縮URLと言っても、指してる先がツイのリンクとは限らないし、いちいち短縮を解いて展開、なんてしてられないわな。

時代に乗り遅れてる感じはありますが、Angular派です。

いや、多数派はReactなんじゃないですかねー。
Reactベースの Next.js も流行ってるみたいですしー。

Reactなら React Native で似たようなお作法で（主にモバイルデバイス向けの）ネイティブアプリ作れるぜーみたいなのもありそうですし。
（他のフレームワークでも同じようなことはやろうと思えばできるようですが、まあ、単体でフレームワークとしてある感じではない）

フロントもSPAとかにして、差分データだけ受け取るというように全体的に作り込めば、リレーサーバのアグリゲーションプロキシとかのアプローチよりも良いものになるはずで（※）、そういう意味ではコンセプトとして間違っていないけど、クライアントを作り込むのが面倒くさすぎる。

というところで、既存の各クライアントがそのまま動くプロキシサーバを作る方が最強のクライアントを作ってやるぜ、とかいうつもりでもない限り、筋は良いと思う。

※:本来手元のブラウザでやるはずだった署名の検証やらに割く処理リソースも無くせるせし、手元のSPAは必要なデータだけ受け取ってレンダリングするだけにできるので、通信リソースも自分が考え得る範囲では一番減らせる構成のはず

Svelte、最近耳にするけど全然把握できてない。。。
フロントエンド界隈は本当にきのこたけのこの勢いで新しいフレームワークとか出て、世代交代みたいなことが起きるのでついていけない。。。

あるマルチコアCPU（近年市場に出ているもの）を搭載したデバイスがあり、あるアプリケーションがあって、あるやらないといけない処理があった時に、当該処理が自身の処理を完了させるまでに消費する電力って、マルチスレッドなりマルチプロセスで処理可能ならやはりそちらの方が下がるのだろうか？

なお、このアプリケーションはネットワークI/Oの量も多いが、マルチコネクションで個別のマシンと通信しており、I/O待ちと、それ以外の処理は時系列上で並行して行えるものとする。 https://t.co/ZvxHgpR6iM

まあ、スマホブラウザで動くSPAを想定した時の話なんですが。

また、処理の完了までに要する時間は特に評価せず、消費電力の最適化のみを考えるものとする。

いや、スマホアプリ一般でも構いません。

バージョン1系（AngularJS）を使い続けている（2系つまりAngularにリプレースしないで）人たちはさすがにやばいと思っている派

私もマスト丼が流行った時に、まあまあ規模の大きいインスタンスで謎に内輪ノリが発生して、楽しくやっていたりしたことがあるのだけど、その時を思い出しつつ、今のNostr村（JP）を見ていて興味深く思っていることがある。

それは、以下を踏まえると、
　
・マスト丼みたいな連合型のアーキで各インスタンスごとにいる人が違う（リモートフォローは割と初期からできたかもだけど）というわけではないので、リレーサーバのアドレスを秘匿して意図的に特定のコミュニティの者しか参加できないような運用をしている人たちがいない限り、日本人ないし日本語話者の中でコミュニティの分断は起こらないはず
（マスト丼が流行っていた時はjp鯖？とか、その他大きなインスタンスとでコミュニティの分断が起きていたりした記憶がある）
・私はいくらかエンジニアの人に偏っているものの、JPな人であれば見かければ大体はフォローしている

　
私が見ているTLにはJPなアクティブユーザ（※）の大半のポストが流れているはずであるにもかかわらず、さしたる流量が無いということだ！
　
※: ここでのアクティブユーザにはROM専の人は含まないものとする
　
いや、だから何だってことではないんですけど。。。
ちょっと言ってみたくて。。。
割と驚きじゃないかなって。。。

Nostrendsとか眺めてても、あ、村民の方だ、みたいなことが大半というのも、私のTLのカバレッジがそれなりにあると考える根拠である

需要があるか不明（他にもっと良い手段があるのかも）ですが、NostrにポストするためのWebhookのエンドポイントを自鯖に立てる方法を、NostrのScrapboxに書いておきました。

~~TwitterとNostrにマルチポストする場合~~様々な情報ソースからNostrに投稿したいという場合にご活用いただければ幸甚です。

https://scrapbox.io/nostr/Nostr%E3%81%AB%E6%8A%95%E7%A8%BF%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E8%87%AA%E5%88%86%E7%94%A8%E3%81%AEWebhook%E3%82%A8%E3%83%B3%E3%83%89%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88%E3%82%92%E7%94%A8%E6%84%8F%E3%81%99%E3%82%8B

テスト2

https://t.co/7WgDhZyyge

Webhookエンドポイントを自鯖に立てる話のScrapbox記事ですが、IFTTTでの指定のところに誤りがあったので修正しました。
送信するメッセージはエスケープしておかないとですね・・・。

"Nostrに投稿するための自分用のWebhookエンドポイントを用意する - scrapbox.io"
https://scrapbox.io/nostr/Nostr%E3%81%AB%E6%8A%95%E7%A8%BF%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E8%87%AA%E5%88%86%E7%94%A8%E3%81%AEWebhook%E3%82%A8%E3%83%B3%E3%83%89%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88%E3%82%92%E7%94%A8%E6%84%8F%E3%81%99%E3%82%8B

自作RDBMSとは別の作業をまたしてもやっていたというのはあるけど、それにしても、まだこの作業やってる。
（テストケースが書きあがってすらいない）
作りが悪い気もしなくもないが、テストケースのコードにあまりこだわっても仕方ないので、このまま突っ走る
#自作RDBMS https://t.co/vHSSLHXBTh

わたくし、ツイターにて引用RTを結構するのだけど、IFTTTのツイターのトリガーは引用しているツイートのアドレスを短縮URLにしてしまうので、Nostrクライアントでは展開されず、かなり微妙な感じになるなあ。

単なるRTはトリガーにしないという設定はしているが、引用RTは自身の投稿として扱われるようだ。

んー。自分で動かすものは、ツイターの短縮URLを含むメッセージが飛んで来たら無視するようカスタマイズするか。
OSSだー

コードを2行追加して、所望の挙動をさせることに成功した。

Next.js、ある程度透過的にサーバサイドとクライアントサイドで行う処理が書けるのは、面白いし頑張るなあと思ったのだけど、使いこなすのは結構難しそう。
ちな良く分からんのは、SPA的な？インタラクティブなWebアプリを作るのには向かない？
公式のShowcaseを見るとその手のものは見当たらないが。

サーバサイドレンダリングなんかを目的に使う場合は、そういう感じの話になるっぽいな。
まあ、おそらく肝要なのは、アプリケーションとしての内部状態をサーバとクライアントでどう扱うかという話で、インタラクティブなWebアプリだとクライアント側は状態を持っていないとダメだろうが、それをサーバサイドと同期するとかいうのは、一般的な通信環境の技術水準では難しいわな。
必要な時に必要な情報だけ渡してAPIを呼び出すということはできるだろうけど、明示的に書かないといけないなら、ただのSPAと大して変わらんので、透過的にやってくれたらうれしいだろうけど多分そこまでは無理だろうな。

学生時代と新卒で勤めた会社での専門はハイパフォーマンスコンピューティング（HPC）というもので、そういう界隈では分散メモリという考え方や、分散共有メモリなるものを分散したマシンから見えるようにするミドルウェア？とかあったが、そこらへんの話を思い出す。

分散共有メモリ
https://ja.wikipedia.org/wiki/%E5%88%86%E6%95%A3%E5%85%B1%E6%9C%89%E3%83%A1%E3%83%A2%E3%83%AA

いくらか似たものとして、Lindaというものがあるのだけど、大変面白いモデルだし、様々な言語やプラットフォーム向けに実装があるので、知っておくとどこかで役に立つかも。

Linda
https://ja.wikipedia.org/wiki/Linda

歳を重ねても、"ちんこ" とか "うんこ" とか楽しげに発話する無邪気さを忘れないでいたい（あまり必要ない

自分を follow ってどうやったらできるんだ・・・

お酒を飲んだ（でいる）時にマイクロブログをやるのは危ないと、祖父が飼っていたイッヌが言ってました！

ツイターのサイトはぬるぬるスクロールするなぁ・・・

おはようございまスカイ（未来志向

少し前にSegmentさんがNostrはサーバを信頼してないという点でP2Pと同じとか、ただのハブだ、とかおっしゃっていて、ハッ！って思ったのだけど、Nostrって本質的にはクライアントがオーバレイネットワークにいるP2Pネットワークに近いものなのかな、と思ったりした。

P2Pのレイヤでのアドレスは公開鍵。
公開鍵を指定することでP2Pでの通信が可能。
一度送信したメッセージは送信時に相手がオフラインでも受信ができる。
また、他のノード群（クライアントが動いているコンピュータ達）に、ゴシップブロトコルみたいなものを使わずとも、比較的高速にブロードキャストが可能。この通信においても、送信先のノードは、後からメッセージを受信できる。

で、上のような通信特性を実現しているのが下のレイヤにいるリレーサーバ。クライアントから受けた通信は他のクライアントにブロードキャストできるし、メッセージキューのミドルウェア（うんたらMQとか名前つくようなやつ）のように、あるクライアントから受け取ったメッセージは、他のクライアントが後からでも受信できるようにしてくれる。メッセージキューのミドルウェアのように保証はしてくれないけど。

オーバレイネットワークとしてだけ見ると当てはまらないのは各ノードのメタデータ情報を自身や他のノードがネットワークから取り出せるところ。これはあくまで近いものであって、違う、というところかな、と。

こう整理すると、クライアントの仕事がやたらと多いのも自然だし、メタデータが飛ぶことがあるのも、まあ、ネットワークの謎機能使ってるので、しゃあなくて、クライアントたちでのフォローが必要なのでは、みたいな考え方になる（で、手動だけど復元のためのクライアント機能を内在したサービスが存在する）。

あとは、普通の見方に戻って、リレーサーバに着目すると、ブロードキャストしてくれるとか、メタデータを持ってくれるとかいうことはしてくれないけど、NAT内にいるコンピュータ間の通信を中継してくれるという点で、WebRTCでも用いられるTURNサーバと同じようなもんだよなーというのも思うところではある。
まあ、本来、アプリケーション次第であるものの、Twittetrモドキを実現するために使われるのが現状、主な用途であって、メデイアデータみたいなでかいデータをやり取りしないからリレーサーバ提供者が死なないレベルのトラフィックで済んでいる（？）、というところは、WebRTCなんかでのTURNサーバとは違うところだけれど。

と、こんなところでどうでしょう？

まあ、こういうこと言うと、e-メールの仕組みも同じだよね、とかいう話になったりするんだけど。。。

とはいえ、ｅ−メールサーバ使ってオーバレイネットワークを構築して、割と高頻度で通信するアプリケーションを動かす馬鹿とかはお遊びレベルではいたのだろうと思うけど、まあ、まともに運用に載ったということはなかろう。

サービス作ってみた人は、積極的にawesome-nostrに載せろリクエストするといいと思います！
他の人がやってあげても親切かも！（他力本願寺

#[0]

NostrでポストををPinするって、どうやればいいんや！

あー、そうなんですね。
なるほどう。
情報あざます！！！

NostrでポストをPinする方法教えてくれーと、世界の中心で叫んだところ教えていただいた。
シェアしておきます。

#[1]

ポート番号みたいですねw

> AndroidバージョンではDamus ではなくAmethystという名称になります

かなり誤解を与える書き方のような。。。
Amethystの開発者さんが可愛そうだよぅ

#[1]

Amethystでの投稿の調子がおかしい？？？

件のAll Aboutの記事について。

> ※AndroidバージョンではDamus ではなくAmethystという名称になります。

この書き方は誤解を与えるような。。。
Amethystの開発者さんが可哀想だよぅ

どこかの勢力が主要リレーサーバにDDOS攻撃とかかかえて、Nostrネットワークを壊滅させようとしているのでは!（妄想

nostr.wine ってリレーサーバ、何か特別な機能とか持ってるの？

PCでは iris を使っていたが、Snortに乗り換えるかなー

Amethystの開発者さん = Vitorさん
ですね。

な、なんだってええええええ
（素晴らしい）

あー、しかし有料リレーサーバなんですね。
まあ、やっていることの性質上しょうがない感はありますがー。

filter.nostr.wine が提供している機能性は私が以前から、こういうのがあったらいいな、と言っていた、リレーサーバアグリゲーションプロキシ（リレーサーバ）と大体同じだな。
（私が考えていたものは、特定のメッセージのレスポンスを返さないように設定できる、とかいうのもあったけど。likeの通知だなんだとか）
　
実装がOSSで、自鯖でホストできたらいいんだけどなあ。
今のところ、アグリゲート対象にJP系サーバは入っていないようだし。

https://nostr-wine.github.io/filter-relay/

なるほどう。
ややこしいですねw

情報あざます!!!

nostr-ircええやん!

https://github.com/tubomius/nostr-irc

これを自鯖で動かして、スマホにIRCクライアント入れて接続すれば、出先Nostrリソース消費やばすぎ問題は割と解決では？

接続するのにいくら必要なのかまでは見なかったですが、結構高いんですね・・・。
うーむ。

filter.nostr.wine を利用するための料金はLNでsatoshiを送ることで支払えるようなので、satoshiを投げ銭してもらうことに対しての意味が（個人的には）1つ増えたな。
約1万satoshiとか集まらん気はするけどw

https://scrapbox.io/nostr/nostr.wine

おかしなメッセージを送信する・返すようになったノード（Nostrではサーバおよびクライアント）が現れたり、そもそもメッセージ返さなくなったりするノードが現れて、系全体で混乱が起きるとかって、分散システムあるあるなんだよなー。

そういうノードが現れた時に系全体がいかに健全でいられるようにするか、というのも、システム設計・実装の重要なところである。

まあしかし、Nostrの場合、リレーサーバにもクライアントにも、良くも悪くも多様性があるので、なかなか大変だよなーとか。
所感。

これはこれで熱い。

#[0]

filter.nostr.wine の話であれば、アグリゲートしているリレーサーバは外した方が良いのでしょうね。
せっかく、filter.nostr.wineが束ねてくれた意味が無くなるという話もありますし。

ただ、利用している端末の性能やネットワークの帯域・遅延にもよりそうですが、（私の認識では）そもそも重複して受け取ることが起こる想定でクライアントは作られているはずなので、変な話だな、という気もします。

nostr.wineの話だとしたらなおさらですが、irisが、有料サーバに接続している場合の処理に何か課題を抱えているのかも？

はてなブログに投稿しました #はてなブログ

考察: Nostrプロトコルはオーバレイネットワークを構成するためのプロトコルなのではないか？ - Ryoの開発日記 Neo! https://ryogrid.hatenablog.com/entry/2023/02/26/141302

socket.IOは一言で言うと、強い。
（Websocket通信がプロキシやらファイヤウォールの都合上通らなかったりした場合に、Cometやらポーリングやらの"いにしえ"の通信方法に切り替えてくれたりして便利なんですが、Nostrの場合はクライアントがWebsocketしか想定していないので、そのあたりは注意が必要かも。ダウングレードを認めないようにオプションを指定してlistenするとか）

まあ、インターネッツに情報は多いはずですし、ダウングレードを試みないようオプション設定しておけばよいだけかと思いますし、オプション設定してなくとも、クライアント側もWebsocketでの接続しか想定していないはずなので、単純に失敗して終わりになる気はします。
　
まあ、一応、そういうこともやれるものである、という程度の話でした。
混乱させてしまったかもしれませんね。

リレーサーバ側の話はひとまず置いておきますが、Websocket接続での受信データ量はクライアント側である程度コントロールできるので、おっしゃるようにクライアントが"低回線モード" とか "低負荷モード" とかを用意して、ONにするとサブスクライブするイベントを絞るとか、イベントの受信実績から、接続しておかなくてもことが足りるリレーサーバとの接続は切る、といったことをしてくれれば、クライアントがもろもろのリソース消費し過ぎ問題は許容可能なレベルまで抑えられるはずなんですよねー。

まあ、開発者の人たちはそんなところまで手が回る状況ではないのかもしれませんが^^;

続くは複数のリレーから受信したイベントデータから重複排除を行うなどの、通信量的なところの最適化ですね！（期待）

ちなみに、コードはオープンにしていたりしますか？

strfyというリレーサーバ実装は単体でリレーサーバとして機能できると同時に、別のリレーサーバと接続してデータを受信して重複排除した上で自分のDBに突っ込むということができるようだ。

自身に接続してるクライアントからのリクエストをフォワードするのか、他のリレーサーバからデータを引っ張ってくる時に何でもかんでもではなく、条件を指定できるのか、まではリポジトリトップの説明からはうまく読み取れなかった。
コード読め、って感じかな・・・。
　
しかし、いじってみたいと思ったりしたが、C++なんだなこれ・・・。
うーん・・・。
C++は得意ではないですな・・・。

https://github.com/hoytech/strfry

勝手ながらIDでググってたどり着いて、fork元の説明読んだりしてましたw

strfyではなく、strfry。

わたくし、RDBを自作したりしているが、C++得意ではない（のと、パッケージングシステムが無いなど、他人にいじってもらう時に敷居が高い）ので、とある教育用実装をGolangにポーティングするところから始めたからな私・・・。
（最低限のコアの部分は他の方によって既におおむねポーティングが済んでいたが）

まあ、パフォーマンス重要だろうし、残党な選択ではある。
（一応扱えないことはないが、Rust実装であるよりは良かった・・・かもしれない。微妙なライン）
Golangぐらいで妥協してもいいのよ？

Nostr関連で調べものしてて Markle tree なるものをちょこちょこ見かけていたのだが、何か良く知らんかったので重い腰を上げてググっているが、ハッシュ木のことのようだ。
（ハッシュ木もようしらんけど）

Markle tree って他の文脈でも耳にしたことがあったような記憶があったが、blockchainでした。 https://t.co/9Hx7bXQSSs

Strflyなるリレーサーバ実装（説明を読むとプロキシ的な役割を担わせることに最適化されているっぽいような）の説明を読んでいたら、Testingというセクションに "real-world nostr events" とかいうリンクがあって、飛んでみたら、リレーサーバが扱うことになるのだろう、eventデータのデータセットのページがあったw
（結構知られてるものなのだろうか？）

https://wiki.wellorder.net/wiki/nostr-datasets/

例えば、1m(v1)というものだと、展開すると1.4GB程度のサイズがあって、100万イベントのデータが含まれているそうな。

metadataに関するものだけを集めたものもあるみたい。
こちらは、7万イベントぐらいしかないようだけど。

なかなか熱いなこれは。

Strflyなるリレーサーバ実装は、Strflyに設定してあるリレーサーバから全てのイベントデータを受信し続けて、自分のDBに格納して、俺がそいつらの代わりにデータを返すぞ！という設計のようだ。

うーむ・・・。
全ては男前すぎるような・・・。
まあ、きっとどれぐらいの期間分保持しておくのか設定できるのだろうから、プロキシとして使うなら、それを例えば1日とかにしておけば、外出時だけ、自前で立てたStrflyに接続する、とかいう運用は可能かなあ。
　
クライアントから飛んできた投稿のイベントやら、メタデータ設定のイベントは自身のDBに格納しつつ、設定されているリレーサーバ全部に投げるのだろう。多分。
それ以外にワークする設計思いつかんし。

クライアントに返す時の重複排除はしてくれるみたいだし。

ウィペディってたら、Gnutellaとか懐かしいキーワードが現れた。

https://t.co/aR4iPybiuE https://t.co/VI6fBv1Dvi

まあ、すごく雑な表現だけど、READMEを読むだけで、「コイツ、ガチだ・・・（ビビり」、というのが伝わってくる一品であるな。

諸般の事情でChromium（C++で実装されている。クソデカコードベースで死ぬ）のコードを追ったりしていた時に培った経験をここで生かす！

サザエさんシンドロームの時間帯はとっくに超えてますね。
自分も、えっ、もうそんな時間？って思いましたｗ

strflyなるリレーサーバについてコードやらドキュメント？を読んで分かったことは以下。

■リレーサーバのデーモンとしては単体で完結するような作りになっている模様
　=> 自身に接続してきたクライアントの相手を普通に行うのが基本で、その中で受け取ったイベントデータは自身のDBに格納する

■他のリレーサーバとのやりとりはCLIなコマンドが用意されていて、それを用いて行う
　=> 主には、イベントデータの受信およびイベントデータの送信
　$ ./strfry stream wss://relay.example.com --dir both
　とかすれば1つのWebsocketコネクションで双方向にデータを送受信しあうらしい。
　少なくとも受信はイベントの生成日時関係なく受信可能なものは全て受信すると思われる（ちょっと自信がない）

　 https://github.com/hoytech/strfry#stream

　そもそも、strflyは自身のDB内において、他のリレーサーバのデータが同期されていればいいじゃん、と考えているようで、それを効率的に行う仕組みを作りこんでいるようで、
$ ./strfry sync wss://relay.example.com
　とかいうのが受信方向に対応するコマンド

$ ./strfry sync wss://relay.example.com --dir both
これが、双方向で行うコマンドだが coming soon であるとのこと

　https://github.com/hoytech/strfry#sync

　データの同期に関しては元々リレーサーバ間の連携のために設計されたyesstrプロトコルとやらがあって、それを拡張したものの実装である Quadrable というのを（自分たちで作っていて、）それを用いて行うのだとか。
　しかし、Quadrableのリポジトリの説明を読むと、nostrというキーワードは出てこなくて、マルチバージョンなデータベースで、効率的に他のデータベースインスタンスと同期できるところが特徴である、みたいなことが書いてある。
（データベースならまかせろ!!!）

https://github.com/hoytech/quadrable

ご参考まで！以上！

ようやるわ・・・

ポスト消えちゃったら悲しいのでブログに書いておくか・・・

記事を投稿しました！（Nostrプロトコルの）リレーサーバ実装 strfly について調べた [Twitter] on #Qiita https://t.co/AZ5PNse4nN

Nostrのポストには永続性がないので記事化しておきました・・・

matrix、Nostr村でちょこちょこキーワードとして見かけたのと、今ATプロトコルに関する記事を読んでいて、その中でも出てきたのでググった。

なんか、マスト丼よりはイケてそうな雰囲気醸し出してるけど、アーキとしては同じようなものっぽいな。

https://matrix.org/

Nostr関連であれこれやっていたために、今日も自作RDBMS全然進まなかったな・・・

#自作RDBMS

おはようございノス

（必要性があるかは怪しくなってきたけど、）Nostrなアプリケーション（ここではマイクロブログ型SNSとする）がスケール可能（全体のユーザ数が増加しても使えるものであり続ける）にするためにはどうすればいいかと、初心に戻って思考実験レベルで考えてみている。
答えは出ていないけどアイデアとか、糸口になるかなーみたいなところは思いついた。

で、まず、Nostrの特徴として維持されないといけないことを決めておかないとで、以下かと考える。

・リレーサーバは気軽に建てられて運営をやめてもユーザに迷惑がかからない
（ボランティアベースになるというところはひとまず仕方がない、ということにしておく）
・リレーサーバに要求されるマシンスペックや通信リソースはべらぼうな量にならない
・クライアントはそれなりに遅延なくデータを取得できる（ピュアP2Pなアーキを意識）

その上で、
・最低限、リレーサーバの連携は必要で、リレーサーバのソフトウェアはもっとインテリジェントになる必要がある
・可能であれば、スケールさせるための仕組みにクライアントを協力させる仕様にしてもいいかもしれない
・クライアント間の連携も通信コスト的に見合うならやってもよさそうだが、P2Pでの直接通信は行わない

というのが、まあ大枠。

これを、ブレークダウンしていく。

クライアント側の要件を整理すると、
・クライアントはどんなに絞ってもフォローしているユーザの投稿に関するデータは受信できる必要がある
（どれだけの期間分受信できればワークするかは想定するユーザの使い方によって変わるので明確化は難しい）
・リレーサーバに持たせている各種メタデータも（自前で持っておくこともしたほうがいいし、仕様として整理が必要そうな気はするものの）、受信できる必要ある（だろう）
（複数の端末やクライアントで同時にアプリケーションを利用可能であるという利便性は捨てられない、と思う）
・一番目のポチと重なるが、現時点での仕様および各種実装だと起きてしまうフォローしてるユーザを見失う、フォロワーを、置き去りにしてしまうことが起きないようにする（今はユーザ数がさして多くなく、定着したユーザの同質性からコンセンサスを成立させられているので、例えばJPなユーザは特定のいくつかのリレーサーバに接続していればOKってなユーザの運用でどうにかっているが、ユーザ数が増加して、各々のペルソナも多様になった場合、同様のことは難しくなるはず）

技術的な側面での要件・制約を整理すると、
・スマホ程度のスペックでも動作し、通信量に制約のあるモバイルネットワークでも無理なく使える
（パケ死やバッテリ消費やばい問題が起きない）
・なお、スマホ等のモバイルデバイスでの通信に着目すると、恒常的に大量の通信を要することはクリティカルだが、（私が調べた範囲では、）Websocketのコネクション数が多い事自体は、数十程度に収まっていれば、問題とならないはず（要検証）

これらを踏まえて、以下、スケールさせるために具体的に必要なこと。

■確実なもの
・クライアントが、利用するデバイスや環境、ユーザの求める機能性に合わせて必要なデータ量を絞れるようにする
（Amethystなんかが持っているリレーサーバことの通信内容の設定ができればおおむね良いが、Likeなどの通知の類もTPOに応じて切ることができるのが望ましく思う）

■アイデアレベル（妄想レベル）のもの
・現状、フォローされているユーザAとフォローしているユーザBは同じリレーサーバへの接続を1つは持つ必要がある
=> リレーサーバが連携する前提で、分散ハッシュテーブル（DHT）の仕組みを使って、公開鍵の値からあるユーザを担当するリレーサーバを決めるようにする
　=> ユーザAのデータがあるサーバ（あるべきサーバ）はリレーサーバであれば分かるようになるので、ユーザBの初回のサブスクライブ要求では要求を受け付けたリレーサーバが、担当リレーサーバのアドレスを返し、そこにHTTPでのリダイレクトのような形でアクセスさせ、以後そのリレーサーバにリクエストしてもらう（クライアントも連携が必要）。ユーザAがイベントデータを投げる場合も基本的には同様。
　冗長性の確保のために、担当リレーサーバのマスターは1つだが、他に2つ（ここではひとまず）のスレーブリレーサーバがDHTの仕組みの中で定められ、それらもAとBに返却される。Aはスレーブにもイベントを投げ、Bはマスターと、スレーブのうちの1つに接続する。どちらかかが死んだら、残りのスレーブに接続する。マスターを主体として、常にスレーブは規定台数維持され。足りなくなれば新たに追加され、クライアントに通知される。

【DHTで担当サーバを決めるアーキの良いところと課題】
・Good 中央集権的なサーバが不要
・Good 元々、リレーサーバが突然いなくなることが考慮されている
・Bad この手のものはうまく実装しないと期待通りに動かない場合が往々にしてある（爆）
・Bad フォローしているユーザに比例して接続すべきリレーサーバが増える

■なんとなく思っていること
・Twittetrでも"クラスタ"などという言葉があるように、完全に、もしくはある程度、ソーシャルネットワークの中には分断が起きていて、ユーザ数の増加に真正面から対応するのではなく、分断されているコミュニティ内でのやりとりであれば大きな遅延なく行えることをターゲットに、リレーサーバ・クライアントが連携して上に書いた担当サーバなどが決まるようにすればフォローしてるユーザ数に比例して接続リレー数が増えるようなことは避けられるのではないか、とか
・"クラスタ"うんぬんの話と同様に、フォロワーがめちゃくちゃ多いユーザは同じリレーサーバにまとめる、とかすれば良いのかも？

以上、長文失礼。

下を書くのを忘れていた。

・サブスクライブした場合の、受信するイベント情報はバラバラに送ると各々に重複する情報があって無駄が多いケースがあるようなので、リアルタイムのイベントでない限り、一つのメッセージにいくらかまとめられるように仕様拡張する
（少なくともサーバ側の処理負荷は増えると思うけど・・・）

以下も追加。

マスターが死んだ場合はスレーブの1番古株が新たなマスターになる。
（マスターとスレーブの間では定期的に生存確認を行う）

下もDHTの説明のところに追加。

・Good 大概、いい加減なアプリケーションなので、メタデータを除いて、他のデータが多少消えたりしても大きな支障はない
・Bad 新たにリレーサーバが参加した場合や、リレーサーバが死んで新たにスレーブを増やす場合に、リレーサーバ間で持っているデータの一部を渡す必要があり、そのデータ量が巨大になる場合がある

このポストも永続性は無いのでチラ裏（Myブログ）にでも書いておこう・・・

DHTを使う話って見方を変えると、連携させたリレーサーバ群を公開鍵をキーとして指定できる Key-Valueストアにしてしまおう、って話であるとも言える。
永続性は当然保証されないが。

書き忘れたが、リレーサーバをインテリジェントにする、というところは『なんとなく思っていること』のセクションに関連するようなところで、ただ、クライアントにリクエストされた通りデータを格納して返すだけじゃなく、データの中の閲覧可能な内容を分析して、ネットワーク構造（リレーサーバ間の接続およびクライアントとリレーサーバの接続）をリレーサーバが連携して最適化する、みたいなことができたらかっこいいなーという話であったりする。

というか、そういうことをリレーサーバ群がしないと『なんとなく思っていること』に書いてあるようなことは不可能なはずですしおすし。

趣味プロが気になって仕事に身が入らないのわかる。

知人でまあなんかすごい物知りで賢い人がいて、いつも興味深く話を聞いているのだけど、その人の分析としては、Web3はアナーキズムを根底に持っていると。なので、自然とガチ勢はそこらへんの人らになっていて、金儲けの話をしてる連中は大体ニワカ、ということだった。
はあ、なるほど、と思った。

ああ。ユーザ？という意味でもそういうことになると思います。
　
なお、私の投稿での "ガチ勢はそこらへんの人ら" というのは仕組みを考えたり、開発をしている人たちのことを意図した記述でした。

つまり、Web3なるものを構築しようとしている人たちの中で、ガチの人らは、アナーキーな思想を持っている人か、そのような傾向がある人たちである、という趣旨でした。

なるほど。
確かにそうかもしれないw

ふーむ。言われてみれば。 > 技術拡大してきた

無法の方面はあまり詳しくないですね^^;
例えば、ダークウェブとかいう言葉がありますが、あまり詳しく知らない^^;

ウィペディってみましたが、ダークウェブってFreenetやTorなんかも含むんですね。
ふーむ・・・。

https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%BC%E3%82%AF%E3%82%A6%E3%82%A7%E3%83%96

確かにリバタリアンという表現の方が適切な感じはしますね。

みんなからの匿名質問を募集中！

こんな質問に答えてるよ
● 質問箱の質問は大半は機械によっ…
#質問箱 #匿名質問募集中

https://t.co/OYZntOJgfw

ATプロトコルでは、パーソナルデータサーバ（PDS）というのが、マスト丼で言うところのインスタンス的な雰囲気で存在して、どうも他のPDSとデータを同期したりするっぽいが、どのPDSと同期をとるかとか、まあ同期をとらないにしても federated な関係になるか、ってどうやって決めるんだろう。
サーバを運用してる人のノリかな。

Nostrだとクライアントが複数のリレーサーバにデータを投げることで、データの冗長性が確保されるので、リレーサーバ側はデータの冗長性だとか考える必要がない（そこがNostrアーキの面白いところでもある）が、サーバ側でやろうと思うと、どう接続関係を持つかを決めないといけないわけだけど、やたらめったら接続しても保持するデータが増えてしまうし、どうやって決めるねん？って気はするのよね。

俺の考えた最強のNostr拡張アーキの話、ブログエントリにしておくかー。
放置しておいても消えちゃうしー。

はてなブログに投稿しました #はてなブログ
私の考える最強のNostrプロトコル拡張（考え中） - Ryoの開発日記 Neo! https://t.co/PD0Xe2lB7e

Nostr村でポストした時はかなりいい加減に書いていたので、いくらか整理してブログエントリにしておいた。

ちゃんと動きました！
すごい！
（あとDamusのリレーサーバが私がNostr始めたころまでデータ持ってて驚いた）

https://nostr.build/i/nostr.build_3d0dd0b914155a92ebd8aa98ac9c4ee1dc320b298b4666cdde2e0f314c5f64d3.png

ちょっと気になったんですが、リレーサーバ一般において、タイムスタンプがやたらと昔なイベントデータも受け付けて保持するんでしょうかね？

昨日、strflyなるリレーサーバの実装を斜め読みしていたのですが、下のようなコードがありまして、おそらく、不自然に古いイベントがクライアントから送られてきた場合に reject する処理だと思うんですよね。

https://github.com/hoytech/strfry/blob/master/src/events.cpp#L124

で、そのような処理は他のリレーサーバ実装にも入ってておかしくないのではないかなーとか思いまして。

タコウィンナーのキャラ、出自はさておき、なんでタコウィンナーなんですか？

反応がなくて寂しいので再度ペタリ

私の考える最強のNostrプロトコル拡張（考え中） - Ryoの開発日記 Neo! https://t.co/PD0Xe2l3hG

なるほどう。
まあ、3年分受け付けるなら当面は心配なさそうですねw
（設定で変えられそうですが、まあリソースカツカツな環境で運用してなければ、デフォルトで使う人は多そう。他のリレーサーバ実装でも。）

なるほど！

#[0]

確かに、足がありますね！
悪路にも強そうだ！

Amethystのアップデートだーん

自分は、偉くなりたい、金持ちになりたい、権力を持ちたい、といった欲求はあまりないけど、承認欲求高め＆自己肯定感高めたいマンなので、それにドライブされてツイターやら、ブログ・Qiitaなんかのメディアで情報発信したり、趣味でOSSなSW書いたりしてるというというのはあると思っている。

自鯖にstrfly（プロキシ的な役割をこなせるリレーサーバ実装）をホストして、自ら人柱になってみるかなー。
ただ、他のリレーサーバからデータぶっこ抜く時に since とかが設定できないと、まずストレージ容量的に無理そうな感じはするんだよなー。
まあ、そもそも、他のfilter条件も設定できて欲しい感じはあるのだけど・・・。
リポトップの説明には書いてないけど指定できたりするのかなー。

https://qiita.com/ryo_grid/items/f2bfae818c6a89bf328b

Thank me later って、thankしねえよクソが！

おめでとうございます！ https://t.co/MiAkVCP7WA

Qiitaにはいろいろ記事、書いてきていて、ここ1-2年のものだと以下あたりなのだけど、strflyの記事のview数、まあまあいってて、関心のある人がいはするんだな、と思った。

3942 views
"（Nostrプロトコルの）リレーサーバ実装 strfly について調べた"
https://gyazo.com/8bbb413437408858bc57a6e2ccf379cc

渾身の力作
6071 views ・・・
"自作RDBのためにオンディスク並行Skip Listを作ってみた"
https://gyazo.com/64e9d4777378d1c0f5cdf22c1e3fd118

11383 views
"自作RDBMSやろうぜ！（出張版）"
https://qiita.com/ryo_grid/items/f23bb5846558698ec4cc
　
34122 views
"他言語ユーザがRust言語をガチめに使っての雑感 - 分散KVSを書いてみて -"
https://gyazo.com/056628f4e07e645a4c165d0ce438b49b
　
他でview数が多いのは、2017に書いたでぃーぽよらーにんぐ関連の記事とか。
みんなお金に絡む話は大好き、ということが分かる。
36213 views
ディープラーニングでFXシステムトレード
https://gyazo.com/ae4c8e7f2cf8effcbb2598a3b1f840bb

しかし、Qiitaのview数ってユニークでなかったとしても、仕込んであるGoogle Analyticsの数字と大きく乖離していて、なんでこんな差が出るんだろう、という謎があるんだよなー。

1つだけ間違えて、普通に記事へのリンクを貼ってしまった・・・

はっ！（ハズカシー

ご指摘ありがとうございました。
Qiita記事のタイトルと中身のところは直しておきました！
（Nostr内での投稿でも間違っていたと思いますが、もうそれはデジタルタトゥーとして刻まれてしまった・・・）

@Nostrちゃん Twitterとは何ですか？

GPT-2ならモデルが公開されているので、自前で動かすこともできるはず。
どれぐらい強いマシンが必要なのかは知らないけど。

Google Colabの有料プランとかなら 1000円程度/monthぐらいで動かせたりしないかな。
あれ、スペックの割には安いんだよな。

わざとtypoさせようとしているのではないか、ぐらいのネーミングですよねw

正確には GPT-2 の日本語モデル

なんか iris がいきなり闇落ちしたのだが・・・
（勝手にダークモードみたいなんになったし、リレーサーバおかしいし、POST流れてこないし）
というわけで、Snortに退避。

秘密鍵入力しなおして再度ログイン？したら直った。
良い機会なのでフォロー情報とプロフィールのバックアップデータとっておいた。

@Nostrちゃん Twitterとは何ですか？

@Nostrchan Twitterとは何ですか？

@Nostrchan Twitterというサービスがありますが、それについてあなたがどう考えているか教えてください。

@Nostrchan あなたは小説家です。Nostr太郎君とNostr子さんを登場人物とした小説を500文字以内で書いてください。

くっ、Nostrちゃんガチャにはずれたか！

なんかNostrくんとかいうのが増えてる・・・

#[0]
よかったら教えて頂きたいのですが、strfryをプロキシ的に使う時って、他のリレーと双方向にイベントデータを送信するCLIなコマンドと、リレーサーバのデーモンを同時に動かしておけばよしなにやってくれるってな感じでしたか？
あと、CLIなコマンドでfilterって設定できたりするのかなーとか。〇刀乙

自鯖で動かしてみよっかなーとか考えておりまして。

最近のクローラは驚くべきことにJSも動かしてクローリングしてくれるらしいですが、レスポンスタイムが遅いと判断されて、評価が低くなってしまう、とかSSR関連の情報を調べてた時に見ましたね。

Mostor面白い。
こういうことが可能なら、Blueskyともブリッジできるようになりそうね。

https://gitlab.com/soapbox-pub/mostr

strfry、Ubutu/Debian系ディストリでのセットアップ手順しかなくて、Redhat系の自鯖ではつらいのでDockerで入れることを試みることにした。
Dockerfileはリポジトリにあるし。