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.

  > old links break to my posts

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

> Do they? I didn't observe any breaks when I did my DNS verification.

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

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.

Yep, I'd love to see it, and you're right that it is.

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.