Deletions shouldn’t be difficult because of the schema. For instance, this query: select display_name, ('https://your.lemmy.host/pictrs/image/' || pictrs_alias) as image_url, pictrs_delete_token from image_upload iu inner join local_user u on u.id = iu.local_user_id inner join person p on p.id = u.person_id; will list all media, with the display name of the user who uploaded them, and the token that can be used to delete the image. Obviously, this needs a where u.id = ? parameter to only expose the list to the right user, but adding a “delete old media” page really shouldn’t be that hard. It’ll require time, though, and with one of the two devs taking parental leave soon, I don’t think there’s that much dev time for a while.
The pieces are almost in place, they just need an API endpoint and some UI work.
That query by itself in a vacuum is fine. Combined with many other triggers on the DB, and then federating that out before actually deleting from the local DB… well that is what creates all sorts of headaches.
Images aren’t federated through ActivityPub so I don’t really see how deleting media is supposed to work. Best you can do is delete media for deleted posts.
The API call for deleting media already exists. It’s actually used in the comment compose screen (you can click the “click here to delete” popup after uploading media). So all you need to do with this info is send a POST request to the existing API endpoint.
I don’t think the Lemmy database uses triggers on media uploads at all, I don’t think Diesel support those well?
Images aren’t federated through ActivityPub so I don’t really see how deleting media is supposed to work.
Yes, they are. Every instance downloads everyone’s images for a “cached” version that is currently never used. This is what makes this problem especially insidious and straight up dangerous in cases like CSAM.
Deletions shouldn’t be difficult because of the schema. For instance, this query:
select display_name, ('https://your.lemmy.host/pictrs/image/' || pictrs_alias) as image_url, pictrs_delete_token from image_upload iu inner join local_user u on u.id = iu.local_user_id inner join person p on p.id = u.person_id;will list all media, with the display name of the user who uploaded them, and the token that can be used to delete the image. Obviously, this needs awhere u.id = ?parameter to only expose the list to the right user, but adding a “delete old media” page really shouldn’t be that hard. It’ll require time, though, and with one of the two devs taking parental leave soon, I don’t think there’s that much dev time for a while.The pieces are almost in place, they just need an API endpoint and some UI work.
That query by itself in a vacuum is fine. Combined with many other triggers on the DB, and then federating that out before actually deleting from the local DB… well that is what creates all sorts of headaches.
Images aren’t federated through ActivityPub so I don’t really see how deleting media is supposed to work. Best you can do is delete media for deleted posts.
The API call for deleting media already exists. It’s actually used in the comment compose screen (you can click the “click here to delete” popup after uploading media). So all you need to do with this info is send a POST request to the existing API endpoint.
I don’t think the Lemmy database uses triggers on media uploads at all, I don’t think Diesel support those well?
Yes, they are. Every instance downloads everyone’s images for a “cached” version that is currently never used. This is what makes this problem especially insidious and straight up dangerous in cases like CSAM.