People describe ATProto as federated, and that has always bugged me.
-
People describe ATProto as federated, and that has always bugged me. And I think I figured out why. It's not NOT federated. But that's deceptively incomplete. It's much more complete to say that ATProto is brokered.
I get why they do it. ATP describes itself as federated, after all. But there's a broker, and everything is mediated by the broker, which they name a "relay" (and used to call a big graph server, which was actually more honest).
-
Jenniferplusplusreplied to Jenniferplusplus last edited by
You can't realistically run your own broker. It's enormously expensive, and also no one would trust it, or even know it exists. You have to connect to the bsky broker. Which means bluesky controls the network, and you have to have their permission to join it.
This breaks one of the core, but often unstated assumptions people have about federated networks: that they are permission-less.
-
Jenniferplusplusreplied to Jenniferplusplus last edited by
And that ultimately is also why I don't view bsky with much optimism. When they run out of venture cash, they will either go belly up or give up control of the broker to become a surveillance capital device.
And I think we know which one they'll choose.
Either way, the fate of the network is tied directly to the fate of the company. For all their talk about openness and federation and whatever, this fact is by design. It's their network, and neither can survive without the other.
-
Jenniferplusplusreplied to Jenniferplusplus last edited by
Which means it's ultimately not so different from cohost. Except I always put a lot more faith in the principles of the cohost devs.
-
@jenniferplusplus I don't trust AT protocol, thus I don't trust Bluesky. I think the folks running the org are good people, but I consider it a mistake to label it as part of the "fediverse". To me, fediverse = ActivityPub. Always has been, always will be. If it's not a W3C spec, it's not a component of the open web. That's why I've shut down my account there and don't plan to return.
-
@jenniferplusplus generally agreed, the relay and its financials are the elephant in the room about the place.
But intuitively I feel like there could be interesting possibilities around decentralised & plural “brokering” all the way down to inter-instance (or PDS) AP style networks while still connecting to the “central” for-profit network. Which is many are kinda doing already by being on here, threads and Twitter simultaneously, just better organised and with decentralisation throughout.
-
Bluesky certainly uses federation in a different sense than the instance-oriented way today's ActivityPub-centric Fediverse does. I think it's technically correct; "federation" is a general term for networked servers working together. Still, somebody from Bluesky asked a while ago whether they should stop using the term and I said yes -- it's confusing because people are used to instance-oriented federation.
In terms of brokering, @[email protected] makes similar points in https://destructured.net/federated-mediated-networks and @[email protected] 's argument that https://fossacademic.tech/2024/04/30/DecentralizedNoncentralized.html that "Bluesky will never be federated" is also somewhat similar.
I think this is true of Bluesky itself, but not true of AT in general, for two reasons:
- Relays are optional components, AppViews can go directly to PDSs -- SmokeSignals (events on AT) does it that way
- Relays don't have to be whole-network, so aren't necessarily prohibitively expensive
And I don't think the permissionless assumption is true for federated networks in general. Oliphant's island networks are permissioned (allow-list based) but very definitely federated.
@[email protected] -
Jenniferplusplusreplied to Jon last edited by [email protected]
@jdp23 @lrhodes @rwg
My read so far has been that the relay defines the network, and so it must be whole network. Connecting to multiple relays seems like it would basically guarantee split brain scenarios, and I don't see any process to resolve inconsistent state.And island networks are still permissionless. There's no authority for the network that can add or remove participants. It's a collection of peers with mutually agreed policies. That the policy is default closed doesn't change much.
-
Baral'heia Stormdancer ΘΔ🐲replied to Jenniferplusplus last edited by
@jenniferplusplus I've been thinking a lot about this lately, how Bluesky's current architecture still appears to rely on centralized services they control, like their BGS/Relay and (if I understand their architecture right) the AppView too... It looks like Bluesky has published their "bigsky" BGS/Relay service code in their GitHub. Do you happen to know if it's actually functional code? I don't know enough about it to try tinkering with it yet. But I'm curious as to whether or not it's even possible to run your own third-party ATproto relay right now with the code that has been published... and how it would participate in the network. The readme for bigsky also seems to say that relays are not required, that appviews can connect directly to the stream from a PDS... any idea if that's actually accurate or not?
-
Jenniferplusplusreplied to Jared White last edited by
@jaredwhite I don't think that's a useful distinction, but it's also not what I was talking about.
-
Jenniferplusplusreplied to Jenniferplusplus last edited by
@jaredwhite by the way http, URIs, TLS, and numerous other core web technologies are defined in IETF RFCs
-
I agree that Bluesky's whole-network Relay defines Bluesky. I don't agree that all AT-based networks are defined by Relays in general or the Bluesky Relay in particular, at least in theory. Relays for non-overlapping PDSs and/or post types (whatever they call them) don't necessarily have split brain or inconsistent state. But, who knows how things will work out in practice. Time will tell.
Maybe we're thinking of permissionless differently. Island networks (as Oliphant defines them) require consensus to add participants and I think have some voting mechanism to remove participants. Earlier this year I pitched an idea for a closed subnetwork of Hometown instances, with limited briding connectivity to the broader network, and there was an explicit approval process as to who could be on it which I'd also describe it as very much permissioned. Agreed that these aren't common today but I think that's an artifact of the preferesnce for "openness" (as it's typically defined) over safety.
@[email protected] @[email protected] @[email protected] -
Jenniferplusplusreplied to Baral'heia Stormdancer ΘΔ🐲 last edited by
@baralheia I don't know. I'm not trying to run a relay. And I find it really hard to read this spec for more than a couple of pages at a time because of how drenched in libertarian nonsense it is.
-
Baral'heia Stormdancer ΘΔ🐲replied to Jenniferplusplus last edited by
@jenniferplusplus Totally fair, I didn't know if you'd played with any of that stuff at all. I've tried to read the specs too but it seems really incomplete or out of date... like talking about how they "may" separate out labelers and feed generators into their own separate services (when this has already been done lol). Mainly just trying to figure out what would happen if Bluesky itself disappeared tomorrow and if/how their network could actually survive that. That was the main reason I asked.
-
Jenniferplusplusreplied to Baral'heia Stormdancer ΘΔ🐲 last edited by
@baralheia it does seem out of date. I don't know for sure if there's any way for the network to outlive the central relay, but I doubt it.
-
@jdp23 @rwg @jenniferplusplus ATProto lists relays as one of the three "core services," so unless I'm misunderstanding your point, I'd say the protocol is explicitly defined by relays and their relation to PDS and app views. If a network dispenses with that core service, I'm not really sure to what extent it would make sense to call it AT-based anymore.
-
@lrhodes @jdp23 @rwg @jenniferplusplus
they updated the atproto.com website recently, the glossary describes relays as 'an optimization and are not strictly necessary'
-
@laurenshof @jdp23 @rwg @jenniferplusplus Interesting. They haven't made that messaging consistent yet. https://atproto.com/guides/overview still lists relays as a core service. Seems clear this is a change in positioning.
I'm not yet convinced that it's a substantive change in approach, though. Functionality still depends on connection to App Views, which serve as a mediating authority. It looks to me like they've just shifted the center of gravity from relays to AppViews.
-
@lrhodes @jdp23 @rwg @jenniferplusplus
on a side note, i can definitely recommend this new blog that came with last weeks update to atproto
-
Thinking about this again after Mastodon's announcement of Fediverse Discovery Providers today. https://www.fediscovery.org/
These seem to play a similar role to AT-style Relays. If they want to provide global search (which is at this point table stakes for a big world Twitter alternative), it's not clear what other scalable options there are. If the implementation is as efficient as AT's the costs of a running a whole-network service provider are presumably likely to be roughly comparable to the costs of a similarly-sized Relay, so very expensive for a whole-network provider.
Of course FDPs are optional. But once they're available, instances using these services will be a lot more more attractive to people who want a Twitter alternative that instances that don't provide global search. So they're not really optional for that use case (just as AT Relays aren't really optional for something Bluesky-scale). Networked communities that only care about search and hashtags of a subset of the network probably don't need them, or if they do the scope of the discovery provider will be smaller so it hopefully won't be prohibitive (like AT Relays scoped to a subset of their network).
And as the announcement mentions, they'll support other kinds of providers. Providers that can label posts, accounts, and instances with information useful to moderators and moderation tools? Providers that give instances and individuals access to customized feeds? The possibilities are endless!
So on the one hand, you can build the AT architecture on top of today's AP (ActivityPods are PDS-like). And as Robin Berjon has pointed out, you could do AP on top of AT. At least today they clearly optimize for different things: AT for scalability and all-public networks, AP for flexibility (which comes with a complexity cost) and scoped visibility ...
My intuition is that today's AP is probably better for connecting disparate systems (Wordpress, Threads, Flipboard, Mastodon, Lemmy) that aren't necessarily built with AP internally. Today's AT is better for building large all-public somewhat decentralized (although not in the same way as today's instance-oriented fediverse) social networks that an then be connected with AP (or whatever).
@[email protected] @[email protected] @[email protected]