I've had a lot of people ask how BlueSky compares to Mastodon and the Fediverse.
-
replied to Mastodon Migration last edited by [email protected]
Even worse then, isn't it!
I've mainly put multiple relays on there so people can see even in the best case scenario, the AT protocol is still putting corporations in control of the network.
-
replied to Benjamin Sonntag-King last edited by
@benjamin @FediTips @janxdevil Facebook *never* federated, what they offered was client connection (which many people used pidgin for, which could have other accounts as well)
-
R [email protected] shared this topic
-
replied to mathieui last edited by
Interesting, hadn't heard that before. Did Google federate properly?
-
replied to effariwhy last edited by [email protected]
Most of BlueSky's board is blockchain people. Their CEO's CV is mostly blockchain and cryptocurrency companies.
-
replied to Fedi.Tips last edited by
There is one key question I haven’t yet seen answered anywhere:
“[…] our proposed methodology here of networking through Relays instead of server-to-server isn’t prescriptive. The protocol is actually explicitly designed to work both ways.”
https://docs.bsky.app/docs/advanced-guides/federation-architectureQUESTION: What would that look like? Would each PDS have to crawl all relevant PDSes (=very inefficient)?
Whether or not AT Protocol can be decentralized hinges on the answer.
-
replied to Axel Rauschmayer last edited by
As far as I know, in the real world AT protocol servers cannot federate without being connected to relays.
There is also only one relay at the moment.
-
-
replied to Em last edited by
That is 100% fine!
Very happy if this info spreads more widely. -
J [email protected] shared this topic
-
replied to Fedi.Tips last edited by
True! But (and I’m saying that as someone who thinks the Fediverse is the better choice):
It *sounds* like the protocol was designed to support true federation (vs. “big world” design based on Relays). What would that look like?
If that works well then, in principle, AT *could* become a reasonable and open alternative to ActivityPub.
If not (which is my current impression but I may be wrong) then there is no way of that ever happening.
-
replied to Fedi.Tips last edited by
@FediTips @effariwhy Do you have a link to the current status as a source?
I only know this article (in german) from November: "Bluesky: How is a ‘decentralised ecosystem’ financed? Bluesky was launched as a non-profit organisation, and controversial names emerged in the latest round of financing"
https://www.derstandard.de/story/3000000245588/bluesky-wie-finanziert-sich-ein-dezentrales-oekosystem -
replied to Fedi.Tips last edited by
@[email protected]
I still think Christine Lemmer-Webber's blog post on it is a worthwhile read for people a little more technical.
https://dustycloud.org/blog/how-decentralized-is-bluesky/ -
replied to James Endicott last edited by
@[email protected] @[email protected] I also think it’s important to specify something.
The Fediverse is designed to give ordinary people control of the network. All of its traffic flows directly from one cheap-to-run server to another.
This is only partially true. In bluesky the way it works is that you have to be connected to the relay. Posts must be "published" to the relay and while you can get a slice of the relay with an appview it still has to connect to the relay. This is something that is expensive to run and manage. Fedi works a bit differently because not every instance is talking to each other. If I follow someone on mastodon.social I am going to get their posts, not the entirety of mastodon.social’s traffic.
In fedi it’s impossible to have the same centralized relay because traffic exists between instances. We have relays but they do not operate the same as the bluesky relay. It is entirely optional to join a relay. Even if you do join a relay you are only going to see posts from other instances on the relay (ignoring the connections your instance establishes outside of the relay). There’s no real way for your instance to receive the entire network’s traffic which makes instances a lot cheaper to run and maintain. -
replied to Mastodon Migration last edited by
For more on who actually owns Bluesky:
Mastodon Migration (@[email protected])
So, to summarize what we've learned on the second day of trying to figure out: Who actually owns #Bluesky? The company represents that Jay Graber and the employees own Bluesky. This is misleading. In actuality, Bluesky has a host of tech VC shareholders (https://accessipos.com/bluesky-stock-ipo/) and is about to get more in a stunning funding round led by Bain Capital valuing the company at $700M (https://www.businessinsider.com/x-competitor-bluesky-valuation-new-funding-round-2025-1). So who are the current owners of Bluesky? Read on... https://accessipos.com/bluesky-stock-ipo/
Mastodon (mastodon.online)
-
replied to Amber (deilannist) last edited by [email protected]
Not strictly true.
ATProto allows relays to be optional—appviews could subscribe directly to PDSs.
But it reduces connections, which allows a relay in ATProto to run a fraction of the cost _per user_, even where the aggregate cost is higher (I think one estimate from a while back is that it is on the order of millions or tens of millions of BlueSky users for about the cost of Hachyderm).
AP is also, as implemented rather than as designed necessarily, _hellishly_ expensive per user compared to pretty much every major systems protocol.
-
replied to Fedi.Tips last edited by
@FediTips @janxdevil I am getting your point and of course, I promote Fediverse as much as I can.
But there are definitely reasons why users prefer BlueSky massively. I am not sure about their MAU, because they are centralized service, there is no way to verify independently, but they may be easily 10 times our MAU.
I think the need to choose the instance is not the main problem of Mastodon and Fediverse. It is quite easy to explain to newbies. The problem is quite simple and straighforward: it is UX focused on power users.
There are too many new concepts to learn. There is no reason, why end users should have to even know about federation: it is the implementation, that matters. Backfilling history of toots and timeline of other instances instead of "opening original page". Starter packs (ie. easy sharing of user-generated lists - no CSV imports). Propper scanning for all replies (somehow). Better search feature. Better explore feature...
Also, even if Mastodon may be the best ActivityPub client so far, it is definitely not for everyone. It is quite complex chunk of code. The frontend is written in JavaScript, which is of course very standard and it is my fault I am not more familliar with it. But Ruby is pretty oldschool server side language and not among the most popular. This makes the backend quite unreadable... although probably still better, than node.js
Anyway, it is not easy for me to participate in development of neither frontend nor backend of Mastodon.
Writing completely different Fediverse application would be probably hard and I definitely don't feel one should attempt it as one man show. The team would need to start with such ActivityPub implementation, which would fix the issues like replies, and then maybe work with W3C to standardize account list sharing, so other Fedi implementations can join.
Good cellphone app would be a must. It would have to come with good instance selector. Etc.
-
-
P [email protected] shared this topic
-
replied to Fedi.Tips last edited by
@FediTips I will stick to Mastodon, but even as technical minded user, it's way more frustrating to use. I can't even see half the content that is on other Mastodon instances, let alone comfortably interact with other protocols. It's confusing and badly communicated by the UI. Things need multiple times the clicks than on bsky.
I understand the limitations, and things are getting better. But realistically there is no way an average internet user can comfortably switch to Mastodon at this point.
