@pwm@Yoruka@bajax@ctr@gav@iamtakingiteasy@kanon@lunarised@menherahair@s@shibao There's only one thing to do: fire off a server-crippling query to have it isolate the posts that included that image but that have a timestamp in the database earlier than the timestamp on your copy of the image, then find the one with the closest timestamp from the set of posts you interacted with.
...FSE's DB used to be small enough that I could do this. Sandwich-repost.gif
though, on the other hand, a lot of the network is nearly blast proof because the data is just rotting away is some dank corner of some unknown server. Big, old instances are the outlier and liability there, but the effect is cool, I guess.
When I lose my mind and write a fediverse server implementation it will not be a steward of the network, but a leech.
@pwm@bajax@gav@ctr@Yoruka@iamtakingiteasy@kanon@menherahair@s@p@shibao@lunarised Yeah, but media gets lost unless there's someone secretly running an instance with mediaproxy warming and proxy_store. A couple times (skyshanty, leafposter, now seal.cafe but I don't know if it's still shutting down) I've mass-downloaded attachments in advance when there's been an announcement but that's a teardrop to the ocean of piss. There's also booru.daggsy.com, not sure if it's still up and pretty sure it ignored non-discoverable accounts anyway.
> FEDIVERSE INSTANCES WERE NEVER MEANT TO BE ARCHIVES
UNTIL NOW
> though, on the other hand, a lot of the network is nearly blast proof because the data is just rotting away is some dank corner of some unknown server. Big, old instances are the outlier and liability there, but the effect is cool, I guess.
Yeah, I don't think every server on fedi has to be that way, but the fact that some of them are has been useful. I have recovered stuff that was on one server by using someone else's server.
> When I lose my mind and write a fediverse server implementation it will not be a steward of the network, but a leech.
Actually in the earlier days I'd just grep the backups, which resulted in zero burden on the server, or I'd periodically load one of the old backups into another Postgres. (This was how I tested eliminating the Gab spam; eventually settled on eliminating activities from users that no one on FSE was following and that had no likes, and that severely reduced the size of the DB on-disk once it was dumped/restored again.)
If your main option is doing this kind of thing on the live server, it's actually helpful to break up the query so locks don't happen. Same way you'd do it if you were going through the API, just remember the last ID and do `where id < $the_last_one order by id`, things like that. because.mp4