The starting experience with Nostr is, lets be honest, rough.

You learn about the protocol, then you go to nostrapps.com and look through to see if you can find some apps you want to try out, you go to sign up, and it tells you that best practice is to set up a remote signer. Ok, fine, which one to trust? You are making an irrevocable decision about what software you are going to trust your master key to, a wrong decision is catastrophic, lose the key and your identity is gone, if the key is compromised there is no way to regain control, the identity is permanently ruined.

Ok, whatever, you choose eg. to try out NOS2X, and you get an extension that while it works, the UX is frankly garbage tier. Then you finally get to sign up for the thing you wanted to try out to begin with, and then every time you do a new action you have to choose whether you give permanent authorization for 10 different actions one by one, with an explanation that quite frankly doesn't really make it clear what it is, or you can give temporary authorization and it will keep asking you every fucking time you do the thing.

This is one of the reasons I wrote a post about a DID based system, where the UX by comparison to what I just laid out would be:
1. You go to the app you want to try out, it could list a few options for you for identity wallets available on the platform you are currently on.
2. You download the identity wallet, and save your master key somewhere safe, ideally in cold storage, but it could also be inside of Bitwarden or similar password manager. An update key is set up as well and stored in the identity wallet app.
3. You click sign in in the app you want to sign into, and it sends you to something that looks very much like an OAuth authorization page, listing out all the permissions the application is asking for, and if you click "Authorize", a verification key is generated and sent to the app (probably stored in local storage, this key can be revoked at any time to disable the permissions granted to the app). The identity wallet handles all the broadcasting of DID documents etc. automatically.

The starting experience with Nostr is, lets be honest, rough.

You learn about the protocol, then you go to https://nostrapps.com and look through to see if you can find some apps you want to try out, you go to sign up, and it tells you that best practice is to set up a remote signer. Ok, fine, which one to trust? You are making an irrevocable decision about what software you are going to trust your master key to, a wrong decision is catastrophic, lose the key and your identity is gone, if the key is compromised there is no way to regain control, the identity is permanently ruined.

Ok, whatever, you choose eg. to try out NOS2X, and you get an extension that while it works, the UX is frankly garbage tier. Then you finally get to sign up for the thing you wanted to try out to begin with, and then every time you do a new action you have to choose whether you give permanent authorization for 10 different actions one by one, with an explanation that quite frankly doesn't really make it clear what it is, or you can give temporary authorization and it will keep asking you every fucking time you do the thing.

This is one of the reasons I wrote a post about a DID based system, where the UX by comparison to what I just laid out would be:
1. You go to the app you want to try out, it could list a few options for you for identity wallets available on the platform you are currently on.
2. You download the identity wallet, and save your master key somewhere safe, ideally in cold storage, but it could also be inside of Bitwarden or similar password manager. An update key is set up as well and stored in the identity wallet app.
3. You click sign in in the app you want to sign into, and it sends you to something that looks very much like an OAuth authorization page, listing out all the permissions the application is asking for, and if you click "Authorize", a verification key is generated and sent to the app (probably stored in local storage, this key can be revoked at any time to disable the permissions granted to the app). The identity wallet handles all the broadcasting of DID documents etc. automatically.

https://primal.net/e/nevent1qqs8r5xnlaltp4ftwysw53shums2fctrevv4hh6mya9rrs45ya0avuqv7vl9c

I wish Nostr used DIDs, specifically a new DID spec that functions something like this:

Each DID document includes:
- A version number, which the owner increments each time a new version of the DID document is created.
- A master key, where the pubkey acts as the identity. The master private key is intended to live in cold storage, think of it as an "in emergency break glass" key.
- One or more update key(s), that can be rotated by creating a new DID document and signing it with the master key. Update keys have authority to sign new versions of the DID document, changing the list of update keys or verification keys + permission strings. Update private keys are intended to live in an identity wallet on a users device.
- One or more verification key(s), with a string of permissions granted to the key(s). These are intended to be used to grant permissions to applications.
- A version history that lists revoked update keys and verification keys.
- A list of relays the DID document owner uses.

This would grant a bunch of nice properties, such as:
- Ability to revoke update and verification keys in case of compromises.
- Key rotation would not lead to your pubkey/identity changing, which would break eg. mentions in Nostr.
- No need for complex key share handling where you must dispose of shares when rotating keys, and having to have multiple devices on at all times to be able to use Nostr, like would be the case with Frostr which uses a threshold based signature scheme.
- No longer needing to use remote signers as a best practice in all cases, if a verification key is compromised it is a limited amount of damage it can do since permissions are limited to only what you want to give the application ability to do.
- Because the DID documents have to be signed either with a master key or an update key, they can't be changed without invalidating the signature, which makes it easily cryptographically verifiable that a DID document has in fact been signed by the owner.

(Not an exhaustive list, just some highlights).

DID documents would be distributed to DID Directory Relays. The relays would not have any authority over the documents, just like in Nostr today, if a relay blocks you, users can simply find your DID document on a different relay. The DID document can also be sent directly to a user or service without going through a relay. This is fundamentally different than eg. AT Protocol that relies on the centralized PLC Directory for distribution of DID documents.