MeiMei

実データで検証したのがあったのだわ  **用語** Sign (Node crypto) → 署名 Verify (Joyent) → 検証 (現行のhttp-signatureモジュール経由のエンジン) Verify (Node crypto) → 検証 (Node標準を使用しての実装) **考察** 鍵アルゴリズム間の違いは概ね一般的に言われてる通り。 しかし、Node v16 (OpenSSL v1) に比べて v18 (OpenSSL v3) 以降は性能が大幅に劣化...

上記検証コード https://github.com/mei23/crytest あと、現状の`http-signature`モジュールのままed25519にすると、署名が10倍速くなって検証が40倍遅くなるので本末転倒感があるのだわ

> また、フラグを変更した場合は再投稿時などでリモートにも反映するようにして欲しい ドライブファイルをid付きのAP Object扱いで公開して (現状はNote.attachmentに付いてるidなしオブジェクト) フラグ更新時にUpdate Documentを送るようにした方がMisskey同士の連合ではいいかも。 DriveFile→添付されているNote→送信対象 を出すのがちょっと負荷高そう？

> 区別するインスタンスはサポートしないで良いかも 大文字と小文字を区別して一意性制約とするデータベースと 大文字と小文字を区別せずに一意性制約とするデータベースの同期など出来ないから それでいいというかそうせざるを得ないと思うわ。

> これしなかったらどうなりますか？ 相手側に大文字小文字違いの重複ユーザーがいなかったら、いちおう取得（＆認識）できると思うのだわ。 ただし、相手側に大文字小文字違いの重複ユーザーがいた場合は 結局重複している方のユーザーはDBにINSERT出来なくて存在しないことにされると思うのだわ。

> つまりなくても何かが新しく壊れることはないと 大文字小文字違いの重複ユーザーがいない場合のみうまく動くようになるが それ以外の場合は動作不定になるのでどちらかがベターかは私には判断できないわ

> 二つのノートのactorが大文字小文字違いの重複ユーザーだったらいまでも動作不定になりそうですがどうでしょう 確かにidの方はスキーマ上はcase sensitiveだわね。 かと言ってusernameの方をcase sensitiveに寄せられないし、めんどくさいわね。

確かに、WebFingerでlowercaseを使う理由は特にない。 lowercaseを使わないようにすれば、このIssueの問題である「WebFinger リクエストに失敗する」は解決する。 （その解決されたユーザーがDBにINSERT出来て認識出来るかどうかは保証できない） ではあるわね。

> node-version以下のバージョンを使っていると起動できない仕様がおかしい気がする > 推奨バージョンと最低バージョンを分けたい インストールとビルドは出来るのに起動時にバージョンチェックして落とす仕様は極めて不親切なので、 package.jsonの`engines`に動作バージョン記載しておけばいいと思うのだわ。

AP向けだと前後にゼロ幅スペース入れてるけど、ローカル投稿でしてないのはなんでかしらね https://github.com/misskey-dev/misskey/blob/b0030d148db99b76d6283a8692a89671760665d0/packages/backend/src/core/MfmService.ts#L365