おさむのひと
おさむのひと
- user_note_piningにsortを持たせる - UserEntityServiceのpack時に↑のsortで並び替えるようにする - プロフィール画面にピン留めノートの順番を入れ替えるUIを用意する - ピン留めノートの順番を入れ替えるためのAPIを用意する とすれば実現できそう…？
連合時の挙動はこれから調査する必要あり
うーん、順番まではコントロールできなさそう？
仕様に明るくなさ過ぎて`collections/featured`についての言及を見つけられてないのですが、どこかにあったりします？ いちおう https://www.w3.org/TR/activitypub/ は検索しましたが…（見落としかもしれないけれど） OrderedCollectionは[記述](https://www.w3.org/TR/activitypub/#collections)を見つけていますが、 ``` 逆時系列の順序を決定するためにどのようなプロパティが使用されるかは、実装の詳細として意図的に残されています。 たとえば、多くの SQL スタイルのデータベースは、識別子として増加する整数を使用します。 これは、ほとんどの場合、挿入順序の処理に合理的に使用できます。 他のデータベースでは、挿入時刻のタイムスタンプが優先される場合があります。何が使用されるかは重要ではありませんが、要素の順序は変更されず、新しい項目が最初になる必要があります。 「最終更新」タイムスタンプなど、定期的に変更されるプロパティは使用しないでください。 ``` みたいなことも書かれており、連合経由での順番入れ替えは難しい可能性も…
参考になります、ありがとうございます 🙏
前提として、「リモートのファイルをキャッシュする」を有効にした時のお話でしょうか（通常はたしかoffだったはず）。 ---- おそらく、下記のような状況を問題視されているのだと思いました。 - 現状のロール上限は「上限を超えた瞬間」にしか削除が走らない → 上限ギリギリに張り付き、キャッシュが入れ替わらない → 結果としてドライブが常時逼迫してしまう - 逆に上限を小さくするとドライブは圧迫されにくくなるが、キャッシュとして保持できる量が減るため、 リモートに対するリクエスト回数が増えてしまう つまり「容量を確保しつつドライブを逼迫させない」という両立が難しい状態かと理解しています。 自動削除があれば、キャッシュの効果を保ちつつ、ドライブ容量の逼迫を回避できるのでは…という旨のご提案だと解釈しました。
 チャンネルのミュート・アンミュートはこちらから。 分かりにくい位置になってしまいましたが、今の画面構成だとここに置くのが限界だと思い… ユーザのフォロー画面のように出来ればいいのかもしれませんが、あまり派手に変えるとチャンネルミュートの本筋から逸れてしまうのでひとまずこの形式で実装しました。
ready for review
コンフリ解消済み
次にしたいかも・・（2025.5.1はもうだいぶ大きいので）