tamaina
レンダリングバグを疑うならFirefoxで違う結果になるかだけでも確認したらいいと思うけど
「sharedInboxがなくなった」という内容のアップデートがあった場合にnullに更新できなくなりそう
分割したものをつなぎ合わせるシステムが意外に面倒 (RFCもなさそう) - s3のマルチパートアップロードの利用を考えてAPIを設計する？ - Misskeyサーバーからクライアントへ一時idを発行する時は、完成後のURLを推測されないようにする必要がある
PUTに対する課金ってマルチパートアップロードの場合どうなるんだろう
S3マルチパートアップロードを使わない場合 - クライアントから別のクラスタにパートが送られる可能性もあるので、Misskeyバックエンドがアップロード前につなぎ合わせる処理をする方式は取れない - ので、ひとまずパートごとにダイレクトにオブジェクトストレージもしくはローカルファイルに保存しておいて、クライアントがファイルを要求するときは、Misskeyバックエンドに`/files/`で繋ぎ合わせながらダウンロードできる機能をつけるみたいなのが考えられる * ただしこれはバックエンドにストリーミングの負荷がかかる - もしくはクライアントが要求する？ * クライアントはメモリが無理そう - 動画はHLSにしちゃうとか？ * mp4を全部読んで解釈しなきゃいけないので無理そう？ * S3のPUTコストは膨れるけどアップロード終了後に後処理で動画専用処理をやってやる（サーバー管理者がオプションでこれをやるか選べるようにする）というのもありっちゃあり
PUTコストはかかるがファイルアップロード終了時に整理して後々のMisskeyバックエンドの負荷を減らす(動画はhls化/それ以外は単一ファイルとして再アップロード) vs PUTコストをかけず/files/で繋ぎ合わせたものをダウンロードさせる (Misskeyバックエンドの負荷は増える) みたいなのを選べるようにすればいいか
Misskeyの場合水平スケーリングを考慮する必要があるため面倒 アップロード途中のファイルをPostgres, Redis, ObjectStorageのいずれかに保持しておく必要がある
アップロードも大変ならダウンロードも大変なので、いっそのことファイルのダウンロードもクライアントで繋ぎ合わせさせればいいのでは(
濫用を避けるためにチャンクの最低サイズを設定できると良さそう(16MBとか?)