What prevents somebody from hosting a community-operated ATProto relay with a few selected PDS and chronological-only Feed Generator?
In other words, what prevents us from building a Fediverse disjoint (and not controlled by) Bluesky PBC, and based on ATProto instead of ActivityPub?
[#]FediMeta #ActivityPub #ATProto
=> More informations about this toot | More toots from astrojuanlu@social.juanlu.space
Would love to know @laurenshof @smallcircles @maegul @hrefna thoughts on this one!
=> More informations about this toot | More toots from astrojuanlu@social.juanlu.space
@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.
=> More informations about this toot | More toots from maegul@hachyderm.io
@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.
=> More informations about this toot | More toots from maegul@hachyderm.io
@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
=> More informations about this toot | More toots from maegul@hachyderm.io
@maegul @astrojuanlu the protocol depends on and cannot work without everything being public, in fact
=> More informations about this toot | More toots from jonny@neuromatch.social
@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)
=> More informations about this toot | More toots from boris@toolsforthought.social
@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/3l3232j6m3d2b
also note that their appview is ridiculously overengineered as it could handle this 20x traffic and apparently still have significant headroom
=> More informations about this toot | More toots from laurenshof@indieweb.social
@laurenshof @maegul @astrojuanlu @smallcircles @hrefna @bnewbold running a service for millions costs a lot.
The way this is architected can start quite small.
And if the stated goal is “I want to run a community PDS” that’s small.
Running a PDS and a custom client (equivalent to eg phanphy) - even an Ozone mod client - also cheap.
Just not the same as how AP is constructed out of individual servers.
=> More informations about this toot | More toots from boris@toolsforthought.social
@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)
=> More informations about this toot | More toots from bnewbold@social.coop
@boris @maegul @laurenshof Looking at how much some Mastodon servers cost, 150 USD/mo for 6M accounts is indeed not that expensive...
=> More informations about this toot | More toots from astrojuanlu@social.juanlu.space
@astrojuanlu
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.
@laurenshof @smallcircles @maegul
=> More informations about this toot | More toots from hrefna@hachyderm.io
@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
=> More informations about this toot | More toots from laurenshof@indieweb.social
@laurenshof @astrojuanlu @smallcircles @hrefna
one of the most powerful features imo
Also not inconsistent with Fedi values IMO. Basically like shared Misskey antennas AFAIU.
=> More informations about this toot | More toots from maegul@hachyderm.io
@maegul @laurenshof Not really thinking of disabling other feeds, just as a way to outline what basic components form a Mastodon-like experience today.
=> More informations about this toot | More toots from astrojuanlu@social.juanlu.space
@astrojuanlu @maegul @laurenshof I'm still gathering details and figuring out a way to do something similar with atproto. Just the basics to tinker with. Did you come up with anything so far?
=> More informations about this toot | More toots from okpierre@mastodon.social
@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
=> More informations about this toot | More toots from jonny@neuromatch.social
@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”.
=> More informations about this toot | More toots from maegul@hachyderm.io
@maegul @astrojuanlu it's a nice dream, but think having to duplicate every part of the system that makes it useful is a pretty strong barrier to secondary relays
=> More informations about this toot | More toots from jonny@neuromatch.social
@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.
=> More informations about this toot | More toots from astrojuanlu@social.juanlu.space
@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
=> More informations about this toot | More toots from jonny@neuromatch.social
Right. I think this is potentially a very interesting model, and you could clearly get going on it today ... as @hrefna@hachyderm.io'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 @oliphant@oliphant.social-style "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 @bnewbold@social.coop 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.
@astrojuanlu@social.juanlu.space @maegul@hachyderm.io @laurenshof@indieweb.social
=> More informations about this toot | More toots from jdp23@blahaj.zone This content has been proxied by September (3851b).Proxy Information
text/gemini