うん、Nostr上でざわざわしてる。

This account is not set to public on notestock.

すみません

This account is not set to public on notestock.

とりあえず、自分の能力だとこの辺が限界。分かる範囲でレポートまとめてissueで投げよう…

もしかして、この「このようにしないでください」を踏んでるか？ https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onMessage

chrome.runtime.sendMessage()しちゃいるけど、その飛び先がonMessage.addListener()じゃなくwindow.addEventListener()側になってる。で、message.data.paramsが無いのでそこでreturnして抜けるから無限ループにならずに済んでると。

そうだとしてもpass on to backgroundしてるはずだが…？

ん？getRelaysがwindow.addEventListener側から来てる？

nos2xだとhandleContentScriptMessageで全部一緒くたにやっていたけど、horseの場合シリアル越しのとそうでないのとで分けたつもりになっていた…が、分け方を間違えたか何かした、とかいうことだろうかね？

もしかして：getRelaysをhandleContentScriptMessageで処理しないといけないのにhandleMessage側で処理させようとしている

なるほど、iris.to, nostterはgetPublickeyを最初に持ってくるけど、Snort, NostrFluはgetRelaysから始めてる。

シリアルポートへのアクセス許可、これと公開鍵の参照許可が同時に求められた場合はシリアルポートのアクセス許可で代えている…？

permissionの許可と、その有効時間の設定がおかしいとかその辺を疑えばいい？

chrome/nos2xだと、irisでもちゃんとpermissionを聞いてくるな。

snortも、event (nullうんぬん）…irisは黙って公開鍵情報持ってくんだけどこれどうなってるんだ。

nostrfluでnos2x-fox使った場合、event (not recognized: kind: null) is requesting...ってなるな。

common.js、permission周りとか大体一緒なんだよなあ…

getPublicKey, signEvent, nip04.encrypt, nip04.decrypt…実際になんかするときに、ということは分かったが。

serial.js、initDeviceを呼ぶのはcallMethodOnDeviceでwriter=falseの時限定か。

あと、アレだ。webserialをopenするタイミングの「クセ」が問題な気がする。これ直すのはちょい面倒そうだけど。

あー、addListened()からhandlePromptMessage()呼ぶ際の引数がreqだけになってる。こいつだ。

senderがundefinedになってる。

ボタン押すとイベントは来る。仕込んだconsole.logは動いてる。ってことはその先。

true undefined undefined {prompt: true, id: '24964911165907', host: 'nostter.vercel.app', level: 5, condition: 'expirable'} {id: 'mhdenjcigpjpimdoakfmnchpcocglfgl', url: 'chrome-extension://mhdenjcigpjpimdoakfmnchpcocglfg…ercel.app&level=5&id=24964911165907&params=%7B%7D', origin: 'chrome-extension://mhdenjcigpjpimdoakfmnchpcocglfgl', frameId: 0, documentId: '174B9766D00744EAD749AB07DDCEFB64', …}

chrome.runtime.onMessage.addListenerに何が届いているか、まずはここか。コンソールにどうログを表示させたものか…

cancelだのauthorizeだのつついてもpromptのウィンドウが消えない。chrome/browser.runtime.sendMessage()の先はどうなってるんだろうか。forever/expirable/single/noのメッセージを受けられないのか、受けても無視なのか…

polyfill化してもダメか。

esbuildみつかんねー→yarn add esbuild

WebSerialはnavigatorに所属（ブラウザそのものに対するモノ？）、chrome, browserは拡張機能の話だから関係ないか…？

でもWebSerialを使う場合は果たしてpolyfill(browser)越しにやれんのか？という疑問が出るな。多分そこを避けるためのchrome化だと思うんだけど。

うーん、面倒だけど試しにPolyill使ってchrome→browserに書き換えて動くかどうかを試す、をしないとダメな気がする。血吐くことになりそうだけど。

JavaScript→アセンブラみたいなもん
Reactとか→ライブラリみたいなもん
yarnとか→コンパイラとかMakeみたいなもん

なんとか.jsxとか→Cみたいなもん
なんとか.jsxをyarn buildでコンパイルして、得られたなんとか-build.jsをバンドルして配布するとかそういうことしてる。

という、とっても雑な理解をした。Cとかで書くのと違って、import Reactせずにimport ReactDOMしても実行時までエラーを教えてくれないってのは確かにキツいな…

やっぱpolyfill抜いたことによる悪影響が出てる、としか考えられないんだけどこれ…JavaScriptだのTypeScriptだのについてはよー分からんのだけど、基本構造一緒なのにpolyfill抜いてる（Chrome専用にしてるからだろうが）という部分が違うんならそれが原因なんじゃないのって思いたくなる。

128GBとは…凄い時代になってる…！