[danabramov]

Running your own firehose is not expensive, fwiw, it's $30/mo. If I were making a "serious" app I'd probably do that. Otherwise, relying on community-maintained ones seems fine.

Running an AppView for your own app is not expensive at all. It can be as cheap as you want. It's only expensive if you want to store gigabytes of Bluesky posts and serve them to millions of users — i.e. if you want to build the full Bluesky AppView. But why would you want to build a Bluesky AppView? That's part of what I'm alluding to in my article — atproto isn't "for Bluesky". You can build any social app.

[JoshTriplett]

> But why would you want to build

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

[danabramov]

I don't understand how running your own Relay is related to competing with Bluesky. A Relay is just a dumb websocket broadcaster. Yes, you can absolutely run one on your own if you don't want to rely on any of the existing ones. I don't think this has to do with competition.

[JoshTriplett]

I'm saying that if there is any required component of a full ATProto setup whose lowest-friction implementation is "use the One True Central Implementation, which every tool defaults to and which will be very painful to change", then it's not a decentralized protocol. Are there any components of ATProto that are found not through a service discovery mechanism that would seamlessly migrate to a new service, but by every individual app going "here's the hardcoded URL we never expect you to want to change"?

I like the concept of working like RSS. I don't like the idea of having a massive ecosystem coordination problem with game-theoretic network effects, for any component of the system.