Keybase got acquired back in 2020 and it's popularity -- at least among cypherpunks, seems to have dropped off.
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.
There are some good ideas there (and Bluekey uses DIDs: https://atproto.com/specs/did)
Could use follows, retweets, etc instead of page links
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
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.
I do agree that multiple domain-based identities would be a nice feature though.
> old links break to my posts
> People do not like changing their handles unless they want to
> what happens if I want to be verified by more than one org at a time?
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...)
I went to one of my posts and clicked "copy link to post." that gives me an URL like this:
https://bsky.app/profile/steveklabnik.com/post/3lndppxy7xc2a
If I change my account to `steveklabniklol.com`, then this URL wouldn't work, as that url turns into
https://bsky.app/profile/steveklabniklol.com/post/3lndppxy7x...
See here for more: https://github.com/bluesky-social/social-app/issues/1221
> People are paying attention to the Display Handle and not the address one
I agree, and that's why people don't like changing it.
> it doesn't seem like Bluesky's implementation will do this
It does.
> I went to one of my posts
But regardless of what could be done, I'm just talking about what is the case right now. Which is that they break.
I think that doing this raises a lot of product questions, so I'm not shocked they haven't done it. But I'd like it if they would.
They got acquired by Zoom and promptly put Keybase into maintenance mode.
DNS for your average user is too complicated. Also what should the domain name be for a journalist at the NYT? What if they leave the NYT?
> DNS for your average user is too complicated.
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?
> What if they leave 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.
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.
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.
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.