@gaditb@icosahedron.website

I think the Bluesky example you linked to is an unfortunate illustration of what happens when we expect technical tools to cleanly solve social problems. Making a blocklist public is obviously egregious, but even private exclusions can be exposed through old-fashioned social interactions. For example, someone casually referencing a post might unintentionally reveal to someone else that they weren't included.

In Bonfire, boundaries aren’t meant to control what others do on their own instance (apart from defining who an activity is addressed to, similarly to BCC with email). They’re more about controlling what reaches you on yours. Since ActivityPub doesn’t yet support strong security features like end-to-end encryption or object capabilities, boundaries are designed as a local-first mechanism. They help shape your experience and interactions rather than enforcing strict rules across the network.

So, in your example, if someone starts harassing you, you can block them, or just silence them or the thread in question. From your perspective, those replies disappear, and new ones won’t appear at all. Your instance silently enforces these boundaries by ignoring unwanted interactions, even if the sender’s server is unaware and still allows them to post.

It’s not perfect privacy or hard enforcement but harm reduction and local autonomy in a messy, federated world...

@mayel (You can tell me to, like, look into it myself rather than asking you to explain every detail and stuff. I'm not in a situation where me having that info is relevant to my safety or supporting anyone where it is relevant to theirs. I'm just asking hopefully-useful questions, so while I like learning about how this works from this angle and am enjoying it, if my repeatedly-asking-details is not particularly enjoyable/useful to you/the project, like.)
(I'm not getting thst impression from you, but just in case/to be explicit about my conversational position rather than try to rely on tonal nuances.)

@mayel
-- And I'm sure there are people who, like, have done theoretical and practical work supporting them in these scenarios, who already have a lot of expertise thst doesn't need to be rederived from scratch --

And ask them to know what capabilities they'd need, what they'd reach for given the tools/options this software provides, and try to trace what assumptions they make and whether the implementation aligns with those.)

(Possibly also running scenarios maybe? Maybe e.g. one target with one account, attacker and per-scenario supporting other accounts they can use also, a support-resource person who can react to information they can see through the network. I'm sure people who like actually know what they're doing and are not just tossing out thoughts have better/stronger-formaized suggestions.)