tech, Mastodon, fediverse blocks, long 

@Thib @cwebber i feel like this is misattributing consequences

3 is not a side effect of 2. 3 is the primary purpose. it is a bug and a huge mistake to treat it as a mere "side effect". 1 is a side effect of 3, if anything.

also, your issue with 1 is not wholly a mistake of the protocol in full. the mistake is sharedInbox for private posts --private posts should *not* be delivered to people outside their audience.

@trwnh @Thib @cwebber

> the mistake is sharedInbox for private posts --private posts should *not* be delivered to people outside their audience.

Right but even if it's not a sharedInbox it needs to exist on the shared server. If I block X@Y, and A@Y is a friend who can get private posts, no matter what happens, server Y is going to need to handle my private messages I send to A. And if Y is malicious, well.

This might be solved with some kind of end to end encryption.

@darius @Thib @cwebber well if a server is showing messages from one actor's inbox to another user that isn't authorized to view the inbox, then at least that makes it spec-incompliant

but yes, encrypting inboxes with your key could be done (shifting the problem slightly, from "malicious software" to "malicious admin"). you'd have to run your own client for it to matter, and monolithic apps like mastodon effectively bundle the client with the server.

@trwnh @Thib @cwebber I guess my main issue here is that you have to assume that malicious actors won't comply with the spec.

@darius @Thib @cwebber i guess my issue is that mastodon's architecture creates new problems outside of the spec

@trwnh @darius @Thib @cwebber
Maliciousness is not an actual requirement for harmful behavior. It's enough to do unwanted favors with the best intentions. Mastodon makes some compromises for performance and other compromises to support interaction. The sum of these compromises is a problem

First, you cannot send "Reject: Follow" when you mean "Block" because you're still federating block information even if you're not using the syntax described in the spec. You're also expecting the target server to retain that information, which is neither reasonable nor possible to assurance

Second, the origin has to provide explicit routing when message delivery may be affected by information that the destination server doesn't have. If you need to deliver to collections in most cases, then you need to identify the exceptions and handle them at origin

When someone on an instance is blocked by the sender then that instance can't be relied on to expand collections in its shared inbox. I'm not addressing implementation details beyond that. Perimeter security with current practices means that instances supporting vulnerable people need to block instances that allow toxic members or federate with toxic instances. That's what needs to be improved immediately

Maliciousness is a problem, but it's not *this* problem. Vulnerable people are capable of dealing with harmful situations decisively. The problem is dealing with centrists leaking information to harmful people while they waffle about the nature of the threat. If implementations deal with the leakage, theorists have a grace period to work on more comprehensive ways to address active threats

@yaaps @darius @Thib @cwebber Reject Follow is imo distinct from Block and also from Undo Accept Follow

if the Follow is stored (as it should be, since Follow must be Accepted and therefore cannot be transient) then you should be able to send Undo Accept Follow to return that account to the "follow requested" state, and Reject Follow to explicitly deny the request.

>instance can't be relied on to expand collections in its shared inbox

i'd argue this is true *always*, not just with blocks.

Follow

@yaaps @darius @Thib @cwebber in short: it is a Bad Idea to deliver non-public activities to sharedInbox, full stop. that cedes access control completely (and access control requires, well, *control*)

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!