We need a way to reflect that human "social trust" is born distributed, and centralising trust subverts it. But here, while they introduce third party verifiers, rather than individuals deciding which verifiers to trust, bsky is going to bless some. So this is just centralised trust with delegation.
What's missing from the blog announcement is that on the at protocol, anyone can publish a verification of any account. It is then up to each client to decide which verifiers to display / trust / etc.
With that in mind, it seems like bluesky is trying to thread the needle on providing tools for the community to do their own verification (via the protocol) while also making their own client "notable user" friendly (via blessed verifications that show blue checks).
I also don't see why it wouldn't be possible for someone to build a labeler that shows verifications from non-bluesky blessed sources. Then community members could subscribe to that labeler to get non-blessed verifications that they choose to show. It wouldn't show up as a blue check but it would still show up on the user's profile in bluesky.
It would look something like this existing "verification" labeler that doesn't use the underlying verification feature on the protocol but instead has to maintain the data in a 3rd party store: https://imgur.com/a/tXR4FUu
Additionally, third-party clients like Pinksky or Skylight could choose to show blue checks or whatever UI for any verifiers they choose. All the data is on the protocol now, so the 3rd party clients wouldn't need to do the verification themselves.
Human social trust works great at small scale. You go to Jim the butcher because everybody you know in town regularly goes to Jim the butcher and they know he's been making meat pretty well for a long time.
An automated version of this system might say "we verify anybody who at least N people within 3-4 steps of your followers graph are also following."
In a big city, you go to the store that's labeled "Butcher" and figure that, because the building is quite permanent and there's a lot of butchery stuff in there and it seems clean and there are people going in and out, then it's probably a fine butcher shop. No real "social" trust involved.
An automated version of this is probably domain checking, follower count, checking that N other 'verified' accounts follow it, some basic "is this a known malicious actor" checks, waiting until the account has some age, etc. Still kind of distributed, but not really relying on your own social trust metrics.
What's fun is that Bluesky allows you to implement both of those mechanisms yourself.
I don't see what the problem was with using domains. If you're trying to claim you work for NYT then get a NYT verified account?
And what ever happened to Keybase? That seemed like a good solution. Verify by public private key? It really seems like that could be extended. I mean we have things like attribute keys and signing keys. It seems like a solvable solution but just the platforms need to create a means for the private bodies to integrate their keys.
Hell, I wish we'd have verification keys for cops and gov employees. So me a badge? No, show me a badge with a key I can scan and verify your identity. It's much harder to forge a badge with a valid key than it is to forge a badge that just looks good enough
> If you're trying to claim you work for NYT then get a NYT verified account?
Part of the problem here is consistent identity over time. People do not like changing their handles unless they want to. I'm steveklabnik.com now, but if I started working at the NYT, and had to switch to steveklabnik.nyt.com, old links break to my posts, etc. And what happens if I want to be verified by more than one org at a time? Domains (at present) can't do that.
Do they? I didn't observe any breaks when I did my DNS verification.
> People do not like changing their handles unless they want to
I don't see it that way. On both twitter and BlueSky there are two handles. I'm sure there's a better term, but let's say "display handle" and "address handle". (On HN they're the same) People are paying attention to the Display Handle and not the address one. Most of the time the address one is even cut off and is partially hidden anyways.[0]
> what happens if I want to be verified by more than one org at a time?
First off, it doesn't seem like Bluesky's implementation will do this so I'm not sure why it is being brought up into this conversation.
Second off, I agree that this is a desirable thing to have. It is why I was suggesting something similar to keybase (keyoxide?) or attribute keys. It definitely seems like Bluesky is intending to do something similar to the attribute keys but there's some details lacking and seems like an existing verified user needs to vet an entity prior to their ability to distribute keys. I'd also be quite happy if there was a publicly visible ledger so one could see former verifications (it's all visible via the firehose anyways, right?).
[0] And there's the classic problem on typing "@" and then the person's name and not actually finding them because the search system is fucked up and is looking for the address handle. I've seen this on both sites, more frequently twitter, and even when typing the address handle directly. Apparently this is a harder problem than I'd have thought (particularly replying to someone in the thread...)
Sounds like this could be solved by redirects? Sure, may get a little confusing if/when someone takes that username after it was abandoned but it seems worth the trade given the implementation. Really it depends on how they're handling the links. I'm not a web person so this may be very naive, but it definitely seems like a solution is that all handle-based links are really just proxies for DID based links. If they're all DID on the backend, then I don't see the problem. You're just building a growing ledger (which is happening anyways and seems like a bigger problem). Of course I'm willing to acknowledge my naivety here and wouldn't be surprised if I'm working with a bad mental model that's leading to poor solutions. If this is a terrible solution I'd appreciate the learning opportunity so I can better understand.
You've got a handle on it, roughly. The issue is exactly when/if someone takes a username. The tension is between links using the did, which wouldn't ever break, and the nice URLs that normal people expect to see. If that didn't exist, they could just always use the DID link and it would be fine.
But regardless of what could be done, I'm just talking about what is the case right now. Which is that they break.
This seems like a perfect use case for `alsoKnownAs` being an array (which is already the case AFAICT). My primary handle (i.e. the first entry in the array) would still be @yellowapple.us, but with secondaries under the domains of affiliated orgs.
I feel like this could be solved with organizations like Github. Steveklabnik.com can belong to the NYT umbrella org. Like on Github, you can either be kicked out or leave the org if you wish.
Right now, while it's possible to have a DID associated with multiple domains, the Bluesky app view only supports the first. Doing something like this could work, but would be a larger lift.
I do agree that multiple domain-based identities would be a nice feature though.
The average user doesn't need verification either.
In fact, I don't think I want most users verified. It then creates a reverse incentive where anonymous accounts are distrusted by default and too much trust is given to verification. An important part of a system with free speech and not governable (the point of distributed) is to be able to freely speak. Sometimes that means hiding your identity. Especially for those in countries or societies with particularly authoritarian rule. The best way to keep people quiet is to make them afraid of their neighbor.
> what should the domain name be for a journalist at the NYT?
Everyone has the bsky.social handle, so you revert. I'd even be happy if optional profiles could show former affiliations. But it doesn't seem like a big problem. I mean NYT shouldn't be verifying a journalist if that journalist is no longer at NYT. Their new employer should.
Are there any good examples of a working "vouch" system? I vouch for a few friends, they vouch others, etc. But if my credibility is revoked, everyone downstream of me is either yanked or needs a new voucher.
A long time ago there was this “web of trust”, I don’t think it exists anymore. Was one of the big CA and you could get different certificates through some form of vouching, I think it even went as far as meeting people to show your ID and then they sign you or something. As it was run by a big CA, not really distributed but IIRC they kept their involvement minimal. It’s been a long time but if you’re curious maybe look into that
Keybases popularity falling off a cliff isn't really surprising, their venture into shitcoinery already put them on thin ice with the anti-cryptocurrency crowd, and then development basically ceased overnight after the Zoom acquisition. I don't know why they're even bothering to keep the lights on, it's been five years of radio silence at this point.
keybase had promise early on but kinda lost the plot. the vouching system was neat in theory but never really caught on outside a small circle. the crypto stuff definitely didn’t help, and once zoom bought them it was basically a ghost town, no roadmap, no real dev activity, just inertia.
feels like identity + trust systems keep coming back around but never quite stick. maybe too hard to balance usability, decentralization, and adoption all at once.
I tend to think the ecosystem is vastly dominated by established solutions. In order for a New Thing to win, it needs to be at least an order of magnitude better and more usable, or the network effect obliterates it.
Could it also be that social media sites depend on commingling “daily active users” vs “number of unique humans” for having high numbers? A web of trust would establish one live person per account, somewhat like Facebook had a policy for.
Keybase was great. The idea behind it (using private key to prove your identity) is the idea behind some of the default methods for the Decentralized Identifier (DID) standard: https://www.w3.org/TR/did-1.0/
You're thinking of the Thawte Web of Trust: https://en.wikipedia.org/wiki/Thawte which was run by Mark Shuttleworth (now of Canonical). The certificates were used for email, not for SSL. I lost track of what happened to it after CACert took over.
There is a p2p social network (as in, people offering there services whatsoever) in France that does exactly this: it's called "Gens de confiance". It works well, although it creates kind of a gated community (as intended: it is mainly meant for upper-class social circles).
My initial thought is about GPG's "Web of Trust" system for trusting strangers' keys. But I don't know if that's a very good example since it always seemed somewhat esoteric and maybe not very successful in general.
"Working" would be a stretch, but this is how "web of trust" systems like PGP are supposed to function. Although I would say the BlueSky system sounds like it could skirt some of the pitfalls of web of trust because verifiers can also be trusted to revoke verification.
Apps on ATProto get to decide for themselves. Another Bluesky client, or a completely different app, can make different choices. Users can then decide which interface they want to use. All part of the design of ATProto
IMO a system of "I vouch for these accounts" and "I trust the accounts these accounts vouch for, and the accounts those vouched for vouch for up to x levels deep" would be a workable solution.
We need a way to reflect that human "social trust" is born distributed, and centralising trust subverts it. But here, while they introduce third party verifiers, rather than individuals deciding which verifiers to trust, bsky is going to bless some. So this is just centralised trust with delegation.