It's in line with the protocol design. If only BlueSky themselves could verify, that'd be too centralized.

Mind you, just because anyone can create a verification record doesn't mean that the default client shows them.

> Why do we need these “Blue Checks”?

Normie users care about this sort of feature.

I'm not sure about the details of the protocol (maybe someone can check?), but the client software can probably distrust certain trusted verifiers or even use a public list of such revocations. If this opportunity is exploited by malicious actors, there must be a simple and fast escalation path to revoke verification (you complain to verifier, then to maintainers of revocation list).

We need the blue checks to combat impersonation attacks. If a malicious actor pretends to represent a New York Times journalist, or your bank, or a government agency, you don't want users to be tricked into believing them.

Verification is a different thing than a "blue check". I might be against blue checks, but for sure I'm for anyone being able to hand out verifications. It creates a web of trust, and ideally one can choose who they trust and how many transitive levels.

There was once Handshake, but they failed mainly because they didn't want to work along side the current system, they wanted to replace it completely with a blockchain. It's actually one of the good use case IMHO, but their leadership didn't want to play nice with what we already have so transition could happen smoothly

What is appropriate here really depends on what properties BlueSky wants to assert about it's ecosystem.

> What was the problem with the current DNS system? I definitely think there could be improvements like displaying domain instead of TLD but still.

As commenters earlier in this thread have noted, one property BlueSky claims it wants to develop/maintain is resistance against BlueSky itself becoming an adversarial party--say in the event it is bought out by an eccentric multi-billionaire who may take steps to discredit certain parties or reduce their reach or reputation.

I don't think the current DNS verification methodology helps or hurts in a BlueSky is hostile scenario. I think the only issues with the current DNS username verification system as I understand it are the same issues with any DNS based verification system in that vanilla DNS was not a protocol designed to be resistant to adversarial use and as a result there are many ways for people to tamper with DNS records, DNS queries, and confuse systems that incorrectly trust DNS records to be trustworthy or well-formed. DNS cache poisoning is a thing. Domain takeovers have and will continue to happen.

Now, if we're talking about what technologies are suitable for username verification in a word where BlueSky is adversarial, we have a very different conversation. I think the scope of such a scenario extends a lot further than usernames. If your primary interface into the AT Protocol feed is the BlueSky website or the official BlueSky application, you are trusting BlueSky to validate usernames. An adversarial BlueSky could easily decide if your interface marks someone as trusted or untrusted without your knowledge.

The only way I could think to avoid this would be to use a different interface to the global feed, but then you run into new problems that are more difficult to avoid: the fact that most BlueSky users don't host their own data (though this is doable with https://atproto.com/guides/self-hosting). BlueSky also manages the global feed, so barring a competitive global index, you'll still be consuming a feed curated by BlueSky's AT Protocol services and implementation.

I'd close this by saying I am _not_ an expert in the AT Protocol, BlueSky's systems, or this space in general. This is a very fast and loose risk assessment I made after reviewing the AT Protocol and a bit of research on how BlueSky says it provides it's services. My current assessment is that if the community wants to be robust against BlueSky becoming adversarial, there needs to be a lot more support for self-hosting of PSPs and similar data stores, alternative global indexes, and likely also independent governance of the AT Protocol itself.

It's no more than any client only showing the information it wants to; anyone can verify anyone else, without permission from the company. Any client can surface this information in any way they'd like, without permission from the company.

There are also labelers emerging to hide, mute, or block verified accounts... for those who are really zealous against the concept