Embed Notice

Interesting ...

My quick reaction is that the different potential levels of blocking in AT Protocol are a complication, and so are the multiple paths of access. A couple of specific examples:

Bluesky PBC controls the PLC directory, so if they blocked an did:plc account at that level it would affect access to 100% of the network. But did:web exists as well, and the blocking there is done by DNS authorities or whoever controlls the domain if multiple people are using it. If 99% of accounts currently use did:plc (I just pulled that out of the hat, and have no idea what the actual numbers are), that means B(1) = 99 ... but it also means that it's trivial for anybody blocked to create a new did:web account and evade the block. Then again, this is a situation where (if I understnad correctly) there isn't "credible exit" -- you can't convert a did:plc to did:web, so you'll lose your data and network.

Similarly, looking at the MIssissippi situation, where Bluesky blocked access at the app level. 99%+ of the people currently use the app; Other apps don't block, and VPNs exist, so it's trivial to evade the block ... but a lot of people don't know this. So is that B(1) = 99, or B(1) = 0, or ...?

I also wonder if a single overall number for the whole ATmosphere obscures important differences between different subnetworks. If Bluesky PBC's Relay and AppView block a PDS, then that PDSs. users are arguably essentially cut off from the "Bluesky network" (whoever that's defeined). But, their own internal connectivity might be a lot less affected -- if for example they've got their own custom AppView. Then again they also potentially have their own internal choke points. So Blacksky's B-index (or Gander's, or Spark's) is different than Bluesky's, and I'm not sure about aggregating them.

@bnewbold