The protocol as it now sits will not keep you "safe" from threads in any meaningful way.
Repeat. After. Me.
The protocol as it now sits will not keep you "safe" from threads in any meaningful way.
I don't mean as in "it will not protect from a malevolent actor" sense. I mean in an ordinary, reasonable behavior sense.
#ActivityPub not only does not have the tools for this, it makes assumptions that are fundamentally opposed to the kinds of protections that people seem to be seeking.
@hrefna sorry.
i mean. i really honestly would like to learn what to do. i read what you wrote and i do agree.
I'm also personally in favor of not federating with threads, but if this cant be done at the moment, then there is urgency to do something about it.
Which means upgrading standards to support it i guess. ...or if there is literally nothimv that can be done about it and you believe (at least i do), that threads will just mean enshittification of mastodon just like with what happened
Because blocks aren't shared with anyone in the base design it means no one else can enforce your blocks. Even other well behaved servers that you trust.
I can go on.
Mastodon or Akkoma or whatever may have ameliorated these concerns today, but that's an implementation detail that there's a 99% probability is an undocumented implementation detail.
New implementations aren't beholden to them and may not know about them even if they want to be well behaved.
This should (SHOULD) make you rather uncomfortable.
There is no way, in the protocol, and in fact the protocol's platonic ideal, has no requirement that they even behave consistently or inform you of what their behaviors are. If the server you are on were to switch tomorrow to another that doesn't support domain blocking and everyone is using the platonic ideal of the S2S and the C2S protocols you'd have literally no way of knowing it.
One can argue that a protocol should not have to carry some of these aspects, but my point is more subtle than that:
AP gets involved in these areas and expresses opinions about them, making it the domain of AP. To me it is ridiculous to make strong statements about how things must be and then turn around and say "but the consequences of this are not my business."
Even if it isn't within the formal definition of the protocol, we need these things to be attached to how we think of AP.
Support projects that think about safety and acknowledge these kinds of problems. Letterbook is an example, but there are others.
Pressure implementations to adopt a practice of publishing their subdialects and formalizing them with test suites. Work to improve the general state of conformance testing.
Pressure (or join) SWICG to either work to improve this situation or get out of the way of those who do work to improve this situation.
You can also support developers/projects who are doing work to make the situation better in specific areas.
Regardless of the how, we need active energy and committed attention. It's also something that no amount of "fediblocking" or "harassing Eugen/others to block threads on m.s/others" will accomplish or aid.
This is not something that will be repaired by default or that we as members of the fediverse should ignore.
This is something where we need you to take an active role.
@hrefna great thread. The (limited) safety mechanisms in today’s fediverse are despite ActivityPub, not enabled by it. Is it okay if I quote and link to this in a blog post or two?
@hrefna Thank you for digging into these issues. I think that we are facing the classic case of a protocol built with an assumption of trust, and then used in a context in which that trust is dubious. The challenge is to retrofit the security controls required when trust is absent, and then do that without breaking the existing community.