Hacker News Reader

This isn't about "average user". Relays have nothing to do with using atproto as a user. They're about developers making new apps.

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.

You're getting hung up on the relay distinction (which is fair). But I'm not talking about relay's here.

And to be clear, I'm talking about the push back towards protocols and decentralization as the solution to enshittification and lock in. I fully believe decentralized protocols and the ability for us to run federated instances for our communities is valuable in and of itself. What I'm arguing against here is the degree to which the pro-social tech community has coalesced around this push as the one and only solution to the problems of enshittification.

And in that context, the average user is everything. And the push fundamentally misunderstands both how enshittification works (email is fully decentralized but still enshittified to a large degree) and the capabilities of the average user (not just their technical capabilities but their cognitive load capacity).

If you want, s/relay/pds/ and my point may become clearer. Or, even, s/relay+pds/app/. The point is pds+relay+app functions as instance for the average user. And the average user doesn't have the time, energy, or cognitive capacity to pick an instance that would be the right fit for them. Which means these decentralized networks are still heavily centralized. And if they remain heavily centralized, those central players still exercise an enormous amount of power over the network.

Including the power to enshittify it.

We can't solve enshittification if we're not cognizant of what the average user is capable of. And that capability extends to more than just "technical understanding". So far, I don't think the protocols push, in so far as it is being pushed as the solution to enshittification, is grappling with that adequately.

I view Bluesky as being decentralized-optional. It's cool because you actually can join first and wrap your head around it later. You can continue using your account you created on the fully 1st-party stack, and you still have the option to switch to self-hosting the parts you care about, without losing your posts or followers.

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

>"Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.

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.

> "Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.

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

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

I think people aren't paying enough attention this part right here: I think the architecture of atproto creates a different set of incentives. People running communities are more likely to face community pressure to ban users, or de-federate with other communities they don't like, and your open/decentralized network fractures apart, creating little silos.

People running infrastructure connecting them to a global network/resource are less likely to feel those pressures. No one asks an email provider to ban another webmail host. The architecture colors the perception.

The biggest problem Bluesky has had is that by virtue of being the only effective relay at launch, people viewed it more like the former and less like the latter. But I think if we start to see more places like Blacksky and Eurosky get mindshare, we can shift it back.

An average user does not need to run their own node for decentralization to work. It just needs to be cheap and easy enough for enough of technical users to run