I would have liked to have seen a justification for this as well. One thing about labels is that they can apply on a per-post granularity as well as a per-account granularity, but verification is purely account-level. Another is that they have slightly different semantics, you can lose your blue check if you change your handle or display name, but labels stay the same no matter what. That's probably the real justification for making it its own feature.
Both of those things sound like all the more reason why labels should've been the preferred approach here:
> they can apply on a per-post granularity as well as a per-account granularity
I might want my verification to apply on a per-post granularity. For example: if I'm speaking on behalf of my employer, then my post should reflect that, whereas my usual shitposting and pet projects probably should not reflect that. Currently the only solution there is to have entirely separate accounts (which might not be unreasonable even with post-level verification, but still).
I'm also left wondering about the temporal aspects of verification. My employer might verify me as one of their employees now, but not necessarily a year from now. Per-post verification would reflect that I was authorized to speak on my employer's behalf at the time I made posts to that effect, without retroactively implying that for posts I made before I worked for that employer, and without that verification needing revoked for those posts after I stop working for that employer.
This is all admittedly a long ways off from what Bluesky probably intends with its new verification feature, but I guess what I'm getting at is that if labels can already do per-account and per-post granularity then having a second kind of label that's only per-account and doesn't offer anything that normal labels can't already do doesn't seem all that valuable.
> you can lose your blue check if you change your handle or display name, but labels stay the same no matter what.
That seems reasonable (but IMO questionably necessary) for handle changes, but rather unreasonable for display name changes.
> Both of those things sound like all the more reason why labels should've been the preferred approach here
Sure, what I'm trying to describe is the various differences so we can speculate why they may have made the decisions that they did. "more flexibility is always better" is a valid choice, but it may not be theirs.
> That seems reasonable (but IMO questionably necessary) for handle changes, but rather unreasonable for display name changes.
I call this the "jaboukie problem," and it's effectively necessary for this kind of feature. Jaboukie Young-White is a comedian who, every time Twitter verified him, would change his account to impersonate another, and then make an inflammatory post "as them." The blue check lent legitimacy to this. It was hilarious, don't get me wrong, but it does undermine trust in the feature.
> For example: if I'm speaking on behalf of my employer, then my post should reflect that, whereas my usual shitposting and pet projects probably should not reflect that
First of all, verification is about identity, not about on whose behalf you're speaking. These concepts are linked, ie if NYT verifies your identity, that might look like an endorsement. I feel like using verification to communicate information about endorsement is not a good idea. On social media, its significantly more important that if you say you're John Doe, that's who you are than it is for users to know if some org endorses your opinions. The extra effort/risk/friction to also communicate endorsements is not in balance with the extra value.
Besides this, its probably a good idea to keep your shitposting and spokespersoning to separate account
There's no UI to do it. It's not currently intended to be a generalized feature, but because the protocol is, it's forwards compatible with eventually doing that if they decide to.
That's what I'm getting at, though: I'm glad (and already aware) it's straightforward from a protocol level to implement custom verifiers, but if you're having to dig down into the protocol level to implement them then that doesn't sound like they're actually easier to implement than labelers (which is what Paul's implying above).
I'm assuming the New York Times ain't hand-inserting records into their account's PDS, which means they probably have some kind of UI already in place. I also wouldn't be surprised if people already built their own third-party applications to this effect (sounds like deer.social already allows users to specify their own verifiers, and I'd be entirely unsurprised if they extend that to allowing users to verify each other directly, too - if they haven't already done so). Still, that hardly sounds less difficult than the current labeler situation.
