Well, that's interesting. DM blocking on #Mastodon means your instance still receives the message, but it's simply not displayed to your face.
Just one of those quirky parts of #ActivityPub
Well, #ActivityPub is very much focused on instances, not users, and it focuses on broadcasting content farther, not carefully tailoring where content goes.
I imagine this is a case of ActivityPub being intent on getting that DM to the recipient instance (not user) and letting the recipient instance deal with the rest of the picture.
Things similar to privacy aren't priorities in ActivityPub.
> #ActivityPub is very much focused on instances, not users
@volkris I'm not sure what makes you say this, but my interpretation of the specification is definitely not that. ActivityPub is focused on disseminating activities to "recipients", which most of the times are actors, or collections of actors. Blocking DMs is probably a Mastodon thing (the server receives an activity which has an actor's inbox as a destination, but due to that actor's settings, it won't make it ithere).
@volkris Block is what ActivityPub has as a "mute" - and by extension one can infer Ignore should work similarly, but that's only defined on blocking another actor, not a "dm" or "dms" as in a category of posts.
A related issue that I always try to highlight is that many users here misunderstand the privacy settings, believing their content to be more secure than it really is. I think that's a serious issue.
In this case, I'd argue that ActivityPub/Mastodon doesn't really have a DM feature, as many know that term. The messages aren't direct or secure. Instead, they're sent to the remote instance with a note saying the content is only for the remote user, but it's really up to the instance to deliver it privately or rebroadcast publicly or whatever.
The lack of two way interface in blocking reflects that.
It's up to the remote instance to do what it wants with the content, hopefully dropping it into the void if the user asks for that to be done. Or might publicly broadcast later, idk (to borrow the phrase)
@volkris
Understanding the nitty-gritty of the tech is necessary to understand the privacy status. Most users don't get into all that. I was a little taken aback when I realized that Hubzilla/Streams/Nomad servers (had to) keep the private key of accounts in order to function.
Anything hosted can be considered not private (except E2E, but not in many applications - not even e-mail as you said elsewhere). Self-hosted Tor service, equivalent P2P, is all there is?
@mariusor
It's not necessary to understand the nitty-gritty. It's a matter of raising user awareness, preferably through UIs that do an effective job of informing users of what's going on.
Just for example, on my client here there's a button called "Adjust toot privacy" and *at the least* I'd rephrase that to toot audience, toot reach, or toot broadcast.
Maybe even "adjust suggested broadcast" to avoid giving the impression that privacy is particularly guaranteed.
@volkris I think clients need to be more explicit and expose more of the actual recipient mechanism of ActivityPub. I think that reframing the problem in terms of "privacy" is less correct.
Yeah my complaint/criticism is just that the user interface talks about privacy toward this audience or that audience while the user will be unaware of that any audience can potentially see the content.
And if I didn't say so above, the issue is that I have also talked to a lot of individuals who are very surprised to find out that they were misled about how the privacy works here. So this is not just theoretical, this is actually what is happening.
I just really wish the platform could be more transparent about how it works.
@volkris
> they were misled about how the privacy works here
In theory, maybe. A Direct Posts between accounts on two instances can - with sufficient digging into the database - be read by the admins of both. That's still fewer people than can read Titter DMs (any engineer with database access plus anyone above them in the company hierarchy).
In practice, nobody reads your DPs except (sometimes) the intended recipient. Unless you've heard otherwise?
@volkris not surprising, maybe the protocol handshake involves knowing just the sending server, not the sending account?