I feel like I may be missing something when it comes to BlueSky, or maybe both I and those trying it out are but in different ways. My understanding is that BlueSky is currently like the Mastodon Social instance is for Mastodon but of the AT Protocol under development, with the long term aim being that once their protocol is sufficiently developed to their liking, they'll put out the version capable of federation for others to spin up their own instances with.

However, once they do that, won't it basically create some of the same problems people already have with ActivityPub, i.e. instance choice, federation confusion, etc.?

What's supposed to set it apart and address existing issues rather than reinvent things and add their own distinct issues?

you are viewing a single comment's thread
view the rest of the comments

[–] fediverse_report@lemmy.ml 10 points 11 months ago (2 children)

I actually set out to answer this question in a blog post, but it turns out that the answer is quite complicated, so I have to write an entire series about it. First part I published this week, which explains all the different components that make up the Bluesky network:

https://fediversereport.com/how-bluesky-works-the-network-components/

I don't think that they'll run into the exact same problems that AP-fedi has, as the design decisions are often made specifically to avoid some of these. However, their design decisions create new sets of problems for the network, which I'll get into later

[–] otter@lemmy.ca 2 points 11 months ago (1 children)

A friend was asking about reading materials for the fediverse, specifically around how different platforms are handling instance selection. I'm taking a look through your past blog posts, but would you have any links handy for me to pass along?

[–] fediverse_report@lemmy.ml 2 points 11 months ago (1 children)

Oh thats an interesting question! I'm assuming you are talking about the UX/UI of instance selection?

And thats not something I have written about (neither does another article pop into my mind either sadly), but interesting idea for an article for sure to write about

[–] otter@lemmy.ca 2 points 11 months ago

Yes that's it, and no worries! Looking forward to the future articles

[–] maegul@lemmy.ml 2 points 11 months ago (1 children)

Nice! Was wondering if you'd pop in to this thread!

Looking forward to the rest of the blog series. Are you at all interested in or looking at what layers/components are amenable to 3rd-party community driven (decentralised?) development of alternative/new apps etc. The feeds system is obviously designed for that (and Relays obviously for big hitters only) but I'm unclear on the rest and curious to hear what anyone else thinks.

[–] fediverse_report@lemmy.ml 2 points 11 months ago

Heya! Good answers earlier by you!

Yeah I think I'll have to get into that, but I'm starting to run into the limit of not being a programmer myself, and information is pretty scarce on ATproto. The article differs from their own federation architecture description from earlier in the year, simply because its outdated and noone has formally written down the new info, so that was a bit of a struggle haha https://blueskyweb.xyz/blog/5-5-2023-federation-architecture

At any rate, the PDS's are amenable for sure. Robin Berjon is the furthest along with thinking here, with his AP over AT piece: https://berjon.com/ap-at/ Responses I've seen havent suggested its technically impossible, but probably difficult for reasons that I tuned out of reading because I didnt understand :D

Beyond that, people keep talking about the lexicon and how that at is core is also versatile; similar to how fedi has Mastodon's type=Note that everyone uses, even though you can create any 'type' you want. I'm pretty sure that nobody has done that yet tho.