Bluesky and Wide Decentralization
Contrary to current perceptions, Bluesky can not be widely decentralized because full independence on AT Protocol simply costs too much. This is not something that can be fixed. It is based on the inherent architecture of the protocol.
All ATProto components rely on some very expensive network resources, accordingly there will never be very many, making these resources points of centralization.
1/
Bluesky and Wide Decentralization (cont.)
With Mastodon/ActivityPub independent service cost relates to the number of instance users, so small decentralized services are very low cost.
With Bluesky/ATProto some components can be distributed fairly well, like users storing their own data, but other components, like full scale relays, necessarily have a cost proportional to the number of users on the whole network, making small and medium size services expensive.
2/
Bluesky and Wide Decentralization (cont.)
This has big implications.
First, it makes creating an independent service very expensive. Every fully independent ATProto service must incur costs proportional to all 40 million Bluesky PBC users. This is something Blacksky wrestled with to create the first full scale independent ATProto service.
3/
Bluesky and Wide Decentralization (cont.)
Second, going forward, every independent service will continue to bear a portion of costs associated with the growth of the overall network.
Lets imagine five independent services, each of 40 million users. Each one would have a portion of cost proportional to all 200 million users. Plus, anyone that tried to start their own independent service, no matter how small, would have this same cost hurdle.
4/
Bluesky and Wide Decentralization (cont.)
This high entry cost means that, unlike Mastodon, Bluesky can never be a widely distributed network of small independent servers. Instead, ATProto facilitates a very few, big 'gods eye view' services with attached clusters of dependent components.
This means future decentralization of Bluesky, will always be dependent upon relatively large service providers.
5/
Bluesky and Wide Decentralization (cont.)
Why does it matter?
It matters because the entire rationale for wide decentralization is power sharing to protect the network from a single entity or a small number of bad actors using their control over the network to assert a political agenda.
Bluesky/AT protocol does not, and structurally can not, afford the same level of protection as widely decentralized networks.
6/
Bluesky and Wide Decentralization (cont.)
Notes:
1) 'Decentralization' here refers fully independent services.
2) 'Independent services' are services that do not rely on other network resources, and can access the entire network.
3) ATProto has many splendid features. The focus here is just on the decentralization of independent services.
4) Would love to be proven wrong. Please correct any misapprehensions.
7/
Bluesky and Wide Decentralization (cont.)
5) This thread addresses implications regarding linear vs. quadratic scaling. For more see https://dustycloud.org/blog/re-re-bluesky-decentralization/ (see section on quadratic scaling), and here https://mastodon.online/@mastodonmigration/116088076918635941
6) This is not a general critique 'hating on Bluesky'. The motive is to call attention to a technical characteristic of ATProto that may be at odds with how the network is commonly understood.
8/fin
Want to thank Kuba Suder @mackuba for his constructive contributions to this thread below.
Kuba has written the definitive 'explainer' (see linked post) on AT Protocol for those of us who are not software engineers, but strive to have some general understanding of the protocol.
I've written a very long blog post about #Bluesky 🙂 It's my "user's guide" that talks about what Bluesky is, what's good to know when you're just starting, the apps & tools that you may want to try, and what about the things that aren't ready yet: https://mackuba.eu/2024/02/21/bluesky-guide/ (This is rather user-focused with not much technical details, I will also write something from a developer's perspective later)
Want to thank Rob Ricci @ricci, Research Professor in the Kahlert School of Computing at the University of Utah, for his constructive contributions to this thread.
Rob is the author of Are We Decentralized Yet (https://arewedecentralizedyet.online/), a great website that tracks network decentralization based on real time statistical analysis.
It's all about tradeoffs in the end
Each project might fit better with AP or AT, it depends on their goals and needs, or even personal preferences, and it's fine
@vicwalker @mastodonmigration @mackuba
My way of describing what one's good for vs. the other would be: if the application benefits from being able to get a complete view of the network, both in terms of seeing all particpants and the ability to see anything that has happened in the past, atproto is a very good choice. If your application can work with a possibly incomplete set of events that may not get delivered, then AP is a better choice.
It's easy to see from that why it's easier to develop for atproto (cue sweaty Steve Balmer jumping around on stage screaming "developers developers developers"). But it comes at the cost of there being parts that you just can't practically decentralize.
ATProto apps don't always NEED to replicate the whole network of +40 million users, they can just worry about indexing the users once they log in for the first time, and it reduces the app server (appview) costs a lot
It can be expensive to keep up a full Bluesky microblog clone as Bluesky PBC maintains it, but we already had some experimental microblog clients using different approaches
As Kuba said in his replies, Blacksky is aiming to be a full microblog alternative (with even extra features for their members, like posts that can be only seen inside the Blacksky app)
Eurosky and Northsky will probably follow the same path, but will take some time
Appreciate the information...
"...the client could just index accounts the current user is following, interacting with, or loading in feeds, and save costs (some people called it appview lite if I remember correctly)"
Would be very interesting to learn more about this 'appview lite', and if anyone has had any success with it.
I might be mixing some names, it's been some time since I saw that
But AppViewLite is a real thing https://github.com/alnkesq/AppViewLite
Some time ago, there was a client named Zeppelin that was the first experiment using nothing from Bluesky's API, if I remember correctly, it used AppViewLite
https://github.com/zeppelin-social
It was more to experiment and show that it was possible, not to be up forever, and it was way before Blacksky started developing their own AppView implementation
YES! This one! I had forgotten the name, since it was around a time before I created a better organization of notes and links related to atproto.
@mastodonmigration @vicwalker This issue with these is that in atproto, one writes things such as mentions, replies, likes, etc. to their *own* repo, not the repo of the account they are interacting with. This has some upsides, for sure. But the biggest downside is that if your app/appview, etc. does not already know about the repo/PDS that is trying to interact with you, it has no way of finding out about it: they write a record saying that they replied to your post, but you will never find out.
AP has discovery for these kinds of things: when someone replies to your post or @s you, the server/instance you are on gets notified. This of course has plenty of downsides, but it means that a partial network view is *far* more useful on AP than on atproto.
From the Eurosky link. "monetisation" + "revenue services" 🤔
I feel like those are probably inspired by other projects and people from the dev community there, since a lot of atproto devs are talking, exchanging ideas and working together all the time
Fair points. The UX can definitely be improved to make those decisions as the network grows more diverse, with more options to pick.
There are multiple Bluesky clients that allow you to set different services for each thing (AppView, CDN, Moderation, and so on), but that's something that's used mostly just by protocol-nerds or devs.
The only thing I want to add a counterpoint: "Now I'm stuck."
Moving PDS is even easier than migrating inside the Fediverse, and usually takes less than 10 minutes, keeping all your data and identity. And there are A LOT of options to choose from now (I have a list of just a few that are more open to join https://blog.vicwalker.dev.br/3lz4g6zxeic2p ).
"I still have to rely on external relays and AppViews", indeed, but there are multiple options of relays already up ( https://compare.hose.cam/ ), and it's pretty cheap to run one yourself ( https://whtwnd.com/bnewbold.net/3lo7a2a4qxg2l ), and you can just…. don't use an AppView at all (as https://reddwarf.app/ does, the client fetches data directly from PDSes).
what do people want from social media?
afaict it's either entertainment or news (maybe culture is somewhere in between). if it's the former, I don't get why decentralization matters at all. if Elon's algo isn't fun for you, go to Threads or Bluesky etc. but if it's the latter, a few big app views getting to decide what gets seen is bad for civics/democracy.
[sharing with friends, family and interest groups is vital but separate imo. I call it social networking]
Only sort of. For example, leaflet is (so far as I can tell, I've used it a bit but haven't looked at the code) quotes, reposts, etc. that happen on Bluesky that are not done by "its" users. This is extremely cool, but only possible if you can contact an omnicient service that can tell you about all activity anywhere on the network.
@mackuba @mastodonmigration I went ahead and looked at the code, and it uses the bsky appview quite a lot
Could it be designed a different way? I'm not sure.
For what it's worth, I looked at the tangled code, and it does *not* significantly use the bluesky appview as far as I can tell. Neat.
On the other hand, I'm not aware of any significant interaction it has with bluesky and other atproto apps - eg. to the best of my knowledge you can use your bluesky *account* and *repo/PDS* but tangled is completely unaware of any reposts, comments, etc. happening on Bluesky. Would you need an appview to do that? I think so, but I'm not confident.
And this actually points out a really interesting case where the current atproto puts a lot of weight on the relay/jetstream, but *could* with relatively small changes, remove some of that dependency.
One reason for tangled to use jetstream is that it lets you filter by DID and NSID/lexicon. That means that tangled can consume only a small amount of data, getting just the users and record types it cares about. Unless I'm missing something, you can't do either of these things directly at the PDS: you can sync individual repos, but this doesn't get you real-time updates (and it gets you records you don't care about, but that's probably OK). If you want real time updates, you have to drink the PDS's entire firehose, all users and NSIDs. So, there is this thing going on where there is indeed a nice API that small apps can use, but they kind of *have* to use it, and centralized services, even - no, especially - if they want a fairly small amount of data on a small number of users.
But: adding these to the PDS would probably be quite straightforward, if atproto wanted to make it easier to avoid centralized services.
@ricci @mastodonmigration There's definitely the temptation to use the Bluesky AppView for a lot of things for convenience, even if technically you could do it without it 🙃
I think the most obvious place to use it in Leaflet is the somewhat recently added full thread view on mentions, for that it's definitely useful to have someone index the whole thread for you.
@ricci @mastodonmigration Without full threads, if you wanted to just show mentioning posts as it was before, there's really no need for an AppView there, you just listen to the relay/jetstream for Bluesky post records matching a given pattern and you save them locally.
For the full threads you could also avoid it if you wanted, just after recording the root post look for any posts with the given at-uri referenced as root and save them too, you just need more tables/columns to store that.
FWIW: blacksky's appview is in production, and has some cool features that the bluesky one lacks, such as local (to the appview) only posts.
To @joborg 's post, the point is that it actually does not scale with the number of users, and this is the problem @mastodonmigration is bringing up with their thread. If you are a small service in atproto, you currently have three choices:
(1) Don't see most of the network: this is cheap (O(your users)), but it means no one on a PDS you are not already following cannot interact with you - or rather, they can try, but you will never know. This is far, far less useful than the partial network view that the fediverse and Mastodon give you, where attempts to interact *do* result in discovery messages to the account's instance.
(2) Run a full-network relay and/or app view. Depending on what exactly you need, this can be quite expensive, and it is O(total network users), not O(your users). See the numbers @vetehinen quotes. (FWIW, I saw that post by Rudy, but have since been unable to re-find it. I'm not sure whether it's been deleted or I just can't find it)
(3) Use a relay and/or appview that is run by someone else. Because running these are resource-intensive, because they need to see the whole network, there are not many and they trend towards centralization
Most projects go with #3.
Wafrn proves most of this wrong.
https://wafrn.net
Feel free to elaborate.
Got it. Thanks for the clarification. Wafrn is cool, but it doesn't sound like it provides an independent AT Protocol service. If, as you say, it uses Bluesky's relay, it is dependent upon Bluesky. Unlike Blacksky who has has created an independent full-scale relay at great cost.
The point is not that it is impossible, but rather that the high cost of these components limits the ability of the network to scale wide, meaning lots of lower cost independent services.
Well, again, it still isn't centralized to Bluesky itself - in that if all the Bluesky servers disappear tomorrow, your Wafrn info is all still there, including the record of the Bluesky posts that previously got fed to your instance. But it does give one the ability to follow, reply and post onto Bluesky - via ATprotocol. So, yeah, the relay servers for Bluesky are centralized and represent a potential single point of failure, but even if that fails, if one is on Wafrn you can happily continue on ones way, just using the ActivityPub side.
@[email protected] @mastodonmigration
WAFRN as a software has the capacity to use other relays. I believe this server uses Blacksky's relay if I'm not mistaken, not Bluesky's.
Not to be like 'my Fedi is better than your Fedi' but sberson is pretty might right on. From my understanding (which is to say, listening to the incredible people who make this shit go and reading all the times they've explained it) we only store profiles and posts that we need, things that have been called upon by the users.
Thanks for the clarification. If indeed WAFRN uses Blacksky's relay that is great, but this doesn't change the overall point of the thread. In fact, it underscores it.
Since these independent full scale system resources, like Blacksky's full scale relay, are complex and expensive, AT Proto networks will be organized as clusters of dependent components around a small number of providers of them.
@[email protected] @[email protected] @mastodonmigration
making a realay is super simple. seriously. you can do it on a cheap vps. The "amnesic relay" is the idea.
you dont need to store the whole network history.
bsky is decentralised. the relay is just one piece and its simple. the appview is another piece and yet again, super simple (we do it red dwarf style wich means our backend calls directly to the pds).
We use jetstream.fire.hose.cam as a jetstream by default, but operators can change it to another one if they desire
let me be clear
bluesky is a lot more decentralised than what matrix is at a protocol level.
and if decentralisation is what you're up for, nostr is the most decentralized protocol. But the people ive seen try it have always made these 3 posts with a few hours of each other:
ATProto is just another protocol and asks the question "what if you dont do all things". The answer? something interesting, with some things a lot better than fedi (account migration, reply control [that one im working on fedi stuff for it]) and some other things a lot worse than fedi (followers only posts as example)
I want to clear up a few things in this thread; caveat that I am not an expert in the wafrn code and I may have some of this wrong
(1) wafrn is cool for sure
(2) afaict, wafrn only includes a jetstream subscriber, not a relay subscriber, meaning that it cannot be using blacksy's relay - it does not, afaict, provide a jetstream
(3) wafrn uses both the jetstream and appview provided by bluesky on the atproto side. I don't *think* it can be configured to do atproto without these, but I could be wrong [edit: the developer says that the dependence on jetstream is correct, but the appview is optional and rarely used,, not required]
So, unless I am misunderstanding something here (possible!) wafrn avoids the problem of having to do O(total atproto network size) work itself by offloading all of that work to services provided by Bluesky PBC. The existence of wafrn does not contradict @mastodonmigration 's point that the atproto network heavily relies on a relatively small number of services.
@ricci @[email protected] @mastodonmigration @[email protected]
2: we dont need a relay, jetstream does the same but with less bandwidth. We do not need to provide that!
3 is wrong. We do ask directly to the pds not to the bsky appview anymore.
Just in case, as optional thing we do ask in some ocasions for feeds for the list of posts the user see as a fallback for possible bugs on our side
Now a thing: petitions done to pds are GET petitions with no signatures. They are extremely fast. Unlike petitions made to fedi posts, with require checking signatures and verification of JSNON-LD wich is EXTREMELY cpu intensive (and requires multiple http petitions too to properly check it! Also a bad actor like Nicolas cage could create an intentionally maformed jsonld payload but thats another thing)
Fedi O scales per user. Not by instances but per users and c
Also: bsky O scales depending on number of appviews. Fedi O scales per user. And even tho bsky has a bigger number of users than fedi, bsky is more efficient. If you make 100000 wafrns, it will still be more efficient than fedi (I don’t rememberz if wafrn knew of 10k or 100k fedi instannces)
@[email protected] @mastodonmigration @ricci @[email protected]
Atproto asks the question “what if you dont do everything”
The answer: some things are extremely better (account portability as example). Others things are worse (no followers only posts, dms are off protocol)
Its different and knowing how activitypub works doesn’t helps you to understand how atproto works!
Knowing driving trains (fedi. Fedi loves trains) doesn’t help you drive huge boats
@gabboman @ricci @wolfwalks @sberson
Thanks for commenting, and apologies for not understanding this level of technical detail, but are you saying that WAFRN does not use any external AT Proto system components? That it is, like Blacksky, 100% independent?
This article defines such independence as 'Unit B.'
"...PDS, relay, AppView, and moderation independently. This is Unit B, fully realized."
https://plurality.leaflet.pub/3mfergx7i7c2b
Is WAFRN Unit B?
@mastodonmigration @gabboman @wolfwalks @sberson
Jetstream is a component provided by full-network relays: it is not currently possible to run one in practice without listening to the entire network.
Using Jetstream is still *using* a O(entire network) service. It may not be *warfn* runinng that service, but *someone* has to, which is the point of the original thread.
Untag me from this thread, thanks!
Mastodon Migration
Kuba Suder • @mackuba.eu on 🦋
Victoria
Rob Ricci
jon_bon
Baral'heia Stormdancer ΘΔ🐲
william.maggos
Joborg
Vesipeto Vetehinen
sberson
wolfwalks
gabboman the wafrn dev