misskey 極力論理削除にする

Summary

そっちの方が便利(クエリするときは削除フラグの考慮が挟まってめんどいけど)
データ量が多すぎるなど、通常の物理削除が困難な場合でも削除することができる

Mar 13 '21 03:03 syuilo

んーただメモリ使用量の増加とパフォーマンス低下が懸念される

Mar 13 '21 14:03 syuilo

削除フラグ(deletedAt)をそれぞれのテーブルに加えることになるが、今までreadなクエリを発行している箇所ほぼすべてでdeletedAtを見る必要があるので、deletedAtにインデックス張ることは必須と思われる

Mar 13 '21 14:03 syuilo

別に真理値でもいいか

Mar 13 '21 14:03 syuilo

👀 https://github.com/typeorm/typeorm/pull/5034

Mar 13 '21 14:03 syuilo

↑の機能を用いれば改修規模は抑えられそうだけど、パフォーマンスが気になる

Mar 13 '21 14:03 syuilo

GDPRによると論理削除は認められていないっぽい

GDPRに従い論理削除は実装しない
GDPR対応しないのどっちか

Sep 01 '21 11:09 syuilo

流石に論理削除実装できない縛りはつらすぎるから個人的には後者かなという感じ (GDPR厳守しようとすると、同じユーザー名のユーザーを何度でも作れることになったりするので…)

Sep 01 '21 12:09 syuilo

同じユーザー名のユーザーを何度でも作れることになったり

他のサーバーでもユーザーが物理削除されるのであれば、とりあえず連合については問題はない気がするのだけれど

（Misskeyって重要な処理でusernameを参照子として使っているのかしら？

Sep 01 '21 12:09 tamaina

他の全てのサーバーからも削除される保証ないからなああとテキスト内のメンションは連動して削除されないから不整合生じそう

Sep 01 '21 12:09 syuilo

他の全てのサーバーからも削除される保証ない

とりあえずほかのアプリケーションの開発者に頑張ってもらうってことで……

あとテキスト内のメンションは連動して削除されない

テキストのメンションは投稿時にパースされてmentionsカラムに含まれるので、~~影響ってMFMのリンクを拾ってこれないとかぐらいじゃない?~~
idがmentionsに含まれるなら消える(or 消しようがある)んじゃないかしら

Sep 01 '21 12:09 tamaina

Not being GDPR compliant could create many issues for misskey server administrators. And probably also for users from the EU. This is because GDPR applies worldwide if data of a EU citizen is processed. Please do not implement Misskey in a way that can not be made GDPR compliant. 🙏

I am not a legal expert, but please also note that deletion in GDPR only includes 'personal data'. So not everything has to be deleted, only data that can be traced back to a specific person. So I think only keeping the username could be in compliance with GDPR. It always depends on if the data is "personal data". For example, protonmail.com says they do not use an email address again even if it is deleted. So they also have to keep a list of deleted user accounts.

Why I think only partial deletion (for example setting most fields to empty string) would be okay: Article 17 (right to erasure) only applies if there is no legal basis for processing. In this case I believe that keeping for example a copy of the username would be a "legitimate interest of the data controller" (Article 6 Section 1 Letter f GDPR).

Sep 01 '21 12:09 Johann150

I think deleting everything except the username would be similar to what Pleroma does (although for slightly different reasons), see for example https://git.pleroma.social/pleroma/pleroma/-/issues/1687#note_55848 or https://git.pleroma.social/pleroma/pleroma/-/issues/2497#note_81986 which says:

local accounts are kept with only enough data to reserve the nickname, this is because of an ActivityPub design issue (otherwise you could end up reading/getting data from the previous user with the same nickname).

Sep 01 '21 13:09 Johann150

やっていきたい

Aug 28 '24 02:08 syuilo

やるか

Sep 19 '24 08:09 syuilo

普通に https://github.com/misskey-dev/misskey/issues/10659 をやれば良いだけの話な気がしてきた

Oct 09 '24 21:10 syuilo

https://github.com/misskey-dev/misskey/issues/10017#issuecomment-2702966568 こちらに引用しておきます。

リモートの投稿だとRN等で復活する

Mastodonの場合、TombstoneというNoteの墓標テーブルがあって、リモート投稿が削除された時（Deleteアクティビティを受け取った時）に投稿者のidと投稿のuriを記録しています。モデレーターが削除した場合はフラグをつけて記録されます。これでRNなどによる復活を防いでいます。リモート投稿専用です。

リモートアカウントが削除状態になった場合、不要になったTombstoneはまとめて消去しています。

また、投稿にも論理削除フラグとしてdeleted_at（削除日時）があります。こちらはローカルもリモートも一緒です。

（時間の掛かる関連データのバックグラウンド削除処理が完了する前に）削除を即時反映させるため

モデレーター削除の場合に、証拠として投稿内容を保持し、処分を取り消す場合に投稿を復活可能とするため

即時反映は、複雑な削除処理中のエラーにより削除漏れとなることを防ぐ効果、削除と同時にリノートやリアクションなどがあった際に削除中の投稿が復活したり状態が矛盾することを防ぐ効果も持っています。

なお、消去権等の関係で、証拠としての保持など特段の理由のある場合を除き、本人が削除を実行したデータを論理削除で保持し続けることは権利侵害となり得るため、必要以上に保持しない対応は必要です。

Mar 06 '25 07:03 noellabo