The lemmy devs should really focus on proper content deletion tools. It’s not just the images, it’s very strange and inconsistent overall. When I delete a comment, it’s seemingly still visible to many people and collecting up/downvotes even many hours after I deleted it. On the other hand, when a post gets deleted, it’s completely gone, to the point that I can’t even look up the discussion that I had within that post, just my own comments on my profile.
Clicking delete on one server does not magically delete content on other servers, federation needs to happen first and there’s usually a queue for that. If the delete command hasn’t reached remote servers yet, those servers will receive upvotes, downvotes, reactions, you name it. Your local server will likely refuse most of those, but other servers who have a copy of your comment will have a differing local state until the delete request makes it over. If your server, or the remote server, is slow for a while, federation can take minutes to hours to complete.
Not only that, I can restore your deleted comment/post on my server and start commenting on it. My comments will only show up locally on my server, but funky deletion behaviour is just one of the ways Lemmy and centralised platforms differ.
On most servers, the post table is a lot smaller than the comment table, so even on your local server the delete button may take a moment to work, though I wouldn’t expect that to take too much time.
I’m not sure why your deleted stuff is still collecting votes, I think the server should be refusing those. Maybe there’s a bug somewhere?
And even if you delete a comment the API will still provide the message content as due to federation shenanigans it’s actually just hidden.
If you need to remove something, edit and redact the message first.
It’s always only had a handful of real devs dedicating time to it. A whole site like this is kind of a huge undertaking, especially when you’re deciding to build it from the ground up in a modern language like Rust, and on top of a relatively new API set, ActivityPub.
Even from early on, I remember lots of discussion from people with database management credentials who were basically pounding their heads going “why are you guys doing it this backwards way?” I don’t follow the development super closely so I don’t know if those issues were resolved or not. I just remember a lot of discussion on it when I was first on Lemmy on a different instance.
Anyway, the short point of what I’m saying is they probably have a plan that makes sense to them, but without more external poking on certain things, they will work on what they think is important first, which may not always line up with what the community thinks is important.
Once again, it’s a handful of folks doing front-end-dev, back-end-dev, and admining a very large instance.
I don’t follow the development super closely so I don’t know if those issues were resolved or not. I just remember a lot of discussion on it when I was first on Lemmy on a different instance.
not that i’m aware of, and fixing a database schema once it’s already in place tends to be a clusterfuck so i’m very skeptical it will get better any time soon
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.
The lemmy devs should really focus on proper content deletion tools. It’s not just the images, it’s very strange and inconsistent overall. When I delete a comment, it’s seemingly still visible to many people and collecting up/downvotes even many hours after I deleted it. On the other hand, when a post gets deleted, it’s completely gone, to the point that I can’t even look up the discussion that I had within that post, just my own comments on my profile.
Clicking delete on one server does not magically delete content on other servers, federation needs to happen first and there’s usually a queue for that. If the delete command hasn’t reached remote servers yet, those servers will receive upvotes, downvotes, reactions, you name it. Your local server will likely refuse most of those, but other servers who have a copy of your comment will have a differing local state until the delete request makes it over. If your server, or the remote server, is slow for a while, federation can take minutes to hours to complete.
Not only that, I can restore your deleted comment/post on my server and start commenting on it. My comments will only show up locally on my server, but funky deletion behaviour is just one of the ways Lemmy and centralised platforms differ.
On most servers, the post table is a lot smaller than the comment table, so even on your local server the delete button may take a moment to work, though I wouldn’t expect that to take too much time.
I’m not sure why your deleted stuff is still collecting votes, I think the server should be refusing those. Maybe there’s a bug somewhere?
And even if you delete a comment the API will still provide the message content as due to federation shenanigans it’s actually just hidden. If you need to remove something, edit and redact the message first.
It’s always only had a handful of real devs dedicating time to it. A whole site like this is kind of a huge undertaking, especially when you’re deciding to build it from the ground up in a modern language like Rust, and on top of a relatively new API set, ActivityPub.
Even from early on, I remember lots of discussion from people with database management credentials who were basically pounding their heads going “why are you guys doing it this backwards way?” I don’t follow the development super closely so I don’t know if those issues were resolved or not. I just remember a lot of discussion on it when I was first on Lemmy on a different instance.
Anyway, the short point of what I’m saying is they probably have a plan that makes sense to them, but without more external poking on certain things, they will work on what they think is important first, which may not always line up with what the community thinks is important.
Once again, it’s a handful of folks doing front-end-dev, back-end-dev, and admining a very large instance.
not that i’m aware of, and fixing a database schema once it’s already in place tends to be a clusterfuck so i’m very skeptical it will get better any time soon
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.