3 ms·

Yes, I know; where do you think I got the idea from? :) Client-side mute is a different feature than the blocking discussed here. They have both (Ctrl+F "mute"

Yes, I know; where do you think I got the idea from? :) Client-side mute is a different feature than the blocking discussed here. They have both (Ctrl+F "mute", the second usage in the article). I am suggesting only having the client-side mute, not bothering with all this server-side blocking stuff which is loaded with caveats. > “Mute” behavior can be implemented entirely in a client app because it only impacts the view of the local account holder. Blocks require coordination and enforcement by other parties, because the views and actions of multiple (possibly antagonistic) parties are involved. Only having mute is still a bad outcome, it's just that it's the corner they've written themselves into here. Private blocks is the feature people actually want, and it's not possible with their architecture.

LegionMammal978 3y ago
Well, I'm mainly confused by your expression that the server-side blocking is defeated as soon as one person has a rogue client; if the goal is that the blocking user and the general audience don't see any blocked interactions, then is it not sufficient if the vast majority of them don't see the interactions because their clients are compliant? Sure, a few people using custom clients would be able to see the interactions, but if they were really interested in seeing what blocked people had to say, they could always have communicated on an external forum anyway. (Although this implementation does let me imagine a funny scenario, where a subgroup of users make "secret" replies visible to each other but no one else, entirely using blocked interactions. I imagine many people would get mad if they discovered such a thing.)
- electroly 3y ago
  Indeed, it's not sufficient. I don't think people want a "eh, it's almost good enough most of the time" blocking feature. They don't want their block list to be public at all (this is a dealbreaker already) and they don't want other people ever to see blocked people's replies dangling off the bottom of their posts. The client-side mute feature prevents 100% of those posts from appearing to the one client, while keeping the list private. The block feature then, necessarily, must be about other people not seeing the replies to your posts. Otherwise, all you need is the easy client-side mute feature. And indeed, I think the block feature is broken enough that client-side mute is the only thing they can reasonably do. There WILL be people defeating the block for anyone who can see it and screenshotting it for anyone who can't. As an obvious example, imagine what would happen if Donald Trump were on Bluesky. He will receive both blocked replies AND people will leak his block list.
  - LegionMammal978 3y ago
    > and they don't want other people ever to see blocked people's replies dangling off the bottom of their posts. What I'm saying is, "ever" is an impossible criterion, for any typical blocking implementation on any online service. Unless the whole stack is DRM'd all the way down, someone could always write up a browser extension or equivalent that lets blocked people overlay the official messages with their own messages, sourced from a separate host. (I'm picturing something like a third-party version of Twitter's Birdwatch.) Indeed, if we allow screenshotting, then even going that far would be unnecessary: people could just screenshot (e.g.) Trump's messages on his own social media site where he quotes the original message, and that screenshot could be spread juat as far as a screenshot from a custom Bluesky client. Generally, I just don't see how it makes that much of a difference if these overlaid messages are transmitted via Bluesky's network instead of a separate network. Are you saying that Bluesky-hosted blocked messages are so much more compelling a mechanism than third-party-hosted blocked messages that this becomes substantially more problematic? (That does not seem clear at all to me a priori; don't people wanting to transmit and receive blocked messages have to put in active effort either way?) Or are you suggesting that all existing block features are broken in this way, and they're acceptable only if they're private?

LegionMammal978 3y ago

Well, I'm mainly confused by your expression that the server-side blocking is defeated as soon as one person has a rogue client; if the goal is that the blocking user and the general audience don't see any blocked interactions, then is it not sufficient if the vast majority of them don't see the interactions because their clients are compliant? Sure, a few people using custom clients would be able to see the interactions, but if they were really interested in seeing what blocked people had to say, they could always have communicated on an external forum anyway. (Although this implementation does let me imagine a funny scenario, where a subgroup of users make "secret" replies visible to each other but no one else, entirely using blocked interactions. I imagine many people would get mad if they discovered such a thing.)

electroly 3y ago
Indeed, it's not sufficient. I don't think people want a "eh, it's almost good enough most of the time" blocking feature. They don't want their block list to be public at all (this is a dealbreaker already) and they don't want other people ever to see blocked people's replies dangling off the bottom of their posts. The client-side mute feature prevents 100% of those posts from appearing to the one client, while keeping the list private. The block feature then, necessarily, must be about other people not seeing the replies to your posts. Otherwise, all you need is the easy client-side mute feature. And indeed, I think the block feature is broken enough that client-side mute is the only thing they can reasonably do. There WILL be people defeating the block for anyone who can see it and screenshotting it for anyone who can't. As an obvious example, imagine what would happen if Donald Trump were on Bluesky. He will receive both blocked replies AND people will leak his block list.
- LegionMammal978 3y ago
  > and they don't want other people ever to see blocked people's replies dangling off the bottom of their posts. What I'm saying is, "ever" is an impossible criterion, for any typical blocking implementation on any online service. Unless the whole stack is DRM'd all the way down, someone could always write up a browser extension or equivalent that lets blocked people overlay the official messages with their own messages, sourced from a separate host. (I'm picturing something like a third-party version of Twitter's Birdwatch.) Indeed, if we allow screenshotting, then even going that far would be unnecessary: people could just screenshot (e.g.) Trump's messages on his own social media site where he quotes the original message, and that screenshot could be spread juat as far as a screenshot from a custom Bluesky client. Generally, I just don't see how it makes that much of a difference if these overlaid messages are transmitted via Bluesky's network instead of a separate network. Are you saying that Bluesky-hosted blocked messages are so much more compelling a mechanism than third-party-hosted blocked messages that this becomes substantially more problematic? (That does not seem clear at all to me a priori; don't people wanting to transmit and receive blocked messages have to put in active effort either way?) Or are you suggesting that all existing block features are broken in this way, and they're acceptable only if they're private?