Firehose access on Bluesky gets shut off for Bridgy Fed for a while https://github.com/bluesky-social/atproto/discussions/3094 https://github.com/snarfed/bridgy-fed/issues/1520#issuecomment-2492534380

Christine Lemmer-Webber

Not malicious, but what's notable here is that Bridgy Fed was unable to work w/ Bluesky during this period. I think @mcc is right that it's a reminder this is a result of centralization https://mastodon.social/@mcc/113541216191108214

Dan Sugalski

@cwebber @mcc Scaling is hard and if you don't aggressively use a core feature when developing a system it's really easy to find it falls over hard, so I have some technical sympathy for BlueSky here.

I'm not in any way surprised, mind. I also fully expect to find that the end result is Bridgy Fed gets shut off basically forever "while BlueSky works out some scaling issues" that never actually get fixed.

mcc

@wordshaper @cwebber i come from a world where p2p is supposed to make scaling issues easier rather than harder

one reason this incident is interesting to me is it shows bluesky is not operating in that space

Dan Sugalski

@mcc @cwebber I'm gonna guess that Bluesky doesn't have p2p really and truly built into their core node, and it's basically a monolith. Their scaling issues reek of that, honestly -- p2p with 99% of your work on one central node has a nasty tendency to fall over when the external nodes start getting bigger.

bryan newbold

@wordshaper @mcc @cwebber "p2p" is not really a design goal for us.

the architecture of atproto has helped a bit with scaling at times (we have dozens of PDS instances, and can spin them up on any provider), but can also lead to weird/unexpected degradation patterns ("invalid handle" due to BGP glitches, notifications not being sync'd). it made early development very slow, and it takes a bit longer to train new employees.

several of the core team accounts are on indie PDS instances