Live data from Hacker News

There are no instances in ATProto

overreacted.io

91–100 of 327 posts

Re: There are no instances in ATProto

#91
post #17

ATProto is an interesting protocol and there is lots of room to argue about its plus and minuses (and about Fedi/Masto's), but lots of people are already doing that so I won't. My concern isn't technology or culture, it's money. At the moment, ATProto is existentially dependent on Bluesky PBC, a venture-funded startup ($100M from Bain Capital). There are people doing good work to make it more decentralized, more powe…

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

Re: There are no instances in ATProto

#92

One thing I like about the ATProto is the stable identity, I could change the hosting as the author did recently and the other users see no difference. The one down side of the system is the cost. It's cheap to host a PDS but expensive for other components. Users could not relies on "someone" for running those components for free forever.

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.

Re: There are no instances in ATProto

#94

I appreciate how this explains the difference between the two. But I also found it a little frustrating, because it answered one part of the question but failed to answer the question so what does ATProto do to solve the problems that instances solve? For example, when this article dismisses defederation as merely a mysterious reason you might not see posts from your friends, it fails to answer "so how does atproto s…

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

Re: There are no instances in ATProto

#95
post #44

> Every single time a post about atproto hits Hacker News, somebody asks in the comments: “But where are all the Bluesky instances?”. The problem is, there are no instances in atproto! The question is a category error. Instances are a Mastodon-brained concept, and I wanted something I can link to that explains this clearly. I feel like you've (perhaps purposefully?) misinterpreted "instances" just to plug ATProto spe…

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.

I agree, a comparison and distinction is helpful, maybe even necessary. But I felt the author's bias came across a bit too strong in places and was a little distracting. Still interesting stuff though!

Re: There are no instances in ATProto

#96
post #82

I think the analogy presented here is broken. RSS doesn't depend on Google Reader at all. Even at its prime, RSS depended less on Google Reader than email depends on Gmail now. In ATProto, AppViews heavily depends on Relays to be useful, and Relays are quite expensive to run. Also, the yellow circles which represent blogs in the RSS illustration are really not of the same nature as the same circles which represent po…

> 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

Re: There are no instances in ATProto

#97
post #82

I think the analogy presented here is broken. RSS doesn't depend on Google Reader at all. Even at its prime, RSS depended less on Google Reader than email depends on Gmail now. In ATProto, AppViews heavily depends on Relays to be useful, and Relays are quite expensive to run. Also, the yellow circles which represent blogs in the RSS illustration are really not of the same nature as the same circles which represent po…

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

Re: There are no instances in ATProto

#98

I appreciate how this explains the difference between the two. But I also found it a little frustrating, because it answered one part of the question but failed to answer the question so what does ATProto do to solve the problems that instances solve? For example, when this article dismisses defederation as merely a mysterious reason you might not see posts from your friends, it fails to answer "so how does atproto s…

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

Re: There are no instances in ATProto

#99
post #44

> Every single time a post about atproto hits Hacker News, somebody asks in the comments: “But where are all the Bluesky instances?”. The problem is, there are no instances in atproto! The question is a category error. Instances are a Mastodon-brained concept, and I wanted something I can link to that explains this clearly. I feel like you've (perhaps purposefully?) misinterpreted "instances" just to plug ATProto spe…

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

Re: There are no instances in ATProto

#100
post #74

Earlier quoted context omitted.

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 i…

It's a comparison they are directly inviting, by constantly claiming it's decentralized. And then its defenders get upset when people rightfully point out that there is only a single instance, because that single instance going down takes the whole thing down. Like in Google Reader.

If atproto app goes down and it’s open source, anyone can put it back up with all public data intact.

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?

Post reply on HN