@julian I think I have some pretty great solutions to all of this! But I can't really document any of it until the other dev work on my app stabilizes a little bit.

It's great to hear there would be support for the idea, at least in principle. I'll probably ping you about it once I have something written out about it, if that sounds good.

@evan Real name policies are a good way to mitigate certain kinds of abuse but ultimately they tend to also get used for top-down abuse.

I've been penciling out some distributed reputation stuff that could solve this problem without becoming a privacy/surveillance thing. I plan to try implementing it sometime after I actually finally launch my app. FEP work to follow if I can suss that out.

I had a dumb thing in my #ActivityPub implementation.

I was getting these broadcast Delete announcements tied to Person objects from servers out in the wild, and was dutifully trying to validate their signatures. I didn't have the key here, and they're signed by the deleted Person, so loading the key gave a 404.

So the next thing it tried to do was see if loading the Person remotely gave a 404, and if so, it's a legitimate Delete, problem solved.

But what I think was happening was that the attempt to load the Key, then the attempt to load the Person, both flagged the remote server "hey this guy doesn't know about the Delete", and it received another copy of the Delete action. It's possible each Delete caused two copies of itself to get re-queued. Holy forkbomb.

So I stuck a little bit at the top of Delete validation that checks to see if I have the target object, and chucks the message in the bin if not. This was in my original implementation but got lost when I did some refactoring.

It sat for an hour, just processing THOUSANDS of backed up Delete messages.