Sure, and happy to answer questions.
Our basic plan is: "federation is scaling!"
We're going to run a number of PDS instances and (transparently) place users on the best instance for them based on laws/latency/etc.
And we'll do classic big-ol-distributed-systems stuff for BGS/AppView aggregators.
Our basic plan is: "federation is scaling!"
We're going to run a number of PDS instances and (transparently) place users on the best instance for them based on laws/latency/etc.
And we'll do classic big-ol-distributed-systems stuff for BGS/AppView aggregators.
Reposted from
Nehemoth
Hi @jacob.gold can you talk a bit about the infra growing in sync with user base?
And what's the plan for near future, if any.
Thank you
And what's the plan for near future, if any.
Thank you
Comments
(I don't know all the details but our lawyers certainly do!)
see also:
https://bsky.app/profile/johnspurlock.com/post/3jw6ahz2kw32j
https://github.com/bluesky-social/atproto/tree/main/packages/pds
does make run-dev-env include a firehose?
it doesn’t seem like it, but that’d be helpful in order to test the feedgen stuff locally.
i see where the code is starting up the test PLC/PDS, so i’d guess i could spin it up there?
Our two chosen languages for services are TypeScript and Go. TS is doing most of the heavy lifting today.
Everything runs in simple containers. Most are public and available on GitHub but aren't super user friendly yet.
Why not Rust?
Only asking because these days I see rust like for everything.
But TypeScript/Go are extremely good at cloud infra/services and (IMHO) more productive, easier to hire for, more easily maintained.
But we might use Rust for something if we do need it!
I also know much less about TS than I do about Go!
For Go: it's just really hard to beat its scalability, stability, and simplicity.
All data is self-certified (using public-key cryptography) so is safe to get from anywhere.
Currently: BGS doesn't use Postgres (much). AppView uses it for everything. Search is ES.