Skip to main content

After much community outcry, Bluesky is finally allow people to block accounts.

That feature is live on their website. And it’s hopefully shipping tomorrow morning.

All is good in the hood, right?

Not so fast…

You needed blocks. We cleared our calendars to finish building out blocks. Blocking has shipped to Bluesky web app users and will be available in mobile shortly (version 1.25, when it passes App/Play Store review — hopefully tomorrow morning). You can access this feature now at staging.bsky.app.
in reply to Chris Trottier

Chris Trottier
Chris Trottier
• •

When you block people on Bluesky, your block list is public.

Which means that if someone is blocked, everyone will know.

This approach to blocking may prove controversial.

Important: Similar to your likes, your block list is public data! While users of the Bluesky app can’t easily find this list now, the data is public and enumerable at the protocol level. This means that third-party apps or clients can surface and display your list.
in reply to Chris Trottier

Koree A. Smith :stl_blues:
Koree A. Smith :stl_blues:
• •
that isn’t the dumbest shit I’ve heard this week, but it’s pretty close. Why would they do that?
in reply to Chris Trottier

Chris Trottier
Chris Trottier
• •

Right now, blocks won’t work with third party Bluesky clients because blocks are not currently supported in AT protocol.

It surprises me that this feature is still not available protocol-wide.

Blocks may or may not work on third-party clients in the short term. Some amount of blocking functionality will work, but because this is a protocol-level change, it will require coordination to get it working across the ecosystem.
in reply to Chris Trottier

Ben Ramsey
Ben Ramsey
• •
It’s because they’re designing the protocol themselves. It’s not an open, community-driven process, so they’re not often thinking about the things the community needs.
in reply to Chris Trottier

Chris Trottier
Chris Trottier
• •

I have a feeling that blocks will be public due to how DIDs work on Bluesky.

When you migrate your DID from one server to another, you have to tell it who you’re blocking.

in reply to Chris Trottier

Danger mouse
Danger mouse
• •
And since part of the business model seems to be "a plug-in infrastructure for relevancy algorithms" (my wording), this info has to be "publicly available" (on the API level).
in reply to Chris Trottier

Emelia 👸🏻
Emelia 👸🏻
• •

that is really, uhhmmm, how to put it politely? Stupid.

Making the act of blocking or muting someone public can result in retaliation & that person evading the block. *sigh*

in reply to Chris Trottier

Big Jesus Trashcan☑️🏴
Big Jesus Trashcan☑️🏴
• •
I have heard people say I'd rather have a list of who has you blocked more than to know who your followers were. Dystopia social media. The enemy of my enemy is my friend?
in reply to Chris Trottier

jwz
jwz
• •
I can see that being problem in that it gives the blockee an unintentional boost, but personally I want everyone to know who I blocked so they can block them too. I'm more of the school of:
in reply to Chris Trottier

Phil Stevens
Phil Stevens
• •
That's a dealbreaker for me. Not that I was ever interested in going there, mind you.
in reply to Chris Trottier

The Evil Microwizard
The Evil Microwizard
• •
That is utterly horrendous, not to mention horrific! Your blockist should be on a strictly need-to-know basis, which basically should be you (directly) and the service's (through indirections as necessary to maintain your privacy).
in reply to Chris Trottier

Pär Björklund
Pär Björklund
• •
@rmondello isn't this kind of required to implement blocking? Servers need to know who I blocked to not show my boosted posts to blocked users in the federated timeline
@Ricky Mondello
in reply to Chris Trottier

Jesse
Jesse
• •
It's... public? That's... so many levels of disturbing. There's so much harassment potential there. Damn.
⇧