Would love to know @laurenshof @smallcircles @maegul @hrefna thoughts on this one!

@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.

@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

@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.

@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)