3 ms·
> 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 ch
by steveklabnik 2y ago
> 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.
- 9283409232 2y agoI 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.
- steveklabnik 2y agoRight 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.
- godelski 2y ago> 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...)
- steveklabnik 2y ago> 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 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/3lndppxy7xc2a https://bsky.app/profile/steveklabniklol.com/post/3lndppxy7x... See here for more: https://github.com/bluesky-social/social-app/issues/1221 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.
- godelski 2y ago> 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.
- steveklabnik 2y agoYou'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.
- yellowapple 2y agoThis 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.
- steveklabnik 2y agoYep, 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.