6 ms·
An unfortunate step backwards. I'm cheering for Eurosky and open networks.
by BigTuna 3mo ago
An unfortunate step backwards. I'm cheering for Eurosky and open networks.
- Imustaskforhelp 3mo agoEurosky actually looks like a promising alternative (speaking as non-european) but the AT protocol should have more open friendly competition than just the flagship instance of bluesky. Eurosky seems interesting as well.
- BigTuna 3mo agoIn addition to Eurosky there's also Blacksky, Northsky, and Anisota. Plus dozens of other non-microblogging apps. AT is growing pretty quickly now.
- danabramov 3mo agoNote 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.
- danabramov 3mo agoUpdate: 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/ https://overreacted.io/there-are-no-instances-in-atproto/
- TalkingCodeMonk 3mo agoYour 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).