ISTM that there are >=two usecases for user-to-user blocks here:

- "I don't want that fellow to see anything I'm posting",
- "I don't want that fellow to respond in threads I start/I contribute to/...".

They seem to be a poor fit for the latter (they don't actually prevent anything in that regard, if not for any other reason than that the "I contribute to" variant implies conflicts over control of who can post to a thread), and work mostly by making it harder for the blocked fellow to find such threads and by unreliably refusing to make such replies visible to public at large.

Having a concept of thread and a concept of the thread owner seems to be something that would be a much better solution for the second usecase. Currently, there's some amount of ownership already present, mostly vested in the admins of participants' instances (they can omit posts from replies collections published by their instances, which will sometimes prevent them from being seen in that thread). However, none of that control is reliable. I think we're living in the strictly-worse compromise between "anyone can reply to any post and everyone who looks at the thread sees that reply (viewer's local blocks permitting)" and "every thread's initial poster can moderate the thread (for some value of moderate)".

I wonder whether we could build something with advisory moderation performed by the thread initiator: have them publish messages about their wishes wrt replies in that thread, and give clients an option to obey that.

NB: I think I've understood an actual reason why people dislike that others don't block their blockees: If A blocked B, B replied to A (as in, disseminated such a reply), then instances that do not block A will see and show that reply to all their users and to people who visit their web UI. (@timorl who might find this potential reason interesting)