Skip to main content


BlueSky is cosplaying #decentralization
rys.io/en/167.html

> Almost exactly six months after #Twitter got taken over by a petulant edge lord, people seem to be done with grieving the communities this disrupted and connections they lost, and are ready, eager even, to jump head-first into another toxic relationship. This time with BlueSky.

tl;dr:
- #BlueSky seems designed to get secondarily centralized in the "reach" layer (as they call it)
- moderation is an afterthought
- Jack Dorsey

🧵/1

This entry was edited (1 year ago)

reshared this

in reply to Michał "rysiek" Woźniak · 🇺🇦

Don't want to pick on you for this, but there's seems to be a lot of guilt by association on Bluesky. I think a lot of the criticism is well-grounded and overall I'm sceptical of it, but it bothers me a bit that what the funder said about Musk and what Musk did after that was said is brought into the discussion. I think it would be good if decentralised services could learn something from each other. For example account portability can become a problem, and not just for people doing iffy stuff.
in reply to modulux

I think the politics of people creating a given tool are crucial information when trying to understand the tool and predict what the tool is built for and how it's going to be used. Whom will it benefit, who will wield power in it, and so on.

So it is crucial to understand that Dorsey and Musk are basically the same breed of Silicon Valley techbro hypercapitalist.

What Musk did to Twitter, someone will do to BlueSky, as IMVHO it's been designed to allow for that to happen.

in reply to Michał "rysiek" Woźniak · 🇺🇦

I am not saying we should not discuss certain features of BlueSky. Sure, we should have a bit better account migration on fedi, for example.

But my blogpost is not about feature comparison. My blogpost is about how BlueSky is cosplaying decentralization to trick people into another roach motel.

in reply to Michał "rysiek" Woźniak · 🇺🇦

That's a fair point, and I certainly agree that discussing the politics of systems like social networks, where decisions are inherently quite political is legitimate and important. I wouldn't mind a bit more technical comparisons, partly because I'm not very sure how these protocols really stack and what the affordances are. Also from my understanding, Dorsey is one of the funders of Bluesky but is not directly involved and is more of a nostr supporter, so I'm not sure how much operational influence or control he might have.
in reply to modulux

sure. And if somebody writes a technical deep-dive comparison, I will gladly read it.

Dorsey might or might not be directly involved. The connection is still informative as to possible — let's say — philosophical underpinnings of BlueSky. And it meshes well with available protocol documentation.

BlueSky could be different, of course. And if I start seeing signs of that, I will happily eat my words. But we've all been tricked too many times already to give it the benefit of the doubt.

in reply to Michał "rysiek" Woźniak · 🇺🇦

> #BlueSky’s decentralization is a similar kind of decentralization as with cryptocurrencies: sure, you can run your own node (in BS case: “personal data servers”), but that does not give you basically any meaningful agency in the system.

(...)

> The rule of thumb with search and recommendation algorithms is: the bigger, the better. The more data you have and the more compute you get to throw at it, the better your recommendations will be. So it’s a winner-takes-all system.

🧵/2

This entry was edited (1 year ago)
in reply to Michał "rysiek" Woźniak · 🇺🇦

> Of course, fedi could also have some search and discovery algorithms built on top. Operators of such algorithms (there had been a few attempts already) would also benefit from being first and going big.

> But their potential power is balanced by the power fedi instance admins and moderators have (blocking and defederating) and by the fact that fedi is perfectly usable without such algorithms. And by strong hostility of a lot of people using fedi towards non-consensual indexing.

#BlueSky

🧵/3

This entry was edited (1 year ago)
in reply to Michał "rysiek" Woźniak · 🇺🇦

> In a pretty meaningful way, “speech and reach” is the model of #Twitter today. You just don’t get to choose your recommendation/discovery algorithm.

(…)

> The only way to effectively fight harassment in a social network is effective, contextual moderation. The Fediverse showed that having communities, which embody that context and whose admins and moderators focus on protecting their members, is pretty damn effective here. This is exactly what BS is not doing.

#BlueSky

🧵/4

This entry was edited (1 year ago)
in reply to Michał "rysiek" Woźniak · 🇺🇦

> In other words, “neutrality” and “speech” and “voice” and “protection from bans” is mentioned right there, front and center, in #BlueSky’s overview and FAQ. At the same time moderation and anti-harassment features are, at best, an afterthought.

(…)

> Of course the sad reality is that people will buy the hype, build communities under the everloving watchful eye of Jack “Musk is the singular solution I trust, likes are superficial if not paid for” Dorsey.

🧵/5

This entry was edited (1 year ago)
in reply to Michał "rysiek" Woźniak · 🇺🇦

> And then do a surprised picachu face when inevitably some surveillance capitalist robber baron enshittifies it to a point of complete unusefulness.

> It fascinates me how quickly people forget lessons from the whole Twitter kerfuffle, and just fall for another Silicon Valley silly con. Without even skipping a beat.

#BlueSky

🧵/6/end

This entry was edited (1 year ago)
in reply to Michał "rysiek" Woźniak · 🇺🇦

More in-depth dive obviously in the blogpost:
rys.io/en/167.html

Shout out to @tomasino, @mekkaokereke, and @dr2chase, whom I mention directly in that blogpost. And to everyone who offered their thoughts on ATproto in this thread:
mastodon.laurenweinstein.org/@…

If you want an even deeper (if a bit chaotic) dive, go read that thread. :blobcatread:

This entry was edited (1 year ago)
in reply to Michał "rysiek" Woźniak · 🇺🇦

so I made a mastodon account to post this, idk if you mentioned this, but bluesky is not federated.

I set up a bluesky "pds" and tested it in the bluesky app. you can't interact with any other pds, like bluesky.social. the jwt token (which you need) just doesn't work for viewing bluesky.social profiles or interacting.

here's me trying to load Henry Pickavet's did profile on bluesky from another instance

This entry was edited (1 year ago)
in reply to Elijah

oh this is super-interesting.

So you created a fresh new PDS and you cannot federate with the main bluesky.social PDS?

Huh, first of all, thank you for testing it out and reporting in! Secondly, can you go into a bit more detail why the JWT does not work for viewing bluesky.social profiles? :blobcateyes:

in reply to Michał "rysiek" Woźniak · 🇺🇦

yeah, so when you authenticate with pds, it uses jwt (you can see that here in this todo atproto.com/specs/atp#authenti…). you can't use that token to view another user's profile, which ig is fine but the profile doesn't replicate. there's just no way to get an actor (user) in bluesky.

mastodon has an endpoint, /api/v1/accounts/lookup, that gets an Account from a webfinger address (like @evalprime). that doesn't exist in bluesky from what I can see. that endpoint runs on the instance itself

This entry was edited (1 year ago)
in reply to Elijah

you can test my instance at bsky.elijahs.space and put that into the bluesky app as a custom domain or staging.bsky.app. if you try to access another profile from a user identifier like mirandahalpern.bsky.social it just doesn't work
in reply to Elijah

what it seems like is that because bsky.social is supposed to be private accessing actors from there is impossible, but accessing any pds' profiles needs a jwt token that is exclusive to that instance by default. so basically it's impossible to replicate an actor into your own pds' db anyway.

all of this is kind of fine but they claim it's federated when it's not.

in reply to Elijah

I patched my pds to not require a jwt token to view profiles but even with that, there's just no way for a pds to get another pds actor's info right now.

also interesting: the frontend will not even use the app.bsky.actor.getProfile endpoint unless you're logged in. meaning that staging.bsky.app/profile/elija… will still require you to log in/sign up

in reply to Elijah

tl;dr: bluesky pds (instances) cannot communicate with each other because there is no endpoint (url) for actors (users) from other pds to have their profiles displayed on another pds. even though the atproto is technically a standard, it's not federated
in reply to Elijah

going to shut down this pds as I just needed it for testing. if you want to set up your own, you're going to need a postgresql db and the repos at github.com/bluesky-social/atpr… and github.com/bluesky-social/did-…. you need to build and run the packages/pds folder in the atproto repo and the packages/server folder in the did-method-plc, copying example.dev.env to .env. then use an nginx reverse proxy to port 2583.