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