Untitled attachment

Notices where this attachment appears

1. Embed this notice
   eso (eso@fsebugoutzone.org)'s status on Saturday, 05-Apr-2025 17:23:57 JST eso

   in reply to
   @p @goatmeal
   >https://git.freespeechextremist.com/gitweb/?p=fse;a=blob;f=lib/site/mrf/no_incoming_deletes.ex;h=5a50a544256b6213e4c56d18111ac19881279203;hb=HEAD
   >Once the information leaves your computer, you have no control over it
   It's mindboggling how many people fail to understand this
2. Embed this notice
   pistolero (p@fsebugoutzone.org)'s status on Saturday, 05-Apr-2025 17:00:24 JST pistolero

   in reply to
   @eso @goatmeal Yeah; activity streams are modeled as a linked list and the head is a signed sequence ID and pointer to the first item in the list. This makes AP-style delivery a little complicated, but it does mean that deletes are O(1).
   
   On the two other main servers, they're O(n*m). So, say you delete a post. Pleroma uses the "deliveries" table to track this so it knows where to send deletes (and this table does not even sort of scale) and it sends one delete per activity, while Mastodon (in typical Mastodong style) just sends a Delete activity to every other server that it federates with (and if you suddenly thought "Oh, holy shit, if they instance-block someone, that server never gets deletes again!" then you are correct and you're ahead of them). Account deletion is worse: say you have 100k posts and your instance federates with 10k other servers. That's 1m outbound requests: Pawoo has actually DoS'd other instances by doing that.
   
   So, since it's content-addressed, this makes rebuilding the linked list difficult: you have to walk down, then rebuild the subsequent nodes. But that puts the O(n) onto the person doing the delete.
   
   There is an asterisk here: it's content-addressed, and other nodes don't have to delete anything, and the idea is you do not want to have to trust other nodes. That is more or less how fedi already works. Even nodes that try to run clean sometimes have to ignore things out of self-preservation: SPC had to temporarily ignore inbound deletes because of that. FSE has ignored inbound deletes (for reasons explained at the top of the file, https://git.freespeechextremist.com/gitweb/?p=fse;a=blob;f=lib/site/mrf/no_incoming_deletes.ex;h=5a50a544256b6213e4c56d18111ac19881279203;hb=HEAD , although we started doing it because of a malicious admin; long story) for a long time and we still got flooded, Pawoo was sending dozens of requests per second, they were getting hit by the rate-limiter, and that made them retry the requests.
   
   Anyway, deletes will work fine but don't expect to be able to trust computers that you do not directly control.
   pawoohits193.png