back

by danabramov·1mo ago·view on hn ↗
Note that “instance” is Mastodon-brained and is a wrong way to think about atproto. The correct parallel is RSS / Google Reader.

Atproto has two types of things: hosting and apps.

- Hosting is like RSS. You can host your data on your own server and broadcast from it. It’s just an open source Docker container.

- Apps are like Google Reader. They aggregate from all hosts and usually build an index so they can show a rich view over the network. That’s what Bluesky, Leaflet, Tangled, etc, so.

So there is no “instance”. There’s hosting and there’s apps.

1 comments
Update: I just wrote a post about this since I keep typing it over and over in these threads. https://overreacted.io/there-are-no-instances-in-atproto/
Your post changed my prespective on atproto! It also solidified the architectural issues I've had all along with the fediverse, and view that it's more of an interim solution which doesn't resolve the core centralisation and censorship issues; often exacerbating them to the extreme.

Just noticed who you are. Big fan of you're work and approach to problem solving! Do you have any similar posts about alternative protocols in this space, like nostr et al?

I've been ruminating on the incorporation of censorship resistance by adopting core concepts from tor/I2P and Monero using cryptographic techniques for validation and obfuscation that enable users to subscribe to specific communities, chatrooms, or channels within a PDS, so they also operate like private/public-PDS's to replace messaging providers with a uni/multi/any-cast rss. The reason I think this should coexist in the same protocol is that if the hosting provider itself is untrusted by default, and all comms are E2EE between all consumers from the ground up (public comms could contain a decryption key in the response, or one assembled by relays), the individual hosting providers can't choose to selectively filter or censor individual comms they disagree with at any layer, because they can't see the speech, where it's coming from, or where it's going; even for publicly broadcasted comms, until at least after the response has been transmitted to relays (enforced by the protocol).