https://mstdn.kanagu.info/@cobodo/101493042557675528
あ、これは自分の所有するデバイス間を暗黙に想定していたので、 LAN 内でという前提でお考えください
ssh経由で秘密鍵を運ぶと、その秘密鍵の想定強度が鍵自身の強さじゃなくて、転送に使った経路の暗号強度に依存するようになって管理が無理になる気がする。
SSH とか物理メディアじゃ駄目なんですかね (よくわかってない顔)
ぶっちゃけmastodon APIが各種エンドポイントの引数にIDじゃなくてURIを取るようにしてくれていればIDを使う必要なんて完全に無いよ
いや、そうでなくても静的型付け言語で実装する場合はJSONからのdeserialize時に困るだろうけど、stringに変えるだけでしょ。stringで降ってくるんだし。
例えばブーストのようなことをAPIでする際はIDを要求されるけど、このIDはブーストしたいアカウントの所属インスタンスにおけるIDになっている。ブーストしたいトゥートがブーストしたいアカウントの所属インスタンスから流れてきていることなど絶対に仮定できないし、そもそもそのトゥートがそのインスタンスに流れてきていない可能性すらあるので、まずブーストしたいアカウントの所属インスタンスで対象トゥートのURIを(search APIで)検索して、該当インスタンス内にそのステータスのIDを確定させ、そのIDをもってブーストのリクエストを叩くようにしてある。IDはこの一連の処理でのみ使用され、他に保存したりはしない。
というのも、IDというのはインスタンスごとにuniqueではあってもグローバルにuniqueではないので、複数インスタンスとの接続を前提とする場合、クライアント内に保持するtootをuniqueに指定する識別子としては使用できないため、ロクに使っていない。
これまで内部DBやカラム設定などに数値でIDを保持していた部分が全滅である。かといって放置していたらPleromaユーザのクズどもから「APIの規約はこうだから対応しないアプリが悪い」と言われるのだ。
この変更にはオイゲンさんは関わっておらず、Mastodon開発者の一部がPleromaと敵対したくないという理由で定義を変更してしまった。それで割を食うのはアプリ作者である。要するに「Pleromaでも動くようにIDの扱いを丸ごと変えろ」というお話。ひどい。
マストドンでのIDの取り扱いは余計面倒な方向に進んだらしい。 https://source.joinmastodon.org/mastodon/docs/commit/e086d478afa140e7b0b9a60183655315966ad9ff これ結局アプリ作者に面倒を強いる方向だなあ…。
[RTA] キャッスルヴァニア 白夜の協奏曲 Maxim in 29.60 https://nico.ms/sm34537630?ref=twitter_ss #sm34537630 #ニコニコ動画
政治的なアカウントや