stacker news 、いわゆる `like` も sat だから、 sat たくさん持ってる人が影響力を持つってことかな？
stacker news の FAQ を読んでる。
- 投稿とコメントには最低 1 sat が必要で、スパム避けとクオリティ維持のため。
> each post and comment requires a small fee to prevent spam and to encourage quality contributions.
> Post and comment fees start at 1 sat.
Twitter API がいつ使えなくなるのか待っているが、今朝も使えてた。2/14 だけエラーになった。
- 2/13 OK
- 2/14 エラー
- 2/15 OK
- 2/16 OK
https://twitter.com/TwitterDev/status/1625234161010343941
`a few more days` と言っているのでそろそろ使えなくなりそう。
> There has been an immense amount of enthusiasm for the upcoming changes with Twitter API.
> Twitter APIの今後の変化に対する熱意は計り知れないものがあります。
あと、皮肉が効きすぎている :D
あと、Iris で青ではなく黄色のバッジが付くユーザは何なのか調べてみたら、
- フォローしてないが友達が10人以上フォローしているユーザ
という意味らしい。Iris がフォローをおすすめしているような感じでしょうか。
https://stacker.news のアカウントの作り方
- stacker.news で sign in を押す
- 表示される LNURL をコピー
- Alby で Send 押す
- LNURL をペースト
これでアカウント作れました。
Sign in じゃなくて Sign up でした。
https://stacker.news のアカウントの作り方
- stacker.news で sign in を押す
- 表示される LNURL をコピー
- Alby で Send 押す
- LNURL をペースト
これでアカウント作れました。
snort を local で動かすと速くなる気がする件は、多分プラシーボ... しばらく使ってるとやはりレスポンス遅くなる時がある。
snort で使える markdown は CommonMark から link, linkReference, image, imageReference, definition を除いたもの。
とりあえず、snort は markdown link には対応していない。末尾にスペースつけるだけ。ってことでいいのかな。
> fiatjaf deleted the safer-markdown branch 2 weeks ago
となってる。
まあ、markdown は使わないことにしよう。でも # つけると意図せずでかい文字になったりするのはやめてほしい
https://github.com/v0l/snort/pull/153
結局この後どうなったのか追いきれていない。
snort の markdown 対応がよくわからない XD
Test for snort's markdown link.
[link1](https://snort.social/)
[link2](https://snort.social/#test)
[link3](github.com/getAlby/lightning-browser-extension/blob/ce1b4b0e48493ec82fbc4af46fa7237af3ce0d02/src/extension/background-script/state.ts#L98)
snort をローカルで立ち上げてるんだけど、https://snort.social/ よりサクサク動く気がする。
例えば、ページスクロールして一番下まで行った時に、次のポストが表示されるまでの時間が明らかに速い。
でも、アクセスログを見るとサーバにはリクエストが来てないから、ブラウザ側の処理かリレーからの返答の時間なんだと思うけど、この違いはなぜ起きるのかな？
docker 使える人試してみてください。
```
git clone https://github.com/v0l/snort.git
cd snort
docker build -t snort .
docker run --rm -it -p 80:80 snort
# http://localhost にブラウザでアクセス
```
`decryptData` は AES。password は平文。
```
const password = get().password as string;
const privateKey = decryptData(account.nostrPrivateKey as string, password);
```
pick で password を除外されるので `browser.storage.sync` には保存されていないはず。
```
saveToStorage: () => {
const current = get();
const data = {
...browserStorageDefaults,
...pick(current, browserStorageKeys),
};
return browser.storage.sync.set(data);
},
```
```
% cat ~/Library/Application\ Support/Google/Chrome/Default/Sync\ Extension\ Settings/iokeahhehimjnekafflcihljlcjccdbe/000003.log
password はなかった。
```
NIP-07 の実装の件、Alby はどうなってるのかなと思って調べてみた。
- 秘密鍵は AES で暗号化した上で `browser.storage.sync` に保存
- AES のパスワードは平文だが `browser.storage.sync` には保存していない(おそらくメモリのみ)
- AES のパスワードは Chrome 起動毎に入力
という感じなのでちゃんと実装されているようです。Lightning 方面はさっぱりわかりませんが、NIP-07 に関しては Alby で良いかもしれないです。
詳細は次のポストで。
NIP-05 のこれか。
> Showing just the domain as an identifier
>
> Clients may treat the identifier _@domain as the "root" identifier, and choose to display it as just the
https://github.com/nostr-protocol/nips/blob/master/05.md#showing-just-the-domain-as-an-identifier
もう少しマシな方法としては、OS が管理しているキーチェーン(macOS なら`キーチェーンアクセス.app`)に秘密鍵を置いて、そこから情報をもらうという方法があります。
Chrome の Native Messaging という仕組みを使うと、外部コマンドと stdin/stdout で情報をやり取りできるようなので、外部コマンド内でキーチェーンにアクセスして秘密鍵を取得して、外部コマンド内で署名を行って、その結果を Chrome に返すという方法があります。これだと Chrome には秘密鍵を保存せずに済みます。
NativeMessagingを用いたnostr NIP-07実装例については #[0] さんがプロトタイプを作成されています。
nostr-keyx では、共通鍵(AES-GCM)で暗号化しているので、共通鍵を手に入れないと復号化は難しいです。共通鍵はメモリに置いているのでディスクのバックアップでコピーされることはないと思います。
% cat 000003.log
encryptedPrivateKey
"[\"0FsY962F4VMLS4My1HyfKWLSm/Rl6fdTM5i/ni0Z251o4Fgbfx5njvj+x5XSHhniZlQsOuxAQSu6y4Zjl+8Xn3bM6+139ov0WYp+APMOu+Q=\",\"/11uhVPrZeKcCbl9vbYE6Q==\",\"m96A5oRooKs9Ut3/aeHkWA==\"]"
共通鍵はメモリに置いているので Chrome を終了すると共通鍵は消去されます。なので Chrome を起動する毎にパスワードを入力して共通鍵を生成しないといけないということと、もし Chrome のメモリを覗き見されて共通鍵がバレると秘密鍵は復号化されてしまいます。