I plan to use badges, but this is about synergy between platforms and users ability to have varied identities for purpose. Not everybody wants their gamer tag to be the same as their public posting identity, and these will already be using the nip ā 05 identifiers which have an entire ecosystem of verification and code written to handle them, since the users will be registering a wouldnāt it be good to allow them to utilize that more effectively in the ecosystem. We want to enable more platforms to adopt Noster and embracing varied used cases will help enable that adoption. We want to use standard identifier that are already embraced by users on NOSTR and just extend that capability to be more adaptive for the users and the platforms that offer registration that ties directly to their NPUB.
Discussion
if you don't want your gamertag to be your public identity, then nostr addresses don't solve that. the identiy is still the same. nostr addresse are just human readble formats of the same identity.
if you're a dick in a video game, i can lookup your nostr address and get your public key. an alias doesn't solve that. a different public key does though.
It is not about anonymity, but division of identity. On Xbox live or psn, you may not want to be Derek Ross, might be bigrossman or w/e. But you may want to be discoverable and verified as both, using the same npub.
My goal is to enable more use cases and adoption.
Basically it would you rather the user be able to use both your service to register and my service to register rather than have to pick one because they both offer different things to the user and with seamless integration via aliases they can pick which one is displayed as their primary identify action on most based portals
That is a fair point, but . . .
It also brings up the key issue about . . . well, keys. It is frictionless to spin up another keypair. Is is NOT frictionless (in most cases) to get a nip-05 from a respected, established, trusted domain/relay/whatever. Sure, you can just abuse the nip-05 services like the spambots do, but, if you note . . . they all come from the same core domains, which . . . would be handy to have to block domains entirely, and I don't see a good way to do that at a lower level that some clients (very poorly implemented) block/mute lists.