すべてのプログラミング言語ﾁｮｯﾄﾃﾞｷﾙマンになりてぇ
Jetpack Conpose完全に理解した！って浮かれてたらドキュメントにあるはずのNavDestination.hierarchyがunresolved referenceと言われて何もわからんつってる
AndroidのAPIのランタイムがJVMなはずなのでRustをJVM Byte codeにコンパイルできれば動きそうだけどJVMにコンパイル出来るtargetがあるか分からぬ
Using Rust to Build a JVM
https://googleben.com/2022/05/02/java_rs-memory-management.html
rust: 堅牢でクロスコンパイル出来る
go: お手軽にクロスコンパイル出来る
だからといってロジックのミスによるバグは防げないのであれですが
rustのコンパイラはとても賢いのでこのまま通したらメモリ管理のバグになるケースみたいなものは全て潰してくれます。賢いので
配慮がありすぎるので自分で考えるより雑に書いてコンパイラの指示通りに書き換えていったら形になる
SHOULDで相手のwrite relayのどれかから読み取るべきみたいなことが書かれてるけど普通はkind10002が読めるならreadで繋いでるに決まってるので……みたいなあれがある。クライアントがスパムになりづらいeventをみんなbroadcastしてかないとあんまり嬉しくない
NIP-65、kind3のcontentにrelay情報のjson突っ込んでたのを_規範的にしただけ_なので対応そのものは単純。それをどう使うかがgossip modelなるものの仕組みというだけなので
your readじゃなくてothers writeから流れてる図、そんなにいい感じがしない
gossip modelなんかどうでも良くて素直にrelayのread writeを規範的に持てるkind10002を使っていこうね、適度にeventを見つけたり投げたりしたリレーをランダムにtagのrecommend relayとして書こうねぐらいしか思ってない
ATPは個人にリポジトリがあって、そのリポのMSTはだいたいGitみたいなものなのでcommitsとかrebase/deleteみたいなのをGitをイメージして解釈したらなんとなく言ってることがわかるかも
これは流石にNIP-28がちゃんと考えてない形っぽさがある
> Clients and relays SHOULD handle kind 41 events similar to kind 0 metadata events.
🤔
kind41、複数のチャンネルのmetadataを持つのかぁとなってる
> Update a channel's public metadata.