#fedibird 有効期限付き投稿は、Pawooの自動消滅トゥート機能と似ており、同じような効果が得られますが、異なるものとお考え下さい。
今後、無限に増え続ける投稿を、連合する各サーバが無限に保持することは難しくなってきます。
他サーバのキャッシュもそうですが、ローカルの投稿についても同様です。
投稿者の選択およびサーバのルールに基づき、保持する期間を限定するという考え方も必要になってくると考えています。
そういう意味合いも含めての、有効期限です。
なお、有効期限は、もともと規格に含まれるものではありませんので、合意事項は何もありません。各サーバはこれを無視することができます。
(削除リクエストが来た場合は話は別です)
現在のtootctl status removeのように、スレッドを形成していたり、お気に入りやブックマークの対象となっているものを保護したり、非公開とするが、関係者だけは引き続き参照できるようにしても良いと思います。
投稿は、投稿者が自由に削除でき、APIのレートリミット以上には制限されていない。しかるに、自動で削除する機能は、手動での削除より顕著に負荷が高いなど特段の配慮が必要なければ、同様に自由に利用できて良い。
Pawooでは自動消滅トゥート機能が実際に長年提供されてきており、投稿者・閲覧者に十分な利用経験がある。これを参考にしたい。
マイクロブログ・ミニブログとして考えた時に、公開期間を指定するのはおかしくない。
有効期限を過ぎた際にそれをどう扱って欲しいかは、第一にユーザーの選択である必要を感じる。
取り扱い方法については現実的には2種類に集約されそう。hintまたはdelete。
hintは、期日を明示するだけで、取り扱いを一任する。削除してもいいし、隠してもいいし、何もしなくてもいい。
deleteは、ローカルで削除するとともにDeleteActivityを飛ばしてリモートへ明示的に削除を依頼する。漏れた場合にも、リモート側が自動削除することを期待する。
SNSのデザインとして、希少性(期間限定・ここだけで公開)で煽る効果はMastodonのポリシーと相性が悪い。
#fedibird いろいろなことが考えられるので、意見を聞かせて頂けると助かります。
リアルタイムに張り付くことを求められるということについていえば、たとえば、有効期限の最短を1週間にするという方法もあります。
負荷については、たとえば、全投稿にデフォルトで1ヶ月などの期間設定を行い、全て削除リクエストを飛ばすとします。削除リクエストは、投稿する速度と同じ速度で飛んできます。
投稿と削除の負荷は同じではありませんが、同じペースで時間をかけて実行されるのは、ある種、理想の負荷分散かもしれません(さらに、12時間ずらすなどの工夫も考えられます)
tootctl statuses remove との違いとして、ローカルの投稿削除があります。
expires_atで有効期限を短くする方に目が行きますが、expires_atを指定しない、ずっと残しておきたい投稿が識別できるという側面もあります。