And here's another example. ‪Frank Hecker discussed he analogy between Bluesky's approach and certificate authorities (CAs) in browsers on Bluesky; so did @cwebber here on fedi. Good points by both! But ...

The Bluesky discussion included discussions of verification as a security measure (and the risks of ad hoc security functionality), power dynamics, and other possible approaches like petnames, Trust over IP, using DV/IV/OV/EV SSL certificates, and other interesting topics.

The fedi discussion was almost completely developers discussing situations where people overrode the browser's (or OS's) list of root CA's. Is that really the key point here?

Again, don't get me wrong: the point Christine is making in the original post is a good one -- my frustration relates to where the discussion went from there. I'd use somewhat different language than Christine (since Bluesky's initial implementation does involve mutliple independently-run verifiers I'd consider it at least somewhat decentralized, but power centralizing) but that's not the important thing here. I certainly agree that this implementation approach very much fits the pattern of Bluesky introducing something that's architecturally decentralized but initially almost completely centralized operationally, with vague plans for more future operational decentralization and no discussion of pwer dynamics. Like I say, there's a lot to critique here!

But there's also a lot to learn, and at least from the discussions I'm seeing on fedi, people are generally taking a pass on the learning opportunities.