MeiMei

- moveToを取得しておく => 雑魚い - API/UIにまで反映させる => ちょっとめんどい - Move Activityに対して引越し先を検証する => 罠はあるけどやれば出来る - Move Activityで何かをする => 何をするのか (Follow/Mute/Block/List追従？ユーザーに選ばせる？通知のみ？) みたいなのを決めるコミュニケーションがめんどい って感じなのだわ

AP周りの罠はこのあたり - 引越し元と引越し先をそれぞれ取得してINSERTする実装にすると、元と先 双方が新規だった場合にループするので避けること。 - 引っ越し先がループさせられるのを防ぐこと。 - 引っ越し元と先を検証するときは最新のデータを使用すること。

さらすなって 考え方は多様だから最終的にオプションにするしかない感だわ

- ドライブという機能を提供している以上、アップロードしたファイルをあまり改変したくないところがあります。 - また、動画は最初は自動再生はされずにサムネイルが表示されるだけなので、それほど影響ないのではと思います。 - アニメーションgif=>mp4などの、形式変換を行ってしまうとその形式の画像が上げられなくなります (てゆうか、これMastodonにある大嫌いな機能) - 負荷 なので、ユーザーが上げたものは極力変換したくないです。

アニメーションGIF/PNGなんかはstatic版を用意して使うなどしたほうがよさそう #2996 #2175

たぶんメンションを付け忘れてるんじゃなくて、 `users/search`が「ローカルマッチのアクティブ順, リモートマッチのアクティブ順」で返ってくるから、使われてないローカルを選んじゃうんだと思うのだわ。 「ローカル/リモート問わずマッチのアクティブ順」にするとか。

2bb0a61a891445df4d78bfc0d4a64551ac9b7a39 でしれっと 11 => 12 に変えてるけど大丈夫だったんですかね 多分アウトだけど、たまたまdocker-composeのPostgreSQLで本番運用しているところがなかったか、泣き寝入りしたか…

特定ユーザーだけ `users/get_frequently_replied_users`がタイムアウトする (サーバー側でエラーになってるかも) APIの問題なのでデスクトップでも起きる ぽい

This behavior is by design. There seems to be a problem with the design of this feature in Mastodon and it cannot be fixed. Since the domain that appears in...

最初はリアクションピッカーの初期10種類の表示順でした 他の絵文字も使えるようになったタイミングでその順番には出来なくなりました (しなくなった) その時点から事実上挿入順になっているはず (keyに数値扱いされそうな文字列は登場しないので) その際、挿入順以外だと新しい種類のリアクションが到着した時に位置が動いてしまうので こっちの方がいいかみたいな温度感だった気がします。