My read on #bluesky is that they are effectively sucking the air out of the decentralization balloon, whether they intend to or not. On the tech side, the #ATprotocol will prevent much decentralization from ever happening and divert the focus that was on #ActivityPub development. On the culture side, they deter a critical mass from developing here, which we need to overwhelm the influence of our most annoying users and lure in the people most people want to follow and interact with. #fediverse
@wjmaggos what about ATProtocol prevents decentralization?
From what I've read it promotes it better than the protocols here.
my understanding is you don't get server to server interaction, but there's an intermediary. it's supposedly designed to make things easier at the edge of the network, but my skepticism leads me to think they will just end up being choke points.
it's hard to get people to care about decentralization. it basically has to be forced on us, or most of us will use Amazon etc. I worry about mastodon dot social for this reason too, but here it's almost like setting up WP. not with BS.
I guess that would be good but isn't most of what we do on social media targeted towards the public? being able to tag people almost unavoidably creates confusion over who can see a post. I'd rather we somehow tie in another service and never try anything like a DM on fedi.
It's a really important point that different people use social media differently and expect different things out of social media.
The reason I think this point is so important is because too often users will think the system works one way and expect it to work that way when in reality it's working a different way.
That applies here. You bring up the idea that most of what we do on social media is targeted toward the public, and platforms like Twitter and Mastodon seem very focused on that mode, and there's absolutely nothing wrong with that.
However, a user that expects more privacy and less targeting toward the public might find themself surprised if their content is much more public than they were expecting.
So that's why I grind that ax pretty regularly.
it's a great point but I don't know how you build any momentum on a technology where different people come at it with such different expectations. instead you get a lot of people yelling at each other and curious newbies going somewhere else.
imo the big problem with fedi is that the tech argues for a system similar to Twitter but even more open and public. but it was first utilized by people trying to be more private, to have their own spaces away from Twitter etc. Ugh.
@wjmaggos Well the other half of the ax that I grind is that I wish Fediverse developers had much more of a focus on end users, on letting end empowering end users to shape their experiences the way they want so that different people can use the same platform in different ways.
We do see some of that with, for example, picture posting sites existing alongside the microblogging sites. Different interfaces just have to figure out how to handle different types of content coming across.
But taking it a step farther, this is why I emphasize ActivityPub being not so much decentralized as centralized around instances. That is a constraint that prevents this platform from being as flexible to different users.
And I think ATProtocol seems more decentralized and more flexible so that more users can have different sorts of experiences all on the same network.
In a way it's like how web traffic and email all coexist on the internet. If you decentralize more control you can have more different approaches to the experience.
I think where the fedi is held back is that development is more focused on type of service than type of user. maybe that's what you're saying too. the fedi is duplicating the platforms right now so there's a Twitter like instance/app and one for Instagram and Reddit etc. but our advantage is to let all those things commingle and have instances/apps for general users, but also ones for bloggers, podcasters, video creators. the one for gen users should handle all the inputs.
Well for what it's worth, my opinion, just an opinion, is that the platform was held back by engineering decisions that came out of a web server world, where everything was focused on servers instead of users.
If you look at the technologies underneath ActivityPub, it looks like developers grabbed a bunch of off-the-shelf web technologies and cobbled them together. Lots of http and webfinger and web certificates, etc.
They could have started more from scratch, but this is the direction they went, and for better or worse, it's going to be a server oriented platform because it was built on server oriented technologies.
I think it was a case of having a hammer and everything looking like a nail 🙂
I think that's true but it works. maybe something else would work better but imo we should be very skeptical of big tech coming along with "solutions" that require exactly what they can offer that we can't. BS seems better than most but maybe not good enough.
@Hyolobrika I'd be interested in learning about those proposals.
My concern is that it's like trying to bolt wings onto a car to make it fly instead of starting from scratch with an airplane fuselage: I think the platform is fundamentally not adapted for it, so I'm skeptical that those additions would work in an elegant way.
But I'm interested!
You can talk to @silverpill when he's online.
@Hyolobrika @wjmaggos @volkris I'm back. Was installing an update.
FEP-ef61 is our answer to ATP, Nostr, Farcaster and everyone else. And it can be introduced elegantly
Here's my actor in FEP-ef61 format: https://mitra.social/users/silverpill/fep_ef61
(Note: the link will be dead tomorrow, I'm moving stuff to a different location)
@wjmaggos I agree with recognizing that it works, although there are complaints ranging from efficiently issues through feature issues that I think arise directly from that web-based foundation.
Just to name one thing, complaints people have about difficulty in migrating between instances can be mitigated but never truly resolved simply because the web server approach binds users to servers, and there's really no way around that.
Thanks. Bookmarked!
@wjmaggos It sounds like you might be talking about the actual rollout rather than the protocol itself, which is kind of a different issue.
The AT protocol is decentralized even if nobody takes advantage of that feature. So it could be theory versus reality, and I'm talking about the theory, even if in reality right now the network isn't particularly built out yet.
But speaking of the protocol, as I recall one difference is that, the way you frame it, your mobile doesn't have to talk to A relay. It can talk to multiple relays, as many as it wants, it's in control. The control over who to talk to is distributed down to your mobile.
AP puts everything at the instance level. Your mobile has to talk to your instance, no other instance. And not multiple instances. Your mobile is bound to your instance.
With AP your mobile is really just an extension of the instance. With AT the relays work for the mobile.
maybe I misunderstand but you seem to be describing nostr more than the way I understand AT. and either way, AP is designed such that we can control the server or even make one that can run directly on our mobile eventually. over time, there will be more options. so that puts users fully in control if we want to also be a server admin etc. AT is designed to never support that afaik. there is always supposed to be a middleman relay that requires lots of resources. no?
Relays suck up data from PDSs (IIRC),and App Views from relays.
https://atproto.com/
https://bsky.social/about/blog/5-5-2023-federation-architecture
@volkris @Hyolobrika
I don't understand your version of centralization. If my mobile could talk to your mobile directly, that would be basically full decentralization. If my mobile talks to my server which talks to your server which talks to your mobile, that's more decentralized than most servers also having to go through one of a few relays. that's my understanding of AP vs AT protocol.
Re interfaces and instances, fedi gives developers more options than BS does because, see above.