Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- The OP's article and replies in the comments here seem like someone who's comparing an idealised view of what Bluesky could be versus a cynical view of what Mastodon currently is. This troubles me because it overlooks the massive problems with Bluesky as it currently exists. It is hyper-centralised, much more so than Mastodon ever was. Virtually all users have their data stored by Bluesky PBC, aggregated by Bluesky PBC, access it through a website and app made by Bluesky PBC, and most crucially, are subject to the moderation decisions of Bluesky PBC at every turn. And I don't think it's a stretch to call Bluesky an “instance” here.
Now, sure, you can use a different instance for most of these services. And that instance can interoperate with Bluesky. But that's the case for Mastodon as well, and the real difference is the Fediverse has had to live with the painful compromises that come with the anarchy of the real world. I think Bluesky will discover its own version of defederation soon enough. I don't think “ah, but you technically theoretically can still interact with people even if you can't see them on your instance” is worth all that much.
- Google Reader feels like an ominous pick for an analogy. Sure, RSS survived the Google Reader shutdown, but not all the communities that used RSS (many that still don't know what RSS is) survived.
It feels almost "Freudian" to claim a thing is decentralized and then by analogy keep pointing to a massive (social) centralization of a decentralized ecosystem as a good thing. But especially one that we already know the ending for. Google Reader united a lot of RSS houses, value added a social graph and social commentary between them, and then at the whims of executives Google Reader fell and nearly killed RSS, but certainly destroyed an impressive social graph.
As an analogy that doesn't give me a lot of confidence in ATProto.
by WorldMaker - ATproto sacrifices true decentralization for consistency, Mastodon and AP does the opposite, sacrifices true consistency for more accessible decentralization.
At least that's how I understand it, because running an AP node is much more accessible to regular selfhosters than running one of those content relays in AT.
So all you'll ever "decentralize" in AT is your own data, it's more about owning your data rather than collectively owning a part of the network.
And we've been over this many times before on HN.
by INTPenis - I appreciate how this explains the difference between the two.
But I also found it a little frustrating, because it answered one part of the question but failed to answer the question so what does ATProto do to solve the problems that instances solve?
For example, when this article dismisses defederation as merely a mysterious reason you might not see posts from your friends, it fails to answer "so how does atproto solve the problems that defederation solves?". Because the default reasonable answer to assume, given this framing, is "it doesn't".
by JoshTriplett - If it quacks like a duck... An account has a single Personal Data Server (PDS), right? The DID links to a PDS which is the canonical data feed for a user, and where a user's writes go. Data can be replicated but the PDS is treated as canonical. That's much closer to client/server architecture than distributed architecture. There's no P2P database. There's no writes into a DHT or peers. You write to your PDS, then those writes are optionally mirrored. Also discovery happens via DNS, so you don't even ask peers for data. You connect to a relay not as a peer but as a client asking a server for a copy of data that's canonically hosted by the PDS. I don't think it's a stretch to call the PDS an instance and the relay a mirror.by 4lx87
- As far as I can tell, Relays[1] are the glue that makes ATProto work performantly. I think they're supposed to be content-agnostic — they just shuttle data through, reducing the number of services each AppView needs to be aware of.
As the blog mentions, the big improvement vs Mastodon is that Relays, AppViews and PDSes are separate services with their own distinct scaling demands. It's a rather beautiful solution to a system design problem.
by muglug - I think the analogy presented here is broken. RSS doesn't depend on Google Reader at all. Even at its prime, RSS depended less on Google Reader than email depends on Gmail now. In ATProto, AppViews heavily depends on Relays to be useful, and Relays are quite expensive to run. Also, the yellow circles which represent blogs in the RSS illustration are really not of the same nature as the same circles which represent posts on Facebook. Blogs are self-sufficient, for example.
I'm not saying ATProto is bad at all, but I feel like this blog post adds more confusion than it clarifies anything.
by p4bl0 - > Every single time a post about atproto hits Hacker News, somebody asks in the comments: “But where are all the Bluesky instances?”. The problem is, there are no instances in atproto! The question is a category error. Instances are a Mastodon-brained concept, and I wanted something I can link to that explains this clearly.
I feel like you've (perhaps purposefully?) misinterpreted "instances" just to plug ATProto specifically at the expense of ActivityPub (and RSS, a bit). I think you lower yourself by doing this:
1. it forces you to omit and contort the interesting technical truths about ATProto and Activitypub, like Relays and their pros/cons for ATProto and account migrations and pros/cons for ActivityPub
2. it creates unnecessary conflict and criticism and seems unnecessarily divisive for 2 platforms solving problems in such a similar space
It's also just seems a bit silly: why would you assume that when someone asks "where are the instances?" they're not using the common mainstream use of the word "instances", like, servers, or running software, or VMs, or containers?
Sorry if this is overly harsh or I've misunderstood, but it gives me a strong vibe that it was motivated by disdain and frustration towards ActivityPub and ActivityPub users rather than wanting to legitimately inform the world about ActivityPub.
I did enjoy the diagrams and the explainers though! I just felt like the subtle digs and pops at activitypub were an unnecessary distraction.
by 1dom