おさむのひと
おさむのひと
md5やmimetype検出のため、一度/tmp配下にダウンロードする必要があるようで…その過程でアップロード容量上限に抵触すると連合経由でのノート作成処理全体を巻き込んでエラーとなってしまっていると考えます。 もし対策するとしたら、ノートのみを表示し、添付ファイルの表示をあきらめるとかになるのでしょうか… （本文なしファイルのみのノートが来たらとか、考えることが多そう。他に妙案があればよいのですが）
MkPaginationがマージされての出open
私見ですが、これ以上は対処が難しいかと思います… （入力された内容の意味を判断する必要が出てきそう）
試す限り、以下の部分の動作に差がありそうです。 https://github.com/misskey-dev/misskey/blob/c1514ce91dc08481a092a789ee37da546cdb4583/packages/frontend/src/components/MkSparkle.vue#L48-L66 以下、推測。 1. 上記のアニメーション設定をコメントアウトすると☆自体はレンダリングされている 2. ☆の削除までの時間を延ばし、アニメーション回数を2回以上にすると遅れて動き出す（ただし、repeatCount=2だと1回分しか動かない） 3. ☆が表示された時点で内部ではアニメーションが動作してる判定になっている？ 4. 1 + 2+ 3 = アニメーション1回ぶんの動作はしている扱いになっているが表面上では動いていない の理屈で…scaleのアニメーションも上記によりサイズ0の状態から動かずに消える＝見た目上☆が表示されない…みたいな感じになっているのではないかなと
（自分が実際に使ってみての感想） カラム表示で横幅が狭い状態でリモートノートを受信すると、その人の名前＋アカウント名＋サーバのドメインでだいぶｷﾞｭｯとなっています。 慣れの領分ではなく、もはや視認性のレベルだと思うので、再考したほうがいいように思えます…
メインカラムだとたしかに感ありますね。 ただ、自分はSTLカラムを出していて、その上だと↓のようになっております… 
（そも、「名前欄を縮めてまで全体を読みたいか」というニーズがあるかどうか…）
①APから受信した情報をもとにノートが作成されるとき、IDの採番はサーバごとの設定による（受信したものが持つIDはそのまま使用されない） https://github.com/misskey-dev/misskey/blob/develop/packages/backend/src/core/NoteCreateService.ts#L405 ②meilisearchも①のIDを使ってインデックスされている https://github.com/misskey-dev/misskey/blob/develop/packages/backend/src/core/SearchService.ts#L115 …ので、 > インスタンスごとにID発番形式が異なる については気にしなくてもよいのかもと思いました。 （なんか変なこと言ってたらスルーしてください）
ああ、なるほど・・・
オブジェクトストレージのマルチパートアップロード機能を前提に実装する必要がありそうな感じがします……？