Why are blocks on Bluesky public?
atproto.com
atproto.com
Is this a design I'd like to use? Or a gaping privacy hole attempted to be explained away through "implementation reasons"?
Maybe I want to grab a list of those I also want to block. Or negatively weight.
Conversely, the follow list can add positive weight until I say otherwise.
Distributed email spam and trust lists.
There's the potential for creating a strong filter bubble, but if the user can control their own system's behavior it still seems like a win.
Seriously, it's worse than on Twitter. Bluesky slowly starts looking like "let's redo ActivityPub but so we can make money off it".
enforcement means it needs to be read-able by the relevant software
"optionally" public means that software that can't see the block list can't enforce it
and that means the only way to enforce the block list (reliably) is in your client (which presumably always had read permissions)
this is in no way controversial
i'm unaware of any practical implementation that would address the given use case
if you know otherwise, please point me to it!
However, that shouldn't be the default.
I'm not sure why this page keeps bringing up that "people on other platforms can find out if they're blocked or not". You're always going to have ways to detect that. It doesn't address the conclusion "so it may as well just be public".
There's something to be said for server-local blocking ("muting"), which this post also advocates. However, if you're going with that approach, why put "real" blocks in your protocol?
The second party can find out if they're blocked by the first party.
A third party cannot find out all the people that the first party blocked.
That's a massive usability difference.
the third party can fetch a list of all valid user IDs, and sequentially query the first party about each of those user IDs
it takes more time and may be subject to e.g. rate limits, but the information is equally available
Only if the third party is allowed to query whether there's a block between the first party and the second party. If the block is only visible to the first party, i.e. there's a view filter, then there's no good way of figuring this out.
if blocking information is only available to a given third-party on an opt-on basis from the blocker, then what purpose does this information serve?
"Hey, I know that your server has an extensive personal blocklist, can I take a look at it and adapt it to my server so that I don't start from scratch?"
a "block list" is associated with a user, not a server
You should have both I think. One so the other person knows, one so the other person doesn't know explicitly.
PS: I don't use Bluesky at all, just from previous experience on forums.
Who is the entity that is supposed to keep mods/admins "in check"?
In short - public reputation and ban info is fun, interesting and somewhat a social limiter if the reputation still exist on a particular forum. And there are no negative factors for this really. I'm speaking from experience on other older forums I've participated.
> In theory, a bad actor could create their own rogue client or interface which ignores some of the blocking behaviors, since the content is posted to a public network. But showing content or notifications to the person who created the block won’t be possible, as that behavior is controlled by their own PDS and client. It’s technically possible for a rogue client to create replies and mentions, but they would be invisible or at least low-impact to the recipient account for the same reasons. Protocol-compliant software in the ecosystem will keep such content invisible to other accounts on the network.
That is, compliant clients are expected to mute any interactions between blocked users, even if rogue clients continue to generate such interactions. Only users on other rogue clients would be able to see them. So the hope is that almost all recipients would not be using such clients.
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.
(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.)
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.
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?
You can't even create a mastodon test account to test (and disprove) this theory?
You don't even need an account. You can disprove this nonsense by visiting any Mastodon server and looking at the local feed and confirm that most posts are accessible to anyone.
Your instance won't get posts pushed to it if nobody on that instance follows a given account, but you can still pull unless an account is private, and at least one instance implements a kind of follow that pulls to let people keep tabs on accounts without openly following them.
It's an algorithmic choice, but most who've used these platforms for years know public blocking can also be a form of abuse on these kinds of protocols.
BS could (and this was done by the people who sunk Scuttlebot/Patchwork) for example choose to list all of the people who block you on your profile page as an act of shaming and exclusion.
Assuming BS is p2p, which is another topic.
As mentioned, someone can figure out that they've been blocked, but they can't be certain. There's no way to know who another member is connected to. That's also private to the member, so the logging in as an anonymous user can see that you are available to unblocked members, but not who you are connected to. You can infer that you are blocked. Also, nothing is truly public. Only members can even see other members, and, currently, every member request is vetted by a human. We're not going for scale, which means that getting that sockpuppet account might not be so easy.
That's mainly because of the demographic we Serve. There are quite a few dangerous people, therein, so we need to be pretty circumspect about privacy and security. We make sure that every member has full control of their privacy and data, and we also default to the most secure. No dark patterns to trick people into divulging information.
That said, it's a simple community app, so we can't throw too much friction into the way members interact with each other. If someone is really worried, they shouldn't use our app (or any other social media app, because ours is more anal than most).
Then the person blocked doesn’t even know.
Unlogged people can’t see anything. The app is pretty much useless, unless you have an account.
There's nothing stopping you from writing a Bluesky (or Mastodon) server that doesn't respect blocks, shows a list of users that you have been blocked by or gives you block notifications. On centralized networks with closed-off APIs, you can make first-party apps respect block semantics and the point of blocks is accomplished (friction increases.) On decentralized networks, users can just migrate to non-block-respecting instances, and nobody else will ever know whether another instance respects blocks or not.
I think what you are describing is majority-accurate (arguably https://docs.joinmastodon.org/admin/config/#authorized_fetch addresses some of it, though it's not watertight) for public content. However, quite a lot of people set up their profiles/posts with access controls.
You need to gather the messages from various huge AP instances for anything close to a good recommendation algorithm.
I think the whole algorithm situation is exactly what's wrong with social media today, but it's also what makes people come back for more. Sadly, I think BS will beat AP in this regard because of that.
Further, development on ActivityPub is not "done," correct? As in, someone could technically still write/develop their own client and attach its own algorithm over the top of ActivityPub, right?
To be clear, I hope I'm not sounding like my opinion on this is definitive or anything and I'm just having a conversation. There are definitely problems with ActivityPub, it just sounds like BlueSky is trying to solve/fix every problem that every individual person maybe/possibly/who knows will have before they even launch which, in my experience, is generally a concerning approach.
Do they intend to federate or are they implementing a federated protocol?
That's not a failure in any way. Actually, I think it's a much more respectful approach than what many social media companies are doing. However, it does severely impact the effectiveness in which this network of small servers can push "stuff you might like" to other users. Some major instances may be able to implement a Twitter-like algorithm, but most of them won't have the messages to recommend to people.
BlueSky has chosen a complex model that basically exchanges huge amounts of data. That should allow for the algorithmic crap that AP servers will struggle with.
Don't get me wrong, I consider AP to be better than BS because of the designs and business concerns involved. However, from what I can tell from the people around me, people want the addictive social media algorithms, outrage posts, drama videos, you name it. Every platform with this crap has people addicted and coming back over and over again. Mastodon and friends mostly seem to contain people interested in each other and their work (and not just in good ways) rather than people pushing for high algorithmic scores to boost follower counts.
This is why I think the fediverse will fail in terms of social media. The predatory alternatives will be able to pull in the general public with ways that AP-based servers never would.
a bloom filter provides no false negatives, but allows some false positives
how do you model an "A-blocks-B" relationship with this data structure?
specifically, how do you ensure that "A-blocks-B" blocks only B, and never C D or E?
if "A blocks C" returns true when A doesn't block C, then this is a problem, right?
it means you can trust false responses (no false negatives), but you can't trust true responses (some false positives)
if you get a true response, you have to confirm it's actually true through some other source, which must not return false positives
that other source therefore must be authoritative, and must also be query-able by any client that can query the bloom filter -- it's no panacea
a bloom filter is an optimization, not a source of truth
However, I think I understand why they’re doing it. Bluesky is modeled after Twitter, which has sort of public popularity contest features built in, like retweets and replies, which can let malicious users signal boost using your account. Without a public blocklist, there’s no way to stop that signal boosting, which gives the upper hand to bad actors.
It’s funny how the article focuses on friction to circumvent blocking, which is real, but doesn’t mention that their solution greatly reduces friction of discovering who blocks who. Because traditionally that discovery is tedious and not scalable.
I don't use twitter enough to understand what this means. How can a malicious user signal boost using your account? Regardless of blocking. I don't understand what that means. No one else can force you to retweet or reply if you don't want to.
Not a Twitter user myself either. But I think it works like this: popular user posts something. A troll account replies to that with something edgy. Then the followers of the popular account will see the troll’s comments. Thus the troll has been signal boosted.
Afaik blocking is a solution to this problem.
instead of publishing the list of people I don't want to hear from
i also think it's fine to let everyone know who i've blocked, but people have different threat models
hash(x) != x
are you OK with the bank using a hash of your account number to identify your account instead of the number itself?
of course not -- any risk of collision, no matter how low, is unacceptable
that's the baseline -- risk tolerance is zero
you have to justify any increase of that risk on a case-by-case basis
To repeat that guy's question, do you avoid going outside in order to avoid freak lightning strikes?
definitionally, this means each output value maps to multiple input values -- which means uniqueness is, factually, not guaranteed
it doesn't matter if the likelihood of collisions is 1-in-10, or 1-in-100000, or 1-in-1000000000000, or etc. -- if a collision is possible at all, then uniqueness is not guaranteed, and cannot be assumed as true
Especially because in the real world even a mathematically perfect system has a baseline failure rate. If the chance of hash collision is orders of magnitude lower than the baseline failure rate, then there is no downside to using that hash.
what? no. absolutely not.
the "baseline failure rate" of a program with some input values X is zero.
> in the real world even a mathematically perfect system has a baseline failure rate.
what? no. absolutely not.
x = 1
print(x)
this line of reasoning is absolutely invalid -- hash(x) != x
i can control what my application uses as IDs
Please explain how the benefit outweighs the cost to spend even 30 seconds to prevent a potential problem with 10^-40 probability. (And by that I mean 10^-40 total probability, not per-item.)
> this is not a probabilistic program, there is no baseline failure rate above zero, the output must be "1", any other output means the program is incorrect
You could have a power outage, or the OS could crash, or the CPU could have a bug on those opcodes when certain counters roll over at the exact wrong time, or a bit could flip in your memory.
The baseline failure rate for a program on a computer in the universe is never zero. This isn't abstract math. And the collision rate of many hashing systems is much smaller than that baseline failure rate.
There are even situations where assuming a hash never collides can increase reliability, because the code will be done sooner and that improves the baseline.
say the probability of a solar ray bit flip is (say) 0.01%, then consider the following function
fn x -> int {
if (randf32() < 0.0001) { panic("boom") }
return 123
}
is this acceptable? can i assume that calling x will never panic, in practice?
Why not? Cryptographically, entropically, there's no difference between a call to "give me a uuid to throw on this new account" and "now crunch it through a sponge function and use that instead"
Your uuid generator will probably check for uniqueness, or your database will enforce unique values, so there's a few places you would be alerted of the collision, but 2^256 is a very large number
if we're talking about hash(x) == x then the hash function doesn't consult any central DB to compute a UUID or evaluate uniqueness or anything
there is no UUID generator or DB involved
It’s really trivial to get to accounts blocking you if all you need to do is open it in your browser’s private/incognito/guest mode.
I think activity pub solves this by just not notifying blocked accounts about new posts anyway. So you can just silently stop appearing in their feed. But maybe that’s not feasible in bluesky.
Why are the blocks so total (or, rather, why is "mute" not the default behavior) given the simplicity of overcoming the read block? Also, isn't the main reason to block is to avoid seeing something bad anywhere?
For context, it seems like Elon Musk is toying with the idea of removing blocking from Twitter [1].
As another aside, I'm personally exhausted with the pet projects of annoying billionaires [2].
[1]: https://www.techdirt.com/2023/06/09/elon-musk-says-twitter-i...
[2]: https://www.nationalreview.com/news/twitter-founder-jack-dor...
The main problem federation solves is centralization of power and perceived abuse of that power. The type of stuff that caused the Twitter exodus and now Reddit. I’d argue that many users do care about that, but I would concede that it’s not clear that federation will solve those problems. Instance operators can go on equally destructive power trips, the way eg AP and mastodon are designed.
Kind of like filter lists for adblock. I would like to subscribe to naziblock, magablock,botblock, and trollblock please.
If someone is upset with another person then everyone can see it, body language alone. Online blocks make pretty much no sense, as the type of person who needs to be blocked will just make more accounts or otherwise persist. The reasonable person who doesn't need to be blocked can be reasoned with and will be reasonable.
Accounts with unreasonable blocks tell on themselves if the blocks are public.
I've been subject to black ball / whisper lists so my perspective may be rare. But I picture the people who've come against me being at a party with me and their behavior is very anti-social. People would quickly notice something weird going on, where online I'm just blocked and muted and nobody else knows.
I don't block anyone but I am aware there are people who can't be reasoned with and they've been the rare exception who've ended up blocked by me in the past. I know they can still access my activity and drop in with anon accounts. "Social media" is more like sociopathic media in its current state. The more like an IRL party things are online the better, so public block lists are an upgrade.
Throwback: AOL/AIM's public warnings. People would start IMing when you got a warning, ask "what happened?" That was pretty social.
Moderation was solved in the 90s.
Who does it report abuse to? What happens to the post? What happens to the person who powered it?
To name just two issues: It doesn't scale without paying a lot of people, and deciding what to moderate precisely, reproducibly, and fairly is a major unresolved issue.
How can you look at twitter and facebook and make a statement like that?
Slashdot would like a word with you
very similar to the real world, if someone comes to my dinner party and they’re a dick, i make them leave. done.
however, somewhere along the line people got it in their head that they could behave however they wanted and the person hosting the party somehow had no rights to remove them.
it boggles my mind that some people are still struggling to understand that this really is no different from the real world analogs. this is a people problem, not a technical problem.
in the real world there are neighborhoods, bars, events, etc… with little to no interference or expectations of behaviors, think of the hole-in-the-wall rough bars in the rough areas of town where violence breaks out regularly.
then think about the bar with massive security/bouncers who take no shit and remove people quickly.
but we still have these people who believe you can have both at once. it’s just never going to work.
you’re either going to have a bar where everything goes: spam and child porn and violent behaviors are accepted or you’re going to need some kind of bouncers removing people who are doing fentanyl at the bar.
of course there is a spectrum in there, but at the end of the day, this is a human problem, not a technical one. anytime someone tells you there can be no moderation, then it will absolutely be full of spam and child porn and all kinds of other shit. if we remove those, then we’re now absolutely and firmly in the “ok, yep, we accept moderation” territory at which point it’s just a matter of “what kind of clientele does our bar want?” and we tailor our expected behaviors accordingly.
as you pointed out, in the early days it was just understood, “ok, we want to hang out in this bar, so we’ll behave accordingly. it is their space afterall.” this is why we had such a massive diversity of places to go. so many different irc networks each with different expectations. so many different forums. so many different comment sections. so many different newsgroups. etc…
the root of this is not a technical problem. its really not a problem at all unless we’re somehow expected to pick only one bar we go party at (which is absurd, btw) sometimes i like to eat at nice restaurant and once in a while i like to slum it at a shithole bar. and most of the time i prefer parties amongst just me and my friends.
again, this is basic human relation shit. but these guys keep going on these wild goose chases—repeatedly showing how little they understand people. ironic af considering what they’re doing…