[shrink]

I built handles.net[1] to make it easy for organisations to manage their member's handles, I think that using domain names for identity is neat and valuable, I have a vested interest in its success as a paradigm but... domain name "verification" is not the right solution today for non-technical people. I shared this sentiment a few months ago[2] and I have only become more confident in that assessment since.

The approach they've taken ("trusted verifiers") is an approach aligned with their values, as it is an extension of the labelling concept that is already well established in the ecosystem. As an idealist, it is a shame that they gave up, I think they could have had an impact on shifting how non-technical people view domain names and understand digital identity... but as a pragmatist, this is the right choice. Bluesky has to pick their battles, and this isn't a hill to die on.

[1] https://handles.net [2] https://news.ycombinator.com/item?id=42749786

[yellowapple]

> The approach they've taken ("trusted verifiers") is an approach aligned with their values, as it is an extension of the labelling concept that is already well established in the ecosystem.

That just leaves me wondering why they bothered with a new separate system instead of just using the existing label system. A "verified by bsky.social" or "verified by nyt.com" or whatever label would do the job perfectly well, no?

[steveklabnik]

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.

[yellowapple]

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.

[steveklabnik]

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

[NoahZuniga]

> 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

[pfraze]

At this stage, labelers still require a fair amount of work to setup and operate. We didnt want it to be difficult for people to issue verifications

[yellowapple]

So what's the process for people to issue verifications? Where is that documented?

[steveklabnik]

You create a record in your PDS. Here's the people I've 'verified' for example: https://pdsls.dev/at://did:plc:3danwc67lo7obz2fmdg6jxcr/app....

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.

[yellowapple]

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.

[steveklabnik]

That's a good reason too!

[mozzius]

also, it's nice that verifications are easily enumerable, unlike labels

[adityavinodh]

Yeah my initial reaction was not too positive. There's something weird to me about simply delegating verification to a third party organization. I'd prefer a more pure solution. Maybe we don't have a solution yet that is simple enough for widespread adoption. The domain based identity does seem a bit too complicated for the average user.

[Retr0id]

> it is a shame that they gave up

They didn't really give up, though - the domain verification still stands and is just as powerful as ever.