Hacker News

I'm being a bit cheeky in the article's tone but I am fairly confident from discussions in the past that "But where are Bluesky instances?" is a common question which usually demonstrates a misunderstanding of the architecture where "having instances of an app" is seen as a measure of decentralization.

My article was an attempt to dig at this specific misunderstanding by comparing it to "But where are Google Reader instances?" which I think illustrates its absurdity. I genuinely do think that the two pictures I provide close to the end clear this up in a way a lot of early atproto/ActivityPub discussions completely gloss over.

Re: Relays, I wrote here on why I didn't include them: https://news.ycombinator.com/item?id=48600963. They're kind of incidental perf optimizations rather than essential to the model. In the post, I wanted to focus on the model.

> 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?

Of course depends on the context, but in a lot of discussions about ATProto, ActivityPub, Mastodon and nearby areas, people talk about "instances" as in "ActivityPub instances that host my data and my profile uses its URL as a 'name'". The blog post is specifically for that context I think.

It's less about trying to hide around the issue, and more reframing how you see the concepts, as people start to associate words with concepts and structures. So when people talk about "decentralized social media", lots of people think about ActivityPub, which typically (always?) has a kind of federated architecture, and the instance is one of those nodes in the network. When these people see ATProto, instinctively (and perhaps rightly so) they literally ask "But why is there only one Bluesky instance that people join?" as those concepts map close to what they know.

Overall I think the post is a good and useful addition to the discourse, with perhaps not a completely novel perspective, but posted publicly for future reference when this inevitably gets asks again sometime in the future, specifically for the people who have these previous associations already formed in their head.

Perhaps ATProto vs. ActivityPub will been seen as the Fediverse's East-West Schism.

Instead of decrees over the "filioque" we get blog posts about the definition of "federation" where both parties talk past each other.

I found the distinction and comparison about Mastodon and ATProto are necessary. The fediverse model is easier to understand given existing social networks. ATProto is a novel concept that give users data sovereign and also the scalability of the centralized social networks.

Relays are actually quite cheap now! They used to be a bit more expensive when they archived all the traffic, but in sync 1.1 that was dropped and they can be run on $20/mo VMs pretty trivially now

People have set up relays for like $15/month.

> Relays are quite expensive to run

While relays are among the more intensive parts of AT Protocol infrastructure, their cost of operation is still something most people can afford: approximately $30/mo now. What is truly expensive and difficult is something that will be immutably so regardless of how centralized or decentralized you are: moderation.

The author of this piece wrote about this common misconception about relays 9 months ago: https://news.ycombinator.com/item?id=45077291#45078223

Yeah, Relays are one way to do that. I've mostly skipped them because they're an invisible optimization and there are other strategies. E.g. many smaller apps today rely on Constellation (https://constellation.microcosm.blue/) instead of building their own database index, so they don't use a Relay at all.

They do remove content directly from relays. They claim they only remove content that is illegal to host, but I don't know how true that is, and there is always the risk it could change in the future.

https://docs.bsky.app/blog/blueskys-moderation-architecture#...

If you’re asking about moderation, it works similarly as you’d expect it to work in a everything-RSS world.

At the hosting level, the hosting you use will likely ban you for clearly illegal stuff. Same as blogspot dot com or Cloudflare could ban you for certain things.

At the application level, application admins/mods would moderate as any app does. This is similar to running any web service today with user generated content. It’s up to app developers to choose. Apps can also provide primitives for userland moderation, like Reddit does, or even ability to plug your own extra moderation services (which Bluesky allows). But again, this is largely how it works on any app with user-generated content.

There’s no “defederation” because there’s no analog of “community instances” that may fight with each other. There’s hosting, there’s apps, and there’s app-level moderation that works according to each app’s developer’s choices.

Does this help clarify it?

It doesn't solve those problems, except in an alternative universe where there are a very large number of appviews capable of consuming the entire firehose and you can freely choose between them and cheaply run your own. ATProto is like RSS in a universe where you can only read RSS through Google Reader (or a clone of Google Reader running on the same scale).

> it fails to answer "so how does atproto solve the problems that defederation solves?".

The better way to ask this is, how does ActivityPub solve the problems that defederation causes? It's essentially the thing Microsoft does with email. Discard messages from all but the largest providers, defederate by default, forcing users to use Microsoft or another major incumbent if they want their messages to be delivered. Then new instances can't have their messages delivered, therefore can't get users. Which is obviously a perverse incentive for the major incumbents to not federate with new instances.

It's an architectural choice that has the long-term effect of cementing an oligopoly.

Meanwhile the claim is that it's necessary to prevent spam, but there are other providers that don't do this, e.g. in general you can deliver to Gmail as long as you have DKIM and reverse DNS etc. configured correctly, and those providers don't have any more of a spam problem than the ones who block innocent small servers by default.

Moreover, there is an obvious way to do this without giving the major instances a perverse incentive. You do the filtering on the client so that the filter list(s) you use are provided by something in the nature of uBlock rather than something in the nature of Microsoft, since the former doesn't operate any instances and therefore isn't trying to pressure everyone to use theirs.

Yeah sure that’s a fine way to phrase it. It’s not what most people who talk about Mastodon mean by “instance”. In Mastodon, “instance” is a coupled and inseparable data hosting + app + community + moderation pairing.

Frontends and relays are far closer to “quacking like an instance.” That’s where your sysop’s power lives. The PDS itself isn’t very powerful - can’t meaningfully limit who you can talk to, for example.

This is an interesting take because AtProto feels both more accessible AND more decentralized to me (at least with my current mental model).

With ActivityPub, because running an instance requires hosting the data, the application, and dealing with all the subsequent scaling challenges, you kinda have to choose between being taking on active ops responsibilities or tying yourself to someone else's instance (which will probably be one of the bigger, more centralized ones).

If you decide you don't like an instance you picked and decide to move (unless things have changed) you're kinda stuck needing to start fresh.

With AtProto, it's trivial to jump ship to a different application platform and continue using your same identity. Exporting your data from a platform and self-hosting is a bit of a UX challenge, but at least it's possible.

As an example, I recently started using Tangled for the first time and was able to login using my existing bsky-backed domain (h14h.com). No need to create a new account or pick a new username -- it was as if I were already there. Then getting set up w/ self-hosting my git repos on a VPS was an afternoon of work at most, and it's just some backend service chugging away that I almost never have to think about.

The worst that will ever happen is I see a banner message in tangled.org saying something like "your repo is out of date and may be compatible with the latest version of Tangled", which I can solve by simply rebuilding & redeploying a docker image w/ the latest versions.

Granted, AtProto is definitely harder to wrap your head around architecturally. But actually interfacing it with a user is much simpler, IMO.

I'm not sure there is such a thing as "true" decentralization :) In my mind it's more of a buffet of tradeoffs rather than a single sliding scale.

FWIW, in the AP world there are several individuals and small teams running relays/mirrors/caches/AppViews and so on -- but you're right that this could get more expensive as things grow.

I think that’s a part of it but doesn’t state it fully.

AT doesn’t just give consistency, but a shared data model across apps. So apps can reference and render content from other apps. It’s really kind of like a web of typed JSON. Different apps are lenses through which you can see the same network. Anyone can build new experiences on top of old data. There’s nothing remotely equivalent in AP.

AP couples data to apps. In AT, it’s more like there’s one global database with entire world’s data that every app can query.

I don’t understand why the discussion always bumps into Relays. Running a Relay if you want to is cheap-ish ($30/mo) these days. There’s multiple existing ones (Bluesky or community) you can use for free. And many apps don’t use one at all and rely on community indexes like Constellation (https://constellation.microcosm.blue/). Some don’t even run their own server or database.

Mastodon also has content relays!

But really, I actually would argue the opposite: ATproto is (or at least, wants to be) more decentralized.

In the ActivityPub world, identity, application, and hosting are intrinsically linked. If I want to use Lemmy, I can either register a second, permanently separate ActivityPub account on that Lemmy instance, or ONLY use Lemmy to the extent my Mastodon instance knows how to send messages that Lemmy understands. EVERY new ActivityPub app is a new set of interoperability concerns, because each app owns its own identity and hosting. There's no way for my self-hosted Mastodon instance to provide an identity to a Lemmy server and then for that Lemmy server to tell that instance to host content on my behalf.

That's the bare minimum you'd need to match ATProto, at least in the version being told to me by the ATProto people. No idea if any of it applies to actually-existing ATProto, in the same way that actually-existing ActivityPub can't interop the way ActivityPub supporters claim it can.

The "problem" is that people are looking for problems. This "problem" isn't specific to Bluesky, ATProto, or anything else. Look at any organization: profit, non-profit, group of volunteers, etc. and you'll always find someone that folks have a problem with.

I'm not an investor and have no conflict of interest with Bluesky beyond being one of the earliest of users. I also understand the protocol, the company, the website within my own limitations.

The site (and app) works just fine. Folks are really focused on finding problems rather than coming up with bigger and better solutions.

Note: the majority of folks don't want an ad-hoc p2p solution like lemmy or mastodon. they want their content in one place, and they want to be able to hold that entity accountable. Because of this, p2p social networking will never take off. I've seen more drama surrounding both Lemmy and Mastodon than I have ever seen with twitter, reddit, facebook, etc. combined.

That's my 2 cents. Also, apparently my spouse feels the same way. So do my friends.

There are other apps, other user data hosting (including personal hosting), and other backend services.

It is decentralised in both theory and practice.

The only thing you could potentially say is that because Blue sky run the biggest parts, it's not decentralised at the community or mind share level, but that's changing.

Does really do a great job? It just says there are no “instances”, it doesn’t explain how the architecture circumvents all the troubles that it leads to such as auth, sync, discovery, etc.

Well, the whole point of atproto is that the social graph also lives in the “blogs/RSS” part. The apps just index it.

So in this analogy, anyone would be able to bring Google Reader back to life or compete while using that same graph.

That’s actually how http://leaflet.pub works now if you’re curious.

Ominous, but accurate. Imagine RSS but you couldn't use a desktop or mobile RSS reader, but only Google Reader or a comparably scaled clone.

In exchange we have many excellent RSS Reader. Just as recently someone talked about NetNewsWire.

> So, anyone who wants to index it gets a copy and you have no control over what they do.

How does this differ from scrapers hitting the blog directly?

Honestly that’s just as much because atproto is a raw data protocol. Putting an http frontend on an atproto account is something we encourage and a lot of folks do. I do that on pfrazee.com for instance, and my leaflet blogposts (which are canonically on atproto) render on my blog.

So every user would have to individually block all the nazi and child porn instances?

The same reason that they don't do that for Email. It's a lot more complicated for little obvious gain

I don’t know what you mean by “instances” here. Leaflet (https://leaflet.pub) is one of those “blogger on atproto” things — is that what you mean?

That’s the whole point of “apps”. Apps are opinionated points of view / prisms over the network. Of course they’re able to apply their own moderation decisions. That’s how the whole mainstream web works in general — you can’t even get an unmoderated app into App Stores.

The difference is that it’s competitive. New apps can rise up that provide alternative lenses over the network. In the crudest case, literally showing everything. Which is what you wanted. Maybe that won’t get into an App Store but it definitely works if there’s demand for that.

That’s not really true. For one, you can have different AppViews which don’t do that. The feeds can be algorithmic however you the user want — multiple apps means you aren’t tied to what one central creator desires for those algorithms.

- There's no "instances" so I don't know what you mean by this.

- Re: PLC directory, indeed, there is only one of those. I think this is a legit point but it's worth considering the whole point of PLC directory is to be the single minimal stateless open source part that lifts identities out of apps and hostings. PLC governance and maintenance is being spun out into a Swiss organization (https://atproto.com/blog/plc-directory-org). Longer term the idea is for it to have a similar role to ICANN. Here's more on that: https://youtu.be/9z0z-Qu66yM?si=_8Dcw1M3VSKFGZhm&t=493

- Re: full Relays, they're easy/cheap to run, and you can run one yourself if you think the other ones are coordinating with Bluesky and don't trust their decisions. You don't need to depend on something else to do that.

There are many relays, here's a list of 13 but it's not comprehensive: https://tangled.org/firehose.club/community-firehose-list/bl...

Bluesky's moderation actions are generally implemented as moderation labels which take effect at the AppView level. Sometimes they'll take down someone's PDS or censor from their relays, but I don't believe third-party relays are aware of those relay takedowns at all.

Most decentralized systems I can think of tend to follow a power law distribution (roughly) where one or a few platforms dominate. In the fediverse that's mastodon.social (or maybe Threads), in email that's Gmail, in AP that's Bluesky. I'm not sure this is unique to the AT protocol?

re: censorship & moderation, the folks @ BlackSky have been active in building out an alternative moderation structure (alongside running PDSes & AppViews).

Author here!

I mostly skipped over it because a Relay is an optimization and not essential to the shape of the network. It's not a fundamental element in the same way that PDS (hosting) and AppViews (app servers) are. It's more like a "next reasonable thing" an engineer would bolt on to make it easy to create apps.

An app can work without a Relay (like https://reddwarf.app/ does). There are caches like Constellation (https://constellation.microcosm.blue/) that you can just query directly.

A Relay is not an "instance" in any meaningful sense because it is a dumb retransmitter. It is cheap to run one, and it is easy to pool them between multiple apps. (Fun fact for nerds: the Relay's API for subscriptions is literally the same as a single server's. So a Relay is kind of a facade for "a bunch of servers" that lets you listen to their events combined.)

Early on (more than a year ago), running a Relay used to be more expensive because any Relay was expected to store the entire network archive. This is no longer a part of the contract, but a lot of discussions still reference or assume that. The current cost of running your own Relay (if you don't want to pool with anyone) is about $30/month. There are community-run Relays like https://firehose.network/ that you can use too.

> Maybe because doing that would show that there are in fact "instances" in atproto, but who knows?

I wonder why you are vagueposting here instead of stating your position firmly. Maybe because you are afraid to be shown wrong, but who knows ?

I just searched up Relay and I guess Relay is like Feeder in the analogy? I don't need it? And if I want it I choose one (many?) or run my own.

Mostly because having a big centralized firehose relay is less decentralized than people want to admit.

The cost of ATProto is only high if your AppView has a goal of "every user should be able to see and access every post and interaction indefinitely". If one limits the scope of what users see on their AppView to, say, a similar scope as what popular ActivityPub applications do (only posts and interactions from users that use that instance, and people that they interact with / follow are available / retained), it becomes not that expensive at all.

The difference is that it's easy to scale ATProto AppViews up beyond the reach of their users. It can scale down though. It is not easy to scale ActivityPub instances up beyond the scope of the people who use it, and it would probably be way more expensive if you tried.

I wouldn't say other components are expensive. Common ones are:

- Relay as an optimization. That's cheap-ish ($30/mo) or free-ish if you pool with others.

- Your own app server. That's on par with normal web apps as long as you can keep a socket open. What's expensive is if the app you're making is a fully capable copy of Bluesky itself with gigabytes of existing posts — but is that the app you're making? The economics here are identical to normal web app stuff.

Yea that's fair. My stubborn point is that Fedi is trying to do the right thing using the wrong technology, and the resulting tradeoffs in user experience are why it will always remain niche. I hope that more resources will eventually flow from Fedi-centered solutions to more independent stuff in the atproto ecosystem.

That goes to the heart of the issue. Bluesky's dependence on VC money and for-profit structure means it has a conflict of interest with long-term survival and independence of the protocol. But that might be fixable.

The mitigation is of course more companies and open source projects getting involved. As far as I understand it, the protocol is pretty well designed, and there is a bunch of open source out there already. It just needs more people to get involved.

But the article pointing out that you can migrate your Bluesky account to a thing called Eurosky was actually news to me. As is the existence of non Bluesky owned applications on top of atproto. I might give those a try actually. It seems a lot has happened since I last looked at this stuff a few years ago.

That still leaves governance of the protocol as a problem. That would ideally need to be untangled from Bluesky as well. But that seems doable as well. The more independent atproto software projects are out there, the harder it is for Bluesky to make breaking changes. That naturally pushes for some independent governance. I wouldn't be surprised to see that happen over time. But worst case, there could be some kind of fork/split of the network.

It would be interesting to see some attempt to bridge with other networks. A mastodon / bsky hybrid. Why make people choose? Despite X's demise, it's still X versus everything else. There's also Meta's Threads and a few others. The whole "not X" space fragments users over multiple networks that sort of could federate if they would but they really aren't. I think Threads is nominally mastodon compatible at least but actually federating is a bit frowned upon by Mastodon users.

And while we are "at" it, why not support email as well? Which is the og. federated communication network with essentially all internet users as active users. It's not perfect, but nothing better ever managed to replace it.

Separating identity from protocol is a good design choice. Cross protocol federation is a logical next step. It's all about receiving content from people, not about staying in walled gardens that belong to share holders.

Never rely a service just because they _hope_ to one day be less decentralised.

It doesn’t fully resolve your concerns, but I do want to highlight that atproto now has an IETF working group to home its spec development

"Seems to have worked OK for email"

THANK YOU. It seems like far too few in this space really understand the benefits of actual decentralization.

ATProto feels like "centralized, except also we get other people to do the hard work with few of the benefits."

Sure, there are servers, but the different grouping is the whole point because they're not coupling hosting to apps. When people say "where are Bluesky instances", they're asserting that it's useful to run many copies of the Bluesky database server. My article is an attempt to show that this way of thinking is very Mastodon-brained because these "instances" are the only unit of decentralization that's available in Mastodon. But you don't have to think this way.

In atproto, you can swap hosting (without changing apps), and you can create and use different apps (without changing hosting). That's the thing you can't do in Mastodon because it hard-couples hosting + apps into monolithic "instances".

In Mastodon, "receiver" and "sender" talk to each other, as you say. In atproto, hosting servers never talk to one another. The data from them flows into apps.

You're right that there's often a firehose in the middle, but that's also misleading. There doesn't have to be one firehose — there's a bunch of community-ran ones. It's relatively cheap to run one yourself these days (about $30/mo). It's easy to pool them between apps. And many apps don't use Firehose at all, and instead query community indexes like Constellation (https://constellation.microcosm.blue/). So "one firehose" is misleading.

There are multiple Bluesky AppViews, Blacksky has a totally independent one. And there are multiple relays, each capable of serving a firehose.

You can have your own AppView and Firehose. They're just relatively expensive to run versus a PDS.

I have a different article that goes into this here: https://overreacted.io/open-social/#open-social

Also here: https://overreacted.io/a-social-filesystem/#links

TLDR: at the hosting layer, it's like <a href> links, but in JSON. Links can refer to other person's repo (even if it's hosted somewhere else). And then apps index everything, so they can present a coherent aggregated view (like a post thread).

Here's a list of active alternative hosts: https://blue.mackuba.eu/directory/pdses

As I mentioned in the article, I literally migrated to https://eurosky.tech/accounts/ yesterday.

What kind of censor?

Whoever operates hosting can decide to ban someone from hosting. This isn't different from how Cloudflare would ban you for hosting something illegal.

Whoever operates an app can decided to ban someone from that app. This isn't different from how a forum moderator can ban you for something they don't like.

Whoever operates services in the middle may decide to ban someone for network spam/abuse, same as cloud services may do if you abuse their limits.

You can always try to host your stuff elsewhere, and you can always access the same network from another app whose decisions you prefer.

So it's basically same as usual on the internet, but each role is separate, and you can mix and match what works for you.

> So all the censor needs to do is cut off one host? And then you upload everything to different host and connect that?

Which host?

I don't know what your first sentence says at all. This doesn't seem related to atproto.

I mean, this literally already happened (a person was banned, and Blacksky reversed that ban on their app server). So their account only works when seen thorough the Blacksky app. What is a better solution you’d like to see? I think it’s reasonable that there’s a market between these and if there’s enough demand, another app server can become popular. I don’t think it’s reasonable to expect that the apps shouldn’t be in control of their own moderation.

I'd say atproto gives you a clear sense of what's tied to each of your identities — you can go and explore your repo in a browser. There's nothing to say your identity has to be "tied to a person" anymore than your Mastodon account on some server is "tied to a person". It's true atproto has a "scraping is the default, so expect it" vibe, whereas maybe you're arguing Mastodon allows security by obscurity?

I don't think I agree. There's nothing intrinsic about the PLC and PDS servers that tie an AT account tighter to your own identity, than an account on an ActivityPub instance in my opinion.

Correct me if I'm wrong, but I'm guessing by plausible deniability you mean that ActivityPub essentially forces you to shred your old account if you need to move instances? Apart from the fact that AT also doesn't impose a "one DID per human identity rule" (yet?), allowing you to move between AT identities and PDS instances as much as you like, there's no hindrance to anyone that really wants to track your account movement between AP accounts of they even slightly want to do so. By default ActivityPub leaves a little entry on your old account saying "the person behind this account move to instance so-and-so", which is what allows you to migrate your followers with you in the first place, but that leaves just as much of a trail than your DID moving from PDS to PDS, and if you want that message to not be there, giving you said plausible deniability, you're just back to creating fresh accounts every time, just like AT.

I mean I think it's hard to say that one platform is better than the other in that regard because the platforms are really really similar to each other from a broad perspective. If you take ActivityPub, break up the concept of an instance into one part that keeps the data and one part that shows the data, scrap the usernames in favor of random IDs, and stick a few more services in between, you've already arrived at the AT protocol, the oversimplification aside.

Nothing is stopping you from making more identities, though?

To be fair, from 2022. I would argue that moderation in Fedi is holding together reasonably well. There are a few popular instances that lots of people think are overly aggressive/purist in their moderation policies, but the people using them seem to like what they're getting.

We could develop an all in one stack that handle relay, AppView and iOS / Andriod / Web apps to serve small communities and have the Mastodon instance vibe, except one identity could appear on different instances at the same time. It doesn't exist yet, but it's possible.