Live data from Hacker News

There are no instances in ATProto

overreacted.io

271–280 of 327 posts

Re: There are no instances in ATProto

#271
post #228

Earlier quoted context omitted.

> I don't care about controlling my PDS if other people can't see my posts. 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,…

It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky. And you’re meant to either host your own instance, or pick one that aligns with your views and interests, such that the bulk of moderation is handled for you in terms of which instances you federate with etc.

> It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky.

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

Re: There are no instances in ATProto

#272
post #216

Earlier quoted context omitted.

I'm one of those "is it decentralized yet" people and to me the real concern is the AppView since I assume that's where censorship would be applied if it ever happens. People keep telling me about PDSes but I don't care about controlling my PDS if other people can't see my posts .

The difference between Bsky and Mastodon is that Bsky unbundles PDSes and App Views, while Mastodon does not. 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 instan…

The difference between the two is that Bluesky has a central audience with decentralized content, while Mastodon has a federated audience with federated content.

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.

Re: There are no instances in ATProto

#273

Earlier quoted context omitted.

It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky. And you’re meant to either host your own instance, or pick one that aligns with your views and interests, such that the bulk of moderation is handled for you in terms of which instances you federate with etc.

> It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky. No, there is not. There is blacksky, northsky, eurosky. They all display the data from your PDS.

I'm already running my own RSS reader, Matrix server, Mastodon instance, etc. How do I run my own appview? They surely have a git repo, docker images and helm chart, right? And if I can't self-host it, surely every local computer club should be able to, as they are with all the other protocols?

Re: There are no instances in ATProto

#274
post #120

Earlier quoted context omitted.

I felt the same: when folks ask this question they might not be using the correct terminology, but what they actually want to know is how many different PDSes (that's what you mean by "atproto hostings", right?) there are in a typical feed.

Currently, just over 3000: https://blue.mackuba.eu/directory/pdses

There are:

- 221 with over 5 accounts

- 74 with over 20 accounts

- 19 with over 250 accounts

- 8 with over 1000 accounts.

And only a handful of those have open signups (13 with open signups have >50 users).

Many of them are actually ActivityPub instances with a PDS bridge, e.g., https://join.wafrn.net/

And most of the other open signup instances are also primarily designed as their own social network, just using AT proto as a compatibility layer, e.g., https://sprk.so/ https://haruhwa.com/ (which is an invite-based, snapchat-style ephemeral social network), https://surf.social/, https://pckt.blog/ (a microblogging platform), aesthetic.computer (a collaborative programming/art platform)

That leaves only bluesky, blacksky, eurosky, selfhosted.social, self.surf and npmx.social.

Even during Facebook's heyday, the unsuccessful diaspora/friendica/gnu social/etc networks had more decentralization than that.

Re: There are no instances in ATProto

#275
post #81

Earlier quoted context omitted.

Thanks for the fair response, I agree you're being cheeky. Sorry, I'm being lazy not searching here, but have you written anything on if instances of something is a good measure of decentralisation? (FWIW, I feel independently owned/managed instances in the traditional non-mastodon-definition seems like an okay measure of decentralisation.) I completely agree with the point in your link that relays are different to i…

In Mastodon/AP, different instances talk to each other which creates the scale problem you’re mentioning. 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…

Wouldn't I have the same quadratic growth (if not worse) if each community were to self-host their app view and relay?

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

Re: There are no instances in ATProto

#276
post #52

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…

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…

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

A good measure for decentralisation is: Can your community continue using the service if the rest of the world disappeared? Can you still federate with other communities that might still exist? What else needs to remain for the service to remain useful?

With mastodon, all of that is trivially answered. With AtProto, I'm either 100% reliant on bluesky, or I'd need to spend tenthousands of dollars a month minimum to self-host the relays and app view.

Re: There are no instances in ATProto

#277
post #108

Earlier quoted context omitted.

Well, I think you also need to consider what PLC is. It’s an open source implementation of an open source spec. The implementation holds zero private state and exposes a verifiable log of operations for audit. There’s ongoing work on mirrors and replicas. Also, its output itself is cryptographically self-verifying. 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…

I’d also call out that activitypub has the same threat model in the form of ICANN, as it’s also heavily dependent on DNS for identity. I believe these are reasonable trades to make; realistically the alternative is to use a blockchain, which few people are keen to do.

Not necessarily – there are some activitypub instances without hostname, directly on IP addresses, and there are even some running in private DNS roots.

Re: There are no instances in ATProto

#278

Earlier quoted context omitted.

> It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky. No, there is not. There is blacksky, northsky, eurosky. They all display the data from your PDS.

I'm already running my own RSS reader, Matrix server, Mastodon instance, etc. How do I run my own appview? They surely have a git repo, docker images and helm chart, right? And if I can't self-host it, surely every local computer club should be able to, as they are with all the other protocols?

You can trivially host an appview for your atproto app on your own. I have a hobby atproto app, and I host an appview for it. I mean — an “appview” literally just means “a server with a database that ingests stuff from the network”. It’s not some mysterious thing or some concrete distribution. It just means you’re aggregating stuff into your database.

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.

Re: There are no instances in ATProto

#279

Earlier quoted context omitted.

In Mastodon/AP, different instances talk to each other which creates the scale problem you’re mentioning. 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…

Wouldn't I have the same quadratic growth (if not worse) if each community were to self-host their app view and relay? > 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…

Maybe we’re just ideologically misaligned here. I think every single little community hosting a copy of every single app is insane, and not where I’d like to end up. It’s like the extreme end of the spectrum compared to centralized Web 2.0. I think atproto’s ethos falls somewhere in the middle — community is mostly a “soft” primitive, and there’s only so many full-scale “copies” of some app as there are strong opinions+funding bundles that motivate their existence. So maybe not too many for large scale ones.

Re: There are no instances in ATProto

#280

Earlier quoted context omitted.

You can switch to the AppView from https://mu.social/ and you'll get editing working.

mu.social is a "client". 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.

I kind of started calling them all “apps” with true appviews being “independent apps”. I think sometimes it makes sense of think of this as an implementation detail. For example, Mu could actually switch to its own database if they do a bunch of technical work in the future. From the users’ perspective, it wouldn’t be noticeable.
Post reply on HN