AWSがSSH公開鍵として`sk-ssh-ed25519@openssh.com`の形式を受け付けてくれないのはどうにかならないものか。一旦別の鍵でインスタンスを作成してからその鍵でログインして`authorized_keys`を編集して`ed25519-sk`の鍵に置き換えるという手間が発生してしまう
AWSがSSH公開鍵として`sk-ssh-ed25519@openssh.com`の形式を受け付けてくれないのはどうにかならないものか。一旦別の鍵でインスタンスを作成してからその鍵でログインして`authorized_keys`を編集して`ed25519-sk`の鍵に置き換えるという手間が発生してしまう
さすが怪しい解説が流暢（"The 'sk' likely stands for "signature key"."）
なぜ私はｴｰｱｲに対してムキになってOpenSSHのソースコードを漁っているのか……
明示的に何の略かを述べている資料は見当たらなかったものの、少なくともOpenSSHのドキュメントに"security keys"という表現は見られるし（<https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.u2f?annotate=1.26>）、ソースコード中でもコメント中で`sk_application`を"security-key application string"と指していたりする（<https://cvsweb.openbsd.org/src/usr.bin/ssh/sshkey.c?annotate=1.148>）
で、本来は何をしようとしていたのだっけか……ああそうだ、`id_ed25519_sk`の「秘密鍵」ファイルをどの程度慎重に扱うべきかを検討していたのだった
この「秘密鍵」ファイルに含まれているhandleというのが"an identifier for a user account"とされてはいるものの（<https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#user-handle>）、典型的には64バイト（ビットではない）の乱数とされていて鍵の導出にも使われるものだから、これ自体が認証の要素をなすとは言えるか。
しかしセキュリティキーを用意した上でそのPINを入力して秘密鍵ファイルのパスフレーズも入力するというのも過剰な気がするしなあ
というかそもそもnon-discoverable credentialsだと端末の数 × サーバの数だけ公開鍵を登録して回るアレにさらに予備を含めたセキュリティキーの数が乗じられて組合せ爆発で収拾がつかなくなりそうだな……。これがWebサイトならhandleはWebサイト側が管理するわけだけど、SSHの場合は自分で管理する必要があるので。
Webサイトごとき（？）にいちいちdiscoverable credentialsを登録させていたら10スロットなんて一瞬で枯渇するだろうから今までは一律でdiscoverable credentialsは使わないようにしていたけど、一部のSSHサーバに対してなら許容範囲か……？
Discoverable credentialsなら`gpg-agent`と比較したときに擬似的に無限に鍵対を生やせるという利点が減るけど、それでもOpenPGPの鍵よりは気軽に生やしたり交換したりしやすいし、`gpg-agent`に対応していない環境（スマートデバイスとか）でも使いやすいはず
このアカウントは、notestockで公開設定になっていません。
そりゃ一般からのAPIリクエストを受け付けずインデックスに徹すれば純粋な計算コストの観点ではそうだろうけど、別に問題はそれだけではないのでは
（いやまあ何かインデックスにクソ強計算クラスタが必要みたいな主張をしていそうな界隈の心当たりがないでもないけど、そちら方面は積極的に観測していないのでよく知らない）
この辺りについて以前にも何か述べていた気がしていたけど、某大有志云々の頃に書きかけた下書きが放置されていただけだった（？）
Non-archival relayやconstellationなどを見ても、技術的な計算コストはある程度"スケールダウン"の見込みもあるのだろうけど、それでもPDSより先の各種サービスにおいて運用者の責任範囲を良い感じにスケールダウンさせる落とし所はやはり見えないように思うのだよな
というか技術的にもconstellationにせよストレージコストが現状でも~2GB/dayかかっているようだけど、これも正直「『プラットフォーム』としては小さい」という程度でしかないし、あくまで「市場」として見たときの参入障壁の低さのような話に過ぎず、個人やコミュニティが自分たちの足場を確保するためのセルフホストとはまた別の趣旨のように感じる（microcosm自体はセルフホストを志向しているとはいえ）
あと細かい話になってくるけど、集約においてはそもそも集約する対象のリポジトリの存在についての知識が必要だと思うけど、新参のPDSが自ら進んで`com.atproto.sync.requestCrawl`しに来るようないわば権威性のあるrelay/AppViewならともかく、そうでないサービスにおいてその辺りがどうなるのかも気になっている
既知のリポジトリから流れてくるレコードに含まれるAT URIから未知のリポジトリを収集するということは可能だろうし、一般にネットワーク、特にこの手の社会的ネットワークがほぼ確実に単一の巨大連結成分（以下GC）からなることを考えるとそういうやり方でも一見何だかんだ良い感じになるのではという気がしないでもないけど、しかしこのGCというのが弱連結についてのものであることに注意が必要で、辺（ここではレコードの参照）の有向性を踏まえると、GCを一方的に参照しながらも自身はGCから参照されることのない弱小アカウントというのは普通に存在するわけで、そういうのを捕捉できるのだろうか
（ここまでの投稿は下書きに雑に手を加えただけのものなので何か整合していない部分があるだろうけど、知ーらね（？））
旧TwitterではDeachoseですら2パーティションに分けて取得する必要があって（<https://docs.x.com/x-api/enterprise-gnip-2.0/fundamentals/decahose-api#decahose-stream>）、なんならTweet compliance streamですら4パーティション（<https://developer.twitter.com/en/docs/twitter-api/compliance/streams/api-reference/get-tweets-compliance-stream>）という規模だったわけだけど、AT Protocolの目指しているところもそういうところだろうし、現時点で酔狂でセルフホストできたところで非本質的という感じがするし、ある程度最適化の余地があるにせよ窮極的には「セルフホストも出来る」という反論よりは目指している方向の違いとして処理するべき議論に思えるのだよな
あーん、わざわざ`developer.twitter.com/en/docs/twitter-api`でリンクしたのにリダイレクトで書き換えられている（？）
Fediverseの人々が言う「セルフホスト」というのはみんなで文字通り万単位ものサーバを建てるようなことを指すわけだけど、その感覚をAT Protocolに持ち込むと正気の沙汰でないことになりそうだし（？）、何と言うか土俵が違いそう
いやまあ、数万×数万もの辺からなる滅茶苦茶な完全2部グラフと化したAtmosphereを見たくないかと言えばちょっと見てみたいけど（？）
こんなことを言っているとFediverseにジャスティン・ビーバー氏が現れたらどうなるか的な揶揄で反撃されかねないので、まあこのあたりにしておくか……（？）
補足として、Fediverseでももちろんそういった入次数0のノードは存在しうるけど、ActivityPubの場合はAT ProtocolのAppViewと違ってそのような場合でも他者の`inbox`に通知を送れるのが大きな違いになる。
弱小アカウントからの通知なんて受け取れなくても良いという考えもあるかもしれないけど（ホンマか？）、しかしサーバを建ててまずとりあえず知り合いに接触を図るというのは典型的なパターンだろうし、もしそこで通知がなされない場合があるのだとすればソーシャルネットワーキングの仕組みとしては割と致命的では（既存プラットフォームでも典型的なスパムと区別しづらい挙動なのでアレだけど……）
まあ一般のWebでも検索エンジンに依存せずにWebページを発見してもらおうとすればout-of-bandな通知が必要になるだろうけど、それは一般の人々のソーシャルメディアのメンタルモデルに合致していると言えるのだろうか。既存の巨大インフラに乗らずに自分でサーバを建てるような人間は一般人ではない？ そうですね……（？）
このアカウントは、notestockで公開設定になっていません。
Decahoseの"c"が脱字していてdeca-という接頭辞を知らない人みたいになっていたことに気づいてしまった……
GIGAZINEにPVを与えないようにWayback Machine経由で開こうとしたら（陰湿）"This URL has been excluded from the Wayback Machine."で逆ギレしている
米当局、フランス人研究者の入国拒否 「トランプ大統領に言及のメッセージ発見」理由に - CNN.co.jp
https://www.cnn.co.jp/world/35230764.html
天邪鬼なのでこういうのを見るとアメリカ合衆国に入国できなくなるような発言ばかりしたくなる（？）
反トランプで入国拒否は誤り 仏研究者が「機密情報保持」―米当局：時事ドットコム
https://www.jiji.com/jc/article?k=2025032200205&g=int
ちなみに当局側の声明
それはそれとして、情報の開示を強要されたときのためにGrapheneOSのduress PIN（<https://grapheneos.org/features#duress>）のようなものがより一般的になると嬉しそう（それで嬉しくなるような人は既にGrapheneOSを使っているのでは？）
しかし生体認証を有効にしていると問答無用で身柄を取り押さえられたときに無力そうなのがなあ。iOSだと電源ボタンを5連打でTouch ID/Face IDを無効化できるけど、咄嗟に5連打なんて出来るかなあ。というかそこからフォレンジックツールで攻撃されることも想定するとさらに電源も切りたいところだし（お前は何と戦っているのか）
というか早口で書いたもといコピーアンドペーストしたスレッドの投稿の一部が何やらBluesky側から見えていないな……
Bridgy Fed、ちょくちょく信頼性に欠けるところがある気がするのだよな。たまに取り消したはずのアクティビティに対応するレコードが残り続けたり……
いや、可能性としてはこちら側から`Delete`なり`Undo`なりが正しく配送されていないという可能性もあるので、どこに原因があるのかは断定できないけど
そういえばBridgy Fedのコードをいじろうとして、しょっぱなの`main`ブランチでユニットテストが通る状態にセットアップするところで挫折してそのまま放置していたのを思い出した……
このCIの準備でも、こう、何やら`pip uninstall`していたりシンボリックリンクを張っていたりと、やけに環境構築が複雑そうな雰囲気が漂っており……
