What prevents somebody from hosting a community-operated ATProto relay with a few selected PDS and chronological-only Feed Generator?
-
Would love to know @laurenshof @smallcircles @maegul @hrefna thoughts on this one!
-
smallcircles (Humanity Now đź•Š)replied to Juan Luis last edited by
@astrojuanlu @laurenshof @maegul @hrefna
I haven't kept up with ATProto so can't point to particular challenges, but I think this is possible.
I might ping @erlend who has plans with #ATProto I think.
And @robin wrote https://berjon.com/ap-at/ pondering how to bring #ActivityPub in the mix.
Btw, I posted that to #SocialHub at: https://socialhub.activitypub.rocks/t/robin-berjon-running-activitypub-over-atproto/3707
-
@astrojuanlu @laurenshof @smallcircles @hrefna
No technical insight, but theoretically nothing (it’s encouraged by bsky devs AFAICT). Practically, the building of any reasonably sizeable relay isn’t trivial, and I don’t think they open sourced any of their relay code (??). Plus running it as a centralised service has financing/org challenges beyond what the Fedi is used to.
Also, it’d be separate from bsky, which maybe isn’t attractive. Tho PDS’s could talk to both, there d be no interop.
-
@astrojuanlu @laurenshof @smallcircles @hrefna
Personally, leaning into having distinct spaces is actually a good or interesting thing. So I’m with you! Eg https://bsky.app/profile/did:plc:n3tgni7rycxch2ob7h72god3/post/3l355t57nfj2f
A new AppView or client would be needed to integrate multiple spaces, and new PDS code/arch to work with multiple relays (??) … perhaps not hard with forms of bsky repos.
As you’ll see in the linked bsky thread, local relays for subsets of PDSs as “Fedi in bsky” was suggested as viable by smarter peeps than I.
-
My deeper question is why.
If you want to run a completely independent network using ATProto that's one thing, but using AP for that is neither necessary nor sufficient and it doesn't define the primitives that you would need.
You also need to figure out what you are doing with the requirement for publicly accessible URIs, etc.
But it isn't clear to me what you gain from all of that work?
-
Absolutely nothing is the short answer.
The slightly longer answer is that there are some core distinctions in how the servers run that would need to be settled (and some aspects that last I checked were not adequately defined in the protocol, though that may have changed since I haven't kept up with the latest), but there's nothing that stops it or even would make it particularly difficult.
-
@maegul @astrojuanlu @laurenshof @smallcircles @hrefna relay code is open source https://github.com/bluesky-social/indigo/tree/main/cmd/bigsky
6M accounts cost $150/month to run https://whtwnd.com/bnewbold.net/3kwzl7tye6u2y (more now, but cheap compared to what I’ve experienced running some Masto servers)
-
@boris @astrojuanlu @laurenshof @smallcircles @hrefna
Huh, newbold (and others) are using white wind, cool to see.
-
@astrojuanlu @smallcircles @maegul @hrefna
totally possible. in fact, another startup is actually doing this with waverly.social. same backend infra, build on atproto, completely separate from mainnet. but they're going the full ai feeds instead of only reversechronological feed.
also not sure why you'd want to disable other feeds beyond reverse-chron? one of the most powerful features imo
-
@astrojuanlu @laurenshof @smallcircles @hrefna
Generally, I *feel* like injecting some Fedi-style values into that system is a good and maybe even important thing.
The wind blows “everything is public” over on bsky, but ATProto’s declared values around diversity and community ownership need actual testing/proof, for which something like this is perfect. If their protocol takes off or even “wins”, establishing more independence early rather than late could be important.
All speculation ofc
-
@boris @maegul @astrojuanlu @smallcircles @hrefna
once the chaos dies down a bit im definitely curious for an update from @bnewbold on how much the relay costs now.
the real costs are in the appview, but you can sort of reverseengineer the costs based on this post by Why:
https://bsky.app/profile/why.bsky.team/post/3l3232j6m3d2balso note that their appview is ridiculously overengineered as it could handle this 20x traffic and apparently still have significant headroom
-
@astrojuanlu @laurenshof @smallcircles @maegul @hrefna the thing that's blocking is that there isn't such a thing really as being disjoint/not controlled by bluesky pbc in atproto - for anyone else to see you, you have to be crawled by the main relay. for you to see anyone else, you have to receive app-views/feeds from the main relay. so you could certainly set up your own PDS, and you can certainly set up a reverse chronological feed, and you could set up your own relay for that matter, but at that point you're just making another island
-
@laurenshof @astrojuanlu @smallcircles @hrefna
> one of the most powerful features imo
Also not inconsistent with Fedi values IMO. Basically like shared Misskey antennas AFAIU.
-
@jonny @astrojuanlu @laurenshof @smallcircles @hrefna
Yep. But if one had a client that made it easy to flip from public relay to small island relays (and then even to e2ee, pds2pds group chats), despite no interaction between the two … I figure that could be interesting.
Small, closed and big,public feel like nice options to have in one “system”.
The small relays then become just like Fedi instances, but with mobile identity kinda baked in through PDS “ownership”.
-
@maegul Yeah I was thinking of the archipielago model too. As @jonny says, to "be on Bluesky" one has to be visible by the central relay, there's no way around that. My point was more about using the technology to build our own, which doesn't necessarily have to be connected with the mainstream one.
-
@astrojuanlu
@maegul
Thats very possible, if there's one thing you can say about their tech, it is eminently runnable. At the end of the day the relay part is just a bigass JSON API, and the PDSes are slick little DAG-CBOR blobs.One problem is that the app is hardcoded to only use the main relay, and I think there are some 3rd party ones (?) But ya that would be one barrier. And ya none of the feeds would work, but you could probably get a relay and a PDS running in an afternoon, even if its just off on its own
-
@laurenshof @boris @maegul @astrojuanlu @smallcircles @hrefna yup, will need to update that guide/estimate. data volume has gone up a bunch, but we are also making the relay code (which is open) more efficient.
would also like to demonstrate/estimate how much it costs to run all the components: bsky appview, PLC, etc.
there are baseline indexing/storage costs, but currently most of the resource go towards serving requests (reads or subscribers)
-
Right. I think this is potentially a very interesting model, and you could clearly get going on it today ... as @[email protected]'s says, there's some stuff that needs to be done but it doesn't seem fundamentally all that hard (although of course the devil is always in the details).
One approach is to have an AppView and Relay per instance, where the AppView is an extension of the current Bluesky AppView that can consume multiple Relays. If you want the equivalent of local-only posts, you could potentially get it by having two Relays for each instance, one for public consumption and one that's only available to that instance's AppView; that would probably require a PDS extension to specify which posts go to which Relay. A nice feature here is that it this general approach could probably also support a "bubble" or an @[email protected] "island network" by having a per-bubble Relay. You could also make public posts avialable to the main Bluesky Relay if you wanted, which would give some interoperability with people on Bluesky itself.
That said this is all somewhat swimming against the stream of ATProto and Bluesky's model of an all-public protocol and a single "big room" conversation, so I'm not sure how actively people will pursue it. I talked briefly with @[email protected] a while ago about a specific bubble-oriented scenario that kind of architecture could be a good match for, but it wasn't all-public so at least today it seemed like other fedi infrastructure like GoToSocial, Glitch, or Hometown might be a better match (although adding bobble-level visibility to current fedi software is complex at the ecosystem level). To me the biggest long-term question is whether AT evolves from its current all-public focus, Bluesky's talked about adding private profiles at some point (which would be a good complement to the other very signficant improvements they're making), but I don't know what the expectations are at the protocol level.
@[email protected] @[email protected] @[email protected]