Conversation

Notices

1. Embed this notice
   Christine Lemmer-Webber 🌀 (cwebber@social.coop)'s status on Monday, 25-Nov-2024 22:05:13 JST Christine Lemmer-Webber 🌀

   • mcc

   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

   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

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Tuesday, 26-Nov-2024 15:06:21 JST mcc

     in reply to

     • bryan newbold
     • Dan Sugalski

     @bnewbold @wordshaper @cwebber Yes, I can tell.

     Never mind "P2P" exactly. I'm interested in the property I mention above— that when you add more actors to the system, scaling gets easier. Your system doesn't have it. I think that's bad because I think the property is good. But more critically it's bad because it means you've created a system where no one else can ever replicate the services of bsky.app within ATProto without being *at least as large a company as you*.

     anban repeated this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Tuesday, 26-Nov-2024 15:06:21 JST mcc

     in reply to

     • bryan newbold
     • Dan Sugalski

     @bnewbold @wordshaper @cwebber Decentralization can be a positive. You've made decentralization into a negative because the more you decentralize bluesky, the more duplication of data is required. Indiscriminate duplication. It is the blockchain mistake all over again.

     And it's relevant to this conversation because to me, it makes the decentralization/freedom/"escape" properties of bluesky uninteresting. Because taking advantage requires, seemingly by design, a big company. I don't trust those.

   • Embed this notice
     Dan Sugalski (wordshaper@weatherishappening.network)'s status on Tuesday, 26-Nov-2024 15:06:23 JST Dan Sugalski

     in reply to

     • mcc

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

   • Embed this notice
     bryan newbold (bnewbold@social.coop)'s status on Tuesday, 26-Nov-2024 15:06:23 JST bryan newbold

     in reply to

     • mcc
     • Dan Sugalski

     @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

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Tuesday, 26-Nov-2024 15:06:24 JST mcc

     in reply to

     • Dan Sugalski

     @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

   • Embed this notice
     Dan Sugalski (wordshaper@weatherishappening.network)'s status on Tuesday, 26-Nov-2024 15:06:25 JST Dan Sugalski

     in reply to

     • mcc

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