How does this differ from scrapers hitting the blog directly?

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.

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.

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

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

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

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.

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.

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.

What I hoped to read in the article is how we approach topics like centralization, censorship, moderation, data ownership--and with a technical lens. But I feel like all I got was "here's why instances are the wrong vocabulary" without substantively talking about the part I personally care about and want to marry the technical understanding with. Maybe I just read too shallowly and need to sit with it.

I completely agree with the point in your link that relays are different to instances - I love architectures involving dumb-relay or zero-trust type nodes. But I think Relays should still be mentioned in your post, since they're probably the main architectural element which protect PDS instances from the scale issues heavily federated AP instances might face, right? (I only have a high level understanding of ATProto and very little experience with AP, happy to be told I just need to learn more for this to make sense.)

Swarms of content.

Cryptographic identities and content signing/attribution.

Cryptographic hashes for content uniqueness/immutability.

Immutability in general.

Ephemerality (content lives as long as some node cares to retain it, otherwise it gets forgotten).

Concrete but extensible ontology for core concepts.

You don't need login. You don't need to agree on a common platform. 3rd party tools and extensions can filter content, provide trust graphs, interest graphs, etc.

You can just slurp up and score whatever might interest you. Your agent or algorithm might do pre-filtering against your preferred heuristics to downsample to relevancy.

You could write any client for this in any shape or form. Completely different look and feel for different people and interests / focuses.

Your definition of "most people" must be very different than the literal meaning.

However there is very little incentive to mirror any of the firehouse if someone else is doing it for free.

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?

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.

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.

With a PDS, the replication happens first, before anyone reads it, and the UI is out of your control.

Maybe that’s okay, but people should understand the tradeoffs.

This is the wrong way to see it. There is no "Best and correct" solution, only solutions with different trade-offs. ActivityPub/Mastodon/Federation makes sense in some cases, "pure" direct distributed P2P makes sense in some cases, one central server makes sense in some.

Bluesky/ATProto just made different trade-offs, for different use cases, some of which wouldn't have been possible without the architecture they ended up with, which sibling commentator expanded on exactly what.

Even if it’s not open source, anyone who wants to write the code can still get it back up with all public data intact.

I think it’s a substantial difference with “takes the whole thing down”. Can we acknowledge that?

If you ask a list of specific questions, that would help a lot. I might be able to write something or reply inline here.

Atproto is an attempt to engage with the problem space in a way that hits the baseline UX of Web 2.0 apps.

But it’s worth noting atproto designers come partially from P2P lineage. Some worked on Scuttlebutt, IPFS, and others.

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.

The difference is on ATProto, when I get banned, people must switch to another "AppView instance" (could be reusing the same Bluesky AppView stack) to interact with me. I summary, my data is not lock in, but my audience could be.

On the other aspect, Bluesky AppView is only a small part (a microblogging network) of the bigger Atmosphere where we can create different AppViews for different use cases, e.g. publishing (leaflet.pub), code repository (tangled.org). Users can use the same handle and PDS for these AppViews.

AT doesn’t have this kind of issue even without Relays. This is because PDS never talks to another PDS so there’s no quadratic growth of edges. PDS only talks to apps, and there’s limited amount of apps on the network. And end users hit apps which cache stuff, so apps tend to take the user traffic hit.

Relays are helpful more on the app side because you don’t want to teach each app to crawl PDS’s and subscribe to them.

I didn’t dive into Relays in the article because they’re kind of a “next obvious optimization” but not really inherent to the model. There are other models like apps hitting shared backlink caches (like Constellation). Relay isn’t fundamental in the way hosting and apps are.

It's a cool idea, in practice it kind of sucks as an experience.

It's been developed adjacent to the Bitcoin community and I can't say there's much going on besides spam.

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.

(NOT ATProto and ActivityPub. Those are platonic ideals of protocols which have no real-world implementations. ActivityPub, especially, was obviously designed by architecture astronauts.)

The east-west schism took way longer to allow some reconciliation :)

I’m running an atproto app and it’s perfectly capable of ingesting the entire firehouse as it comes in. It costs me maybe $10/mo and mostly because I haven’t fixed some memory leaks.

Of course, few of records that come through are relevant to my app so I don’t store them.

If I wanted to store gigabytes of records (like Bluesky) for millions of users forever then yes it would be more expensive. Which would be the case with any tech! What are you comparing it to? How is this a downside of atproto?

Mastodon instances aren’t a valid comparison point because by definition they’re small-world. They don’t serve millions of users.

If your point is that you want small-world atproto, that’s absolutely possible. Take the Bluesky server codebase and make it so that it ignores incoming content beyond some criteria (like “follows of server member list”). You can recreate Mastodon experience on atproto, it just hasn’t been very interesting to anyone so far AFAIK.

Neither of these prevent scraping, and the lack of the first one actually makes it worse because every scraper has to go to the original server and bog it down instead of getting it from anyone with a copy of the data that they can verify using the signature.

> there are ways to block bots with things like captchas

These don't work if you have anything resembling high value content, because AI can solve them now or do the same proof of work as a real user when all they need is to get a few hundred articles once. If they want it enough they can also pay someone in a low income country to download them manually. Fundamentally if you post something that any human can access then someone can copy it. Public is public.

And if the content is the equivalent of blog comment posts, they can probably still get it, but in that case why even care if they do? Notice that this is the same thing that happens on the centralized services, e.g. Facebook uses your Facebook posts to train AI.

I'm hoping that perhaps my personal perspective shades why "instances" comes up, or why the reaction on HN seems to include the wider scope than the article itself covers.

Yes, a lot has happened! The scene still has very much indie vibe, but there's a lot going on in the Atmosphere. Atproto blog has recently started showcasing some community projects so check it out: https://atproto.com/blog

>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 core part of the protocol is literally going through the IETF process now: https://atproto.com/blog/taking-at-to-the-ietf. It's happening.

Re: other things, it's up to the community to do this. You can get involved. BridgyFed is doing cross-protocol federation and has been doing for a while: https://fed.brid.gy/. I'm sure there are other things that could be done in that space.

https://blue.mackuba.eu/directory/pdses

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

If Bluesky specifically wanted to just not have its user interact with some other entity in ATProto-land would they be able to?

My impression is that the answer to this is "yes", because people are signing up to Bluesky and relying on Bluesky to hold on to their posts etc.

Similar to how Email is all federated but in practice a bunch of people use email from one of a handful of large service providers who (in practice, not necessarily for nefarious reasons) do end up blacklisting certain email senders.

The RSS-reader example feels a bit different on the ground because for a given user, "store a list of websites you care about" is not a complicated endeavor.

For the "short-form social media with algorithmic timeline" usecase (which isn't all atproto is about, granted!) "users self-host a thing to scoop up enough of the world's posts to then make a local algorithmic timeline" doesn't... doesn't feel very feasible, right?

I guess the blogspot comparison is apt... but if "full" self-hosting requires a relay with quite some juice ($30 is "cheap" but... compared to a pile of files to host your own blog...), then in practice we're going to see a heavy amount of centralization anyways right?

I prefer AP for one reason, it's more accessible to the people. I would prefer to see small computer organisations with member fees, and donations, that run their own little node, instead of huge monolithic components.

That's why I never liked bsky, because it was too monolithic. I never liked the monolithic AP instances either. If we're going to decentralize, let's properly decentralize.

As soon as something becomes huge and monolithic, it's a red flag.

What we have is a "diaspora", what was once one larger community has moved on to a lot of smaller, more disparate spaces. That's not necessarily a bad thing, but a lot of trade offs were involved, a very large community feeling was lost, and a lot of intangibles were lost (friends with Gmail accounts that could easily follow and interact with us in Google Reader but are lost trying to navigate any other RSS Reader, for instance).

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.

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.

If the instance goes down, the network stays up and continues to work, minus only the accounts on mastodon.social. This is not the case on bluesky afaik. They got DDosed a few months ago and the whole network was down because of it. https://news.ycombinator.com/item?id=47802330

In ATProto there aren't 'instances', and its technically 'decentralized' but theres really only bluesky.

Okay, but that's always the case when you get banned from a service. The difference here is that it's possible to build a competing service with different moderation decisions being a lens over the same data.

And I honestly think this is one of the fundamental problems with the push back towards protocols and decentralization. We're overestimating the bandwidth and capabilities of the average user and we haven't fixed the problems that pushed everyone towards centralization in the first place.

Take me, for instance. I am not only capable of running my own Mastodon or Atproto data server+relay -- I'm technically capable of writing my own ActivityPub or Atproto app.

But I'm currently sitting with accounts on bsky.app and mastodon.social -- the biggest most centralized "instances" (yes, I know, but it reasonably describes the problem). This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.

And this is doubly and triply true for the average person who doesn't have the technical abilities I have.

As a result, both Mastodon and Bluesky are still practically centralized to a large degree. An overwhelming majority (more than 90% last I found data) of Bluesky users are hosted by bsky.app. Similarly on Mastodon, a large plurality of users (~20%) are on Mastodon.social. Mastodon's obviously doing better than Bluesky in this regard, but it also has about a quarter of the overall traction, and I'd honestly put that down to Bluesky's apparent centralization which makes it a lot easier for people to join and wrap their heads around it.

This is the part I would be looking for, in an article talking about "there are no instances". Is there a standard protocol for this, so that anyone can spin up a shared moderation service that people can subscribe to if they're aligned with it, and be able to plug that into any standard app built on the protocol (not just Bluesky-the-company's app)? Or is this something specific to Bluesky-the-company?

If this is a standardized part of the protocol, then that answers the question of "how does ATProto solve the same problems defederation solves".

There are several other things I can think of in the category of "how do you solve the problems that ActivityPub uses instances to solve", but they're things I've already asked in other parts of this thread, namely "how do you make the parts of the system not shown in the tidy hosts->apps M:N graph decentralized, too".

I get that it’s not ideal but I think it’s worth keeping in mind that there’s not much you can mess up with it other than refusing to update requests. The threat model is very limited and it would immediately be obvious that this is happening, killing the credibility.

I personally think that this actually leads to healthier communities but that may be a matter of taste!

Bluesky users can interact with Blacksky users and vice versa unless Bluesky has applied moderation to the Blacksky user, because they are decentralized via ATproto. ~Twitter~ X users cannot interact with users on any other application, because X is not decentralized.

Most people won't do it, but they don't have to, and it's not a particularly expensive hobby.

The problem is that that sounds like "you shouldn't want to compete with Bluesky". Which makes it dangerously centralized.

>"But where are all the Bluesky instances?"

I agree that it doesn't mean "atproto went down", and I don't mean to imply that. but "bluesky went down" is completely accurate, and bluesky is the one claiming to be decentralized due to using atproto. there are no other instances in bluesky's network, only partial ones (blacksky, last I heard they were still working on a major piece?), hence the "no it's not" responses. and that's also how they're directly encouraging people conflating the two.

And maybe that's a good thing.

If I read a post from a month ago, how will my client know how many likes it has or what the replies were? Without reverse links, someone has to look up in a database of all AT actions for likes/replies pointing to that post.

Contrast with the inbox/outbox forward/reverse linking model of activity pub.

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.

Whereas with Mastodon your PDS is your AppView, so if you leave the AppView you lose your PDS (and have to somehow export it).

Is that correct?

> because you don’t want to teach each app to crawl PDS’s and subscribe to them

Why not?

If I want true decentralization, that means no central component. For the same reason that communities and individuals host their own RSS readers, each community will in the end also have to host their own relay and app view.

The benefits of decentralisation, including fault-resistance and censorship-resistance, can only manifest once every community is self-hosting their own relay and app view.

see https://www.youtube.com/watch?v=BxV14h0kFs0 twitter, etc once had a much more open API. so did reddit. This was just the first stage of their penetration strategy.

The decentralization is totally irrelevant due to the way it's implemented. The problem is that Apps are sticky, so app developers have undue power to control their users.

The "content hosts" "moderators" etc need to be completely cut out of the picture to be at the same level of censorship resistance as an RSS-shared blog. I can host a blog on my own computer, and you can subscribe to it without that many intermediaries.

A social graph is more than just data, it is trust, it is attention, and it is political goodwill. That's one of the most important lessons of the fall of Google Reader. It wasn't just that the technology was shutdown, but that it damaged communities when it shutdown. You can't capture communities that don't feel like they belong anymore, that no longer trust you because you closed their former town square.

I still don't see enough evidence if BlueSky itself shutdown that ATProto survives that shock culturally, even if it is built to do that technically. If Mastodon.Social, still the biggest instance, shutdown tomorrow a number of Mastodon instances wouldn't even notice and some of the ones that did notice would just as likely throw a party as lament the disappearance. That's a pretty big cultural difference, not a technical difference.

At the end of the day, truly fully decentralized systems are literally impossible, there's always a centralized aspect (at least for bootstrapping) and it's usually DNS-shaped.

That being said, PLC directories are a problem that blockchains (yuck) actually solve very well: trustless, public ledgers. I would not be surprised if we see a separate implementation based on an architecture derived from such systems.

The guy who runs FSE (one of dark fedi's more notable instances) has written a lot of good blog posts on his side of the technical and social details, his one about running FediList is a good picture of the type of one-sided politics involved (and, if you're into the technical stuff, is rich with that too): https://blog.freespeechextremist.com/blog/about-fedilist.htm...

- If you just want to use your domain name as a username, you set a DNS record.

- If what you care about is the client, you can build your own website or native app. You don't really even need to host a server other than for your own static assets, since the app can request Bluesky network data directly via the logged-in user's PDS (they even have CORS headers!)

- If what you care about is data sovereignty, you can self host your PDS (personal data server) on a low-end VPS. It's cheap because it pretty much just holds your data, passes events to Relays, and proxies data requests to your preferred AppView.

- If what you care about is not needing to trust Bluesky to reliably gather and collate events from each PDS, then you'd need to host a Relay ($30/month) and an AppView (even more expensive) so you'd be best off pooling resources with other people you trust. But that's kind of the nuclear option.

- With a narrower scope though: if you noticed that Bluesky was censoring a handful of legitimate accounts and you still wanted to follow them, I think you could probably have a personal Relay+AppView that only listens to the censored accounts' PDS's, and proxies other requests to the 1st party AppView. (I'm not 100% sure if that would be allowed.)

That doesn't mean other places aren't doing so. As an example - here's a list of all the relays that mirror the ATProto network: https://atproto.at/relays

There's 16 relays by my account, of varying sizes. Of course, you don't have to query a relay - you can look at the Personal Data Servers (PDSes) directly.

Speaking of - there are just over 3000 PDSes: https://blue.mackuba.eu/directory/pdses

Each of these PDSes hosts one or more accounts, and you can self-host your PDS to truly own your data up and down the stack.

There's also oodles of different applications, of which Bluesky is just one. There's:

* Germ (encrypted DMs, Signal competitor)

* Leaflet (blogs, Substack/Medium competitor)

* Semble (link collection/sharing)

* BeaconBits (location-based social media, like FourSquare)

* SkyReader (Google Reader)

* Keytrace (cryptographic identity proofs)

* Smoke Signal (social events)

* Teal.fm (Last.fm)

* Goals.garden (goal/habit tracking/accountability)

* Tangled (GitHub)

* Sifa (LinkedIn)

* BookHive (Goodreads)

* Streamplace (Twitch)

* Spark (Instagram)

* Grain (also Instagram)

* Popfeed (Trakt)

* And more, like the TikTok clone I can't remember the name of, some more blogging platforms, a (fairly dead) Hackernews clone, some games, etc.

That isn't even mentioning all the Bluesky clones like Blacksky, Eurosky, Northsky, and W.

Each of these shares the same account - the account on your PDS, which you can self-host on any computer with an internet connection. I run mine alongside my smarthome server. Because they share an account, they interop - I can subscribe to a blog on Leaflet and have it show up in my Bluesky feed.

These services can fetch data from your PDS directly, or they can look at the Relay and get the full view of the network - but frequently, they don't need to.

Bluesky went down a couple months ago and many of these services were all perfectly usable, because they used the protocol but not any infra provided by Bluesky itself. The people who couldn't access the network were the ones who relied on Bluesky to host their accounts - which is a majority of the network, sure, but in the same way that Mastodon.social is a good chunk of Mastodon's network. I was able to use Blacksky to post onto Bluesky while Bluesky was down, because I was self-hosted.

Now both Eurosky and W have launched; Eurosky is aiming to be fully independent this summer and I _think_ that W already is? W's a bit more closed-off than most of the other projects I named, going directly after Twitter-as-it-is-now and not Twitter-as-it-was (hence why they chose W to compete with X).

Of course, nothing stops an app from doing moderation differently and not using any of that. This is more for better composability and interoperability.

Yes and I find it rather egregious that you can pay (a lot) to self-host a full stack then still be locked out of the majority of the audience of an entire "decentralized" platform by a single centralized entity.

For all of the problems with ActivityPub defederation, at least with ActivityPub you have:

- Many options of places to go in the Fediverse, with a wide spread of different ideologies and approaches to moderation.

- The option to feasibly self-host your own instance that is completely independent. You can be blocked by the major instances still, so they still have the ability to moderate just the same. However, as far as I know no AP server has more than half the active users of the whole network, which is a much more robust split.

It's true that Bluesky architecture enables something like Blacksky to exist. But if there were just two independent ActivityPub hosts and one of them was many multiples the size of the other the protocol would've been declared a massive failure for good reason.

And as far as I know the Fediverse mobile apps and clients are agnostic to your instance, so the apps don't have any influence over what you're able to see. Isn't this what is expected from something that is decentralized?

Not sure how I haven't heard this one before, but I'm stealing it. Salient descriptor.

By "most people" it's implied we're talking about most people who want to run a web app in their spare time. Do you mean a different definition? If you want to run a web app (which is the only reason you'd want a relay) and you're able to pool with ten other developers who want to do the same, you can make the cost to $3/mo. Is that feasible? What do you normally pay for web app hosting?

And again, if you're a hobbyist developer, you'd just use a community relay that already exists and is free. I assume that, if you want to run your own, you have a specific reason to do so.

??? that's not the point. the goal isn't that some non-technical 40 year old will run their own relay. the goal is that relays will be cheap enough to run that there can be hundreds of relays for developers of apps to choose from.

relays are DEVELOPER facing only, meaning the developer of the app chooses which to use, and can even use none at all and build the functionality of the relay into their app itself.

no matter where your account is hosted, it will be crawled by every relay (unless it's banned from some of them) so users or people who "don't have the bandwidth to think about this" don't have to worry about relays at all. anyone who will ACTUALLY BENEFIT from an independently hosted relay (app dev) will perceive them as an incredibly marginal cost.

> This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.

Idk what to say to that. So I'll just say that you can run `npm create pds` and have a single-user PDS hosted for free on Cloudflare in minutes.

But I think what you meant to say (stop me if I'm wrong) isn't that you don't have the "mental bandwidth", it's more that you (and the average user) don't actually _want_ to migrate because there's no tangible benefit.

To this I would say: migration is not the path to spreading users out across instances at a large scale. Migration to me is more of an insurance against a service going down or turning evil. The real way to get people to spread out across different PDSes is to make it so there are more "entry points" to the atmosphere, so more people are onboarded to the atmosphere in more places other than Bluesky, where they can sign up and automatically be on another instance. If more independent atproto apps are created with their own PDSes for onboarding, that's what will solve the problem imo, not encouraging users to migrate (although that can also be done at smaller scales, as Blacksky and Eurosky have proven)

I don't think that was a recommendation for people to do, but to demonstrate that it doesn't require much in the way of resources. That VM could probably host hundreds of people, since relays scale and de-dupe shared content.

If someone said that email or a personal website was inexpensive and could be hosted on a cheap VM, I don't think you'd make a comment like the above dismissing it as impractical: the idea is that if it's that cheap, then there are people that can host cheap/free (maybe ad supported) relays, similar to how cheap/free webmail exists today.

In fact, in cases where Bluesky _did_ go down, Blacksky was still working fine (if a little slow due to the amount of Bluesky people on Blacksky), and people were able to make posts and everything.

Coming up with a new model for social media and also dictating what features are good and bad for users is going make user adoption a tough challenge.

When developers feel empowered to revive products or fork them, I think that eventually seeps into communities. That it’s another way of doing things. It doesn’t happen overnight but this energy exists in the Atmosphere. Maybe loss of Bluesky is not survivable culturally at the moment, but maybe it will be in a few years as Atmosphere grows and matures.

So the new thing here is that if everyone’s data exists in this format, the competition between apps is guaranteed. Because a competitor doesn’t start with nothing: they start with the same userbase and the same content. They can immediately start competing on features, moderation, product experience, etc, without first “luring” everyone to register again and start their entire graphs from scratch.

I think that makes a big difference. Don’t you think?

I still don't quite understand your comment.

>If there are advantages to ATProto over ActivityPub in this kind of deployment setting, they don't seem clear enough to offset the weird corporate parentage

The advantage of atproto is that it's literally "the web". Every app can aggregate from entire network, there's no isolation by default. It reduces to the degenerate smallest case just the same — you can have a single-user app that simply displays content from your PDS. But you can also start aggregating things (e.g. comments left by other users, which are stored on their PDS's). The whole big idea of atproto is that every app is effectively a CMS for app-agnostic "model" web.

What is the concrete thing bothering you? AT is already in the IETF process. It's not some weird corporate thing.

Concrete example: Bluesky banned a person, and Blacksky community disagreed with that ban. When Blacksky switched http://blacksky.community app to have its own complete stack (including its own database), that person’s posts became visible there (despite them being banned on Bluesky app) because they reversed that moderation decision. This was possible because the data for this person’s posts still lives on their PDS.

In general, the data being “pulled outside” products is what enables new products (or forks of products) to come onto the scene and immediately begin competing because they don’t have to solve the “cold start” problem. If you log in, all your stuff is “already there”. And it’s the same shared world so the community doesn’t get forked. You’re just looking at the same underlying data under a different lens, and products act like lenses rather than boxes.

This doesn’t mean that “censorship” can’t exist (every layer can ban you, as always) — but it means that every layer of the stack has opportunity for competition that isn’t possible with centralized platforms. In fact, arguably, it’s more flexible than a Mastodon instance because you can’t fork a Mastodon instance “with all its users” and offer a version that reverses some moderation decision. In atproto, you can.

A "lite" version of Mastodon that dispensed with all of the complexity involved with managing multiple accounts and was optimized for a single user might be nice but with a hosted account you're paying for data storage (which Mastodon seems horribly inefficient with) so in practice that extra complexity is moot.

Isn't that similar with Mastodon? Someone on an instance that does not federate with yours will not see your posts, and I guess someone on an instance that would censor you would not see your posts?

That someone would have to change instance if they disagree with the moderation, and doing so is more painful with ActivityPub than with ATProto, right?

Disclaimer: I have no skin in this game, I don't use social networks. Just interested technically :-).

Migrating to a different App View should be painless in theory (app views are not supposed to collect any state that is not saved in the PDS, not sure if Bsky does or not), and you can use multiple app views with one PDS. On Mastodon, you have to migrate both at the same time, and moving content across instances is not yet a fully solved problem.

I wrote this other comment that I think does well to address this misconception: https://news.ycombinator.com/item?id=48601998

> Many options of places to go in the Fediverse, with a wide spread of different ideologies and approaches to moderation.

And an account tied to exactly one of them, that is a pain to migrate if it's even possible with the ActivityPub application you use. This causes decision paralysis and dissuades most people from even considering joining.

> The option to feasibly self-host your own instance that is completely independent. You can be blocked by the major instances still, so they still have the ability to moderate just the same. However, as far as I know no AP server has more than half the active users of the whole network, which is a much more robust split.

Within what is effectively a rounding error, everyone that uses ActivityPub uses Threads. Blacksky is definitely a larger percentage of the ATProto network than mastodon.social is of the ActivityPub network.

> But if there were just two independent ActivityPub hosts and one of them was many multiples the size of the other the protocol would've been declared a massive failure for good reason.

True! Just like if there were hypothetically only two ATProto applications, that would not be very interesting. I think I've used four or five ATProto applications with my identity? Pretty cool stuff!

> And as far as I know the Fediverse mobile apps and clients are agnostic to your instance, so the apps don't have any influence over what you're able to see. Isn't this what is expected from something that is decentralized?

There is nothing in the protocol enforcing this and this expectation has been broken in the past.

https://github.com/tuskyapp/Tusky/issues/2224

This is in addition to the fact that "clients" in ActivityPub extend to the monolithic instance itself, and therefore is also broken by the very "defederation" you already mentioned!

---

I am very familiar with ActivityPub. I don't hate it. I ran multiple instances for years (one for my friends, and one for my family). ATProto is simply more flexible (allows applications to scale up to provide an experience that one would expect coming from centralized applications) and easier for non-technical people to use. And it's decentralized, which is awesome.

Joel's post was the genesis https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

Salient indeed!

I'm kinda hoping someone sets up a rainbowsky or something for us in the LGBT community. Now that I would join.

I'm not sure that's totally right, though, because I (using the entirely default bsky stack) can and do regularly interact with people who are using different PDS and AppView's (like, I can interact with Eurosky and blacksky accounts).

I think the thing that is centralized by default is the bsky moderation layer.

Blueksy holds all the power, while the users hold none, whereas with Mastodon has many separate communities, similar to the old-school BBSes, forums, IRC and teamspeak servers.

Well, it's where we used to be — and it solves most of the issues of the modern web. Forums, blogs, IRC, teamspeak, gaming servers, etc, it all used to work relatively well with that approach.

The thing there is it destroys the objection people have about having to find and fit in with a particular Mastodon server community.

It also makes Mastodon look more like the original blogosphere and less like Twitter, which is a good thing.

Interesting. I'm an architect by title because my employer doesn't have the career path of a "senior specialist who really knows their stuff and wants to keep going at it". No. We have only two paths: either Manager (not interested in the slightest), or the almighty Architect. Every time I'm forced to architect something, that bit about the bottom line comes to my mind.

If you want to filter for events based on some heuristic (e.g. only from follows of server list), you can do that. You can then specialize that further. E.g. for ongoing threads that already pass your filter, you could add their IDs to an array, and accept all replies for those threads as well into your DB.

You already get a stream of everything so you can scale down what you write to DB to exactly the characteristics you need. Including keeping threads cohesive.

OK, but that raises a question. Can I do that right now? If so, I don't understand why more people are doing this. When I looked into this I definitely didn't see anything like this.

> And an account tied to exactly one of them, that is a pain to migrate if it's even possible with the ActivityPub application you use. This causes decision paralysis and dissuades most people from even considering joining.

I like the concept of W3C DIDs, but it's a little soured for me that there was no real solution to the PLC DID problem. It is, quite literally, the exact opposite of being decentralized. (IIRC they do support one of the other DID methods, but it's not default, and I couldn't figure out how.)

Which seems like a common theme. You can absolutely fix the downsides of the Fediverse, it just requires you to reduce how decentralized the network is :)

> Within what is effectively a rounding error, everyone that uses ActivityPub uses Threads. Blacksky is definitely a larger percentage of the ATProto network than mastodon.social is of the ActivityPub network.

While this is technically correct, Threads is not widely considered an instance in the Fediverse and is missing in "instance lists". Threads is less like a part of the Fediverse and more like a centralized social media service service that supports interoperability with ActivityPub.

> True! Just like if there were hypothetically only two ATProto applications, that would not be very interesting. I think I've used four or five ATProto applications with my identity? Pretty cool stuff!

This is cool but not relevant. I'm more specifically talking about Bluesky vs the Fediverse here, when referring to the protocols. Obviously there are also uses of ActivityPub that are not Mastodon/Misskey as well.

I haven't seen another ATProto application that I found interesting enough to try yet.

> There is nothing in the protocol enforcing this and this expectation has been broken in the past.

> https://github.com/tuskyapp/Tusky/issues/2224

I never suggested it was literally impossible for someone to do it... but the concept of a "Mastodon" app is inherently agnostic to the instance in a way that Bluesky's apps are not.

> This is in addition to the fact that "clients" in ActivityPub extend to the monolithic instance itself, and therefore is also broken by the very "defederation" you already mentioned!

Sure. I'm suggesting you can't actually have decentralization without the possibility of all of ActivityPub's downsides. You can't use technical means to fix the social problems with decentralization; you can only defacto centralize things.

> I am very familiar with ActivityPub. I don't hate it. I ran multiple instances for years (one for my friends, and one for my family). ATProto is simply more flexible (allows applications to scale up to provide an experience that one would expect coming from centralized applications) and easier for non-technical people to use. And it's decentralized, which is awesome.

ATProto is decentralized, at least to some extent.

Bluesky isn't really, though.

You can have an account on Northsky and use it with Blacksky's appview!

An "AppView" is the API server that most clients connect to that aggregates data from the network and serves it in a more useful way. mu.social still uses bluesky's AppView (api.bsky.app).

The name is confusing. I thought clients were appviews myself for a while.

It is just an entire Mastodon instance with one account, though.

Anyways, it's similar in my company. People get the architect title, so managers can justify the salary promotion.

No, there is not. There is blacksky, northsky, eurosky. They all display the data from your PDS.

I'll definitely try it out!

> Plus, whenever I’ve gone to create an account I’ve been presented with a huge list of servers to chose from, many of which seem to be focused on a specific topic, which makes me think I need to pick which community I want to be tied to with minimal knowledge.

As you're already self-hosting ATproto anyway, why not self-host a mastodon instance as well?

Also the best algorithmic “For You” feed on the app runs off someone’s gaming computer at home

How is comparing Mastodon/the Fediverse and Bluesky unfair? Are you kind of admitting that Bluesky isn't actually practically decentralized by suggesting the AP analog of Bluesky is the largest Mastodon instance rather than the federation of them? This seems to contradict what you and much of the marketing around Bluesky says.

It’s just as cheap as hosting any webapp.

But what you’re asking is not that. You seem to be saying “I want to host my own Bluesky appview”. That’s resource-intensive for the same reason “I want to host my own Twitter backend” is expensive. It has nothing to do with the protocol! If you want to host a database application server that stores gigabytes of data from millions of users forever, you’re gonna have to pay for that. This isn’t some kind of gotcha with the protocol, it’s just common sense.

That’s the “instance brain” from my article. You’re used to the shape where the only thing you can host is a “isolated copy of the same app that only deals with a few users”. But that’s not the atproto topology! What atproto lets you host is the real thing. Like a second real Twitter app that “just works” with all existing users. That’s the value proposition here. Or — if you’re not actually in the mood to host a product with millions of users — you can make your own app that has nothing to do with Bluesky. And of course your own app aggregating its own data would be cheap to host because it won’t be aggregating millions of records.

Do you see the disconnect? Atproto allows competition at big scale — actually forking real products — which AP doesn’t do in principle. But you’re using this ability as a knock again atproto. Atproto scales arbitrarily up, so you take the highest scaled up example you can think of (Bluesky app with all its users and posts) and compare it to the cost of running the most scaled down version of AP (an isolated app for some people).

To make the comparison fair, we’d need to scale atproto down in your example. You can definitely achieve scale identical to Mastodon (and thus identical in costs) by taking the Bluesky app server and adding custom logic which ignores all events that aren’t relevant to some hardcoded lists of users (your “member list”) or people they follow. That would be an accurate comparison, and yes, you could totally host that.

People don’t do that because it’s kinda niche. Maybe it would be nice if there were ready-to-go distributions of Bluesky appview that do this kind of filtering. But also — it’s just kind of a non-goal for most developers on the platform. Most developers create their own different apps, rather than host alternate projections of the Bluesky content of the whole world.

Where do I login to ATProto. It's not an application. It's a network of applications.

Where do I login to Bluesky? https://bsky.app

Where do I login to Mastodon.social? https://mastodon.social

People use apps, not networks of apps. Saying you don't care about the broader ATmosphere is exactly the same as saying you don't care about the broader Fediverse. That's fine, but then let's compare apps to apps instead of an app to a network. How does bsky.app compare against mastodon.social? (Actually let's not do that, because comparing a single app in a decentralized network to a single app in another decentralized network is pretty boring).

> Are you kind of admitting that Bluesky isn't actually practically decentralized

The data is meaningfully decentralized (more so than any AP app). The user identity is meaningfully decentralized (more so than any AP app). Moderation is meaningfully decentralized (similarly to AP apps). Independently developed applications are meaningfully interoperable (more so than most AP apps, especially leveraging DIDs). People can and do run their own AT infrastructure all the time. Ask questions instead of trying to pin people with gotchas based on incorrect assumptions.

What steps do I have to follow to get the majority of users to see my content?

Another example. Let's define decentralisation in terms of bus factor:

How many companies could go bust today before most users would notice?

> To make the comparison fair

Okay, so let's build that, then we can actually talk about building a decentralized network on atproto.

How do I build a relay that fetched all content from people I follow, plus all replies to those posts (no matter who sent them), plus automated backfilling if I click on the profile of someone who I'm not following yet?

From what I understand, in bluesky the PDS does not know about replies to a post. So I'd need to scrape the entire network anyway, no matter what, even if I only store some of it.

And every blue-stodon instance would have to scrape every single PDS. So it's a much much worse O(n²) issue, isn't it?

I'm comparing two supposedly decentralized microblogging platforms, Bluesky and Mastodon (and compatible microblogging software.)

The things in your post don't hold up. For example, people log into apps. OK. So when I log into my email account using Thunderbird, that's decentralized. Right? Literally I am using a client to connect to some IMAP+SMTP server. Couldn't be more decentralized.

So now let's say I log into gmail.com. That's still email. Is email still decentralized with the existence of gmail? Well, it is less so than it maybe should be, but absolutely! Because I actually use Fastmail. That's what a federated network looks like.

When I log into Matrix, I still use Element regardless of homeserver. I can use any instance of Element, or install it to my machine. But still, it's Element. That's what a federated network looks like.

Not all decentralized things are federated. Some of them are, for example, peer to peer, and many other architectures.

I am ignoring the broader ATmosphere because it is not part of Bluesky the microblogging network. There are also plenty of ActivityPub applications that are not Mastodon-compatible microblogging networks, and I'm not talking about those either. I'm not talking about, for example, the network of Peertube instances that are also using ActivityPub.

I fully admit that I am not an ATProto expert, but if you're not running a Bluesky compatible AppView that speaks the Bluesky schemas, you are not participating in Bluesky, which is what I am talking about specifically.

I have used the terms "ATproto" and "ActivityPub" only in the context of Bluesky/compatible and Mastodon/compatible. That is it. If you wanted to argue about something else, it is not me pulling a gotcha on you to refuse. I just simply don't care, and you are not taking the hint. It's my damn comment thread, I know what my intended scope was. I know, too, you must know that Bluesky itself is supposed to be meaningfully decentralized, such that you can indeed run your own entire appview stack and still be a part of Bluesky, so you must understand that what I am doing is inherently an apples to apples comparison.

Yet when I log into Bluesky using a Bluesky app, what I get is the Bluesky appview and Bluesky moderation service. This is because Bluesky is substantially more centralized than the Fediverse. You can kick. You can scream. It doesn't matter. Bluesky. Is. Centralized.

> The data is meaningfully decentralized (more so than any AP app). The user identity is meaningfully decentralized (more so than any AP app). Moderation is meaningfully decentralized (similarly to AP apps). Independently developed applications are meaningfully interoperable (more so than most AP apps, especially leveraging DIDs). People can and do run their own AT infrastructure all the time. Ask questions instead of trying to pin people with gotchas based on incorrect assumptions.

With all due respect, to the extent that there is any, no thank you.

They could rely on some relays to build their AppViews. The flexibility is already there.

You can’t “get” the majority of the people to see anything, that’s not how anything works. Neither on centralized systems, nor on Mastodon, nor in real life.

On a centralized platform, if you get banned, there are no steps you can take. Your account is down — goodbye.

On a Mastodon instance, there are also no steps you can take. Your account is banned on the instance — your entire identity goes down with it.

On atproto, it depend on whether you’re banned at hosting or app level.

If you get banned at hosting level (usually something clearly illegal would trigger this), you’d have to find another hosting (assuming apps haven’t banned you too).

If you get banned at an app level, people will see you through different apps. You’re right that this presupposes that there are apps that (1) people use, that (2) haven’t banned you, (3) and that display the same type of content.

But, even if you’re looking from solely censorship resistance perspective, atproto at least enables competition in moderation space to happen. If enough people disagree with the lens, it is possible to build a an alternative lens over the network.

This isn’t theoretical — there was a situation like this where a person got banned at Bluesky app, but the Blacksky community wanted to reverse the decision. When Blacksky got an independent app database running, they overrode it. But yes, this does require investment and a subset of community being interested in alternative moderation / features / etc. You can’t “force” people to hear you but there’s a market for alternatives.

> How do I build a relay that fetched all content from people I follow, plus all replies to those posts (no matter who sent them), plus automated backfilling if I click on the profile of someone who I'm not following yet?

The realtime part is trivial. You just filter the stream of everything as it comes in.

Backfill would either require you to index the network yourself or to rely on existing indexes. You could use Constellation (https://constellation.microcosm.blue/) to fill up threads (query by thread root ID), and you’d hit the user’s PDS to fill up their profile page.

You could actually see that in practice now at https://reddwarf.whey.party/ which my article links to. It’s a Bluesky client that doesn’t have a server at all (and doesn’t hit Bluesky API). It’s lazily getting stuff on the client purely from PDS’s and from Constellation. It’s a bit slower than an appview-backed experience but it works fine.

You're constantly looking at it from the wrong perspective. I don't care about the instance I'm on banning me because I am the one that hosts my instance.

What I care about is that I am able to connect with any of my friends without the data going through any central arbiter that can decide what we get to see or not.

And on mastodon, if one instance defederates from me, pretty much everyone else will still be able to interact with me anyway, it's not the end.