upvote
Yea that's fair. My stubborn point is that Fedi is trying to do the right thing using the wrong technology, and the resulting tradeoffs in user experience are why it will always remain niche. I hope that more resources will eventually flow from Fedi-centered solutions to more independent stuff in the atproto ecosystem.
reply
That goes to the heart of the issue. Bluesky's dependence on VC money and for-profit structure means it has a conflict of interest with long-term survival and independence of the protocol. But that might be fixable.

The mitigation is of course more companies and open source projects getting involved. As far as I understand it, the protocol is pretty well designed, and there is a bunch of open source out there already. It just needs more people to get involved.

But the article pointing out that you can migrate your Bluesky account to a thing called Eurosky was actually news to me. As is the existence of non Bluesky owned applications on top of atproto. I might give those a try actually. It seems a lot has happened since I last looked at this stuff a few years ago.

That still leaves governance of the protocol as a problem. That would ideally need to be untangled from Bluesky as well. But that seems doable as well. The more independent atproto software projects are out there, the harder it is for Bluesky to make breaking changes. That naturally pushes for some independent governance. I wouldn't be surprised to see that happen over time. But worst case, there could be some kind of fork/split of the network.

It would be interesting to see some attempt to bridge with other networks. A mastodon / bsky hybrid. Why make people choose? Despite X's demise, it's still X versus everything else. There's also Meta's Threads and a few others. The whole "not X" space fragments users over multiple networks that sort of could federate if they would but they really aren't. I think Threads is nominally mastodon compatible at least but actually federating is a bit frowned upon by Mastodon users.

And while we are "at" it, why not support email as well? Which is the og. federated communication network with essentially all internet users as active users. It's not perfect, but nothing better ever managed to replace it.

Separating identity from protocol is a good design choice. Cross protocol federation is a logical next step. It's all about receiving content from people, not about staying in walled gardens that belong to share holders.

reply
>It seems a lot has happened since I last looked at this stuff a few years ago.

Yes, a lot has happened! The scene still has very much indie vibe, but there's a lot going on in the Atmosphere. Atproto blog has recently started showcasing some community projects so check it out: https://atproto.com/blog

>That still leaves governance of the protocol as a problem. That would ideally need to be untangled from Bluesky as well. But that seems doable as well.

The core part of the protocol is literally going through the IETF process now: https://atproto.com/blog/taking-at-to-the-ietf. It's happening.

Re: other things, it's up to the community to do this. You can get involved. BridgyFed is doing cross-protocol federation and has been doing for a while: https://fed.brid.gy/. I'm sure there are other things that could be done in that space.

reply
Never rely a service just because they _hope_ to one day be less decentralised.
reply
It doesn’t fully resolve your concerns, but I do want to highlight that atproto now has an IETF working group to home its spec development
reply
"Seems to have worked OK for email"

THANK YOU. It seems like far too few in this space really understand the benefits of actual decentralization.

ATProto feels like "centralized, except also we get other people to do the hard work with few of the benefits."

reply
I think email is a pretty poor example of decentralization in the modern internet. I pay a company to not have to worry about hosting my own and I've still had emails blackholed by the massive providers for unknown reasons I can only assume are some combination of the custom domain* and the provider. I went back to using Gmail on my resume and for applications after nearly missing out on an interview because of it.

*: Not an .xyz, has proper SPF and DKIM records

reply