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 ...
-
Domain blocking is not a feature in ActivityPub
Authorized fetch is arguably in _violation_ of the required treatment of public objects
Public objects must be shared without authentication and when it was asked to change this the response from members of the SWICG was, at best, hostile
There's a requirement for dereferencable ids that makes this all fundamentally harder
Forwarding from the inbox removes control
The protocol conflates ids with objects and either can be sent in _any_ case
2/
-
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.
3/
-
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.
Again, not hostile, intrinsically and _by design_.
4/
-
How do we _fix_ this?
IMO:
We need implementations to define subdialects and for ways to communicate about those subdialects.
We need a real extension mechanism that isn't just "this is how you get something into the AS namespace."
We need to create documented norms about when we do or do not share objects vs. links.
We need to push back on situations where the protocol is unsafe and call out examples.
We need to acknowledge the problems and see where we can find a way forward.
5/
-
𝓼𝓮𝓻𝓪𝓹𝓪𝓽𝓱【ツ】☮(📍🇬🇧)replied to Hrefna (DHC) on last edited by
@hrefna so should we upgrade mastodon or qctivity spec or abandon mastodon, because it cant and hence will inevitably be overrun by threads?
-
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.
6/
-
Hrefna (DHC)replied to 𝓼𝓮𝓻𝓪𝓹𝓪𝓽𝓱【ツ】☮(📍🇬🇧) on last edited by
This is not what I said, anywhere, and borders on a bad faith reading of what I am saying.
-
Christian Huitemareplied to Hrefna (DHC) on last edited by
@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.
-
What are some steps you can take?
* 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.
etc.
7/
-
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.
8/8
-
@[email protected] 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?
-
@jdp23 go for it ^_^
