People describe ATProto as federated, and that has always bugged me.
-
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'
Glossary of terms - AT Protocol
A collection of terminology used in the AT Protocol and their definitions.
AT Protocol (atproto.com)
-
@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
ATProto for distributed systems engineers - AT Protocol
AT Protocol is the tech developed at Bluesky for open social networking. In this article we're going to explore AT Proto from the perspective of distributed backend engineering.
AT Protocol (atproto.com)
-
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] -
@jdp23 @lrhodes @laurenshof
I expect Mastodon's search things will be much smaller and less revolutionary than you're imagining.Also, fwiw, I think ATP is better both at interop between disparate systems and all-public publishing/sharing. And I think it's more flexible in practice. AP's most significant benefit is scoped visibility, as you call it. And it's not even good at that, it just doesn't prohibit trying.
-
Hard to know on how much impact this will have. If it's only Mastodon I agree with you, but also it depends to at least some extent on what Threads does. If they're serious about the fediverse -- or just want to pretend they are for PR/regulatory reasons -- I could certainly imagine them having a discovery provider (just as they've already talked about providing moderation tools). Or I could see Flipboard doing it, they seem to be betting on the fediverse pretty big (and I've been impressed with Mike McCue's strategic thinking). Time will tell.
And maybe AT is better at interop, I was just noticing that's where AP has traction now. And agreed that AP isn't particularly good at scoped visibility ... hmmm ...
@[email protected] @[email protected] @[email protected] -
@jdp23 @jenniferplusplus @laurenshof Seems to me there are some pretty fundamental differences between what they're describing and what AT relays do. You could (with limitations) build the AP equivalent of an AT relay, but only by violating a lot of the norms and expectations of federated networks, and the fedidiscovery project have stressed that they don't intend to do that. Maybe it could add features like moderation labeling, but not without huge redundancies in the system. But who knows.