Conversation
Notices
-
Consider a stronger version of the delete rejection policy: upon receiving a delete request, the instance does not only reject it, but, if the object is not in the database, fetches it from another instance known to reject deletes.
Is such a setup possible? Has anyone done this?
-
@Inginsub Remote instances do not expose remote AP objects directly, so you'd have to query the API and recreate the object yourself, a bit too much wor k to do. Having an MRF that instead pushed a post edit with "this user tried to delete this post at XX:XX" might be less of a hassle.
-
@cassidyclown @Inginsub It won't be able to do anything with delete request for a post that wasn't cached in a first place, but it would at least offer some more context to conversations. Still, many reject deletes for performance reasons, and having a whole new activity to be applied might have a negative effect on that.
-
@mint @Inginsub that would achieve the same effect anyway right
-
@Inginsub @cassidyclown Can't be a dick if you can't get an erection thanks to database dysfunction.
-
@mint @cassidyclown what if I don’t care about performance and just want to be a dick instead
-
@mint @Inginsub what if you get the object url from the delete request and plug it into the search of an instance that rejects deletes, grab the url of the resulting post and paste that into the message i.e "user tried to delete this post, archived at https://urlofpostoninstancethatrejectsdeletes" - wouldn't be the same as having it on your own instance but at least it would make it more accessible without messing with the db
-
@cassidyclown @Inginsub Without a post
-
@cassidyclown @Inginsub Without a post being cached, here's no way to know which thread does this post belong to.
-
@cassidyclown @Inginsub Ah, I'm retarded and forgot about the API part and focused on Delete activity itself which doesn't reference anything but the deleted post.
-
@mint @Inginsub unless you used the "in reply to id" of the post on the remote instance api and then used the api to get the object uri of that post the deleted post was replying to and then plug that back into the search of your own instance and grab the post id so your bot can reply to the post the deleted post originally was replying to. This is assuming the post the deleted post was replying to wasn't also deleted - could do a check on this and then go up to the next reply id until there's a post that wasn't deleted. If it wasn't replying to anyone then a standalone announcement from the bot would suffice.
:ihavenomouth:
cassidyclown
All ０７６萌ＳＮＳ content and data are available under the