Yes, they are trying to use DIDs, sidetrees, and the w3c stack. Jack is behind it so might not compete too much, but will have good funding. They have a very complex spec with a few mistakes. But most of it is OK, and boils down to typed JSON.
It offers key rotation, which nostr doesnt have. And personal storage which nostr doesnt have either.
Personal storage will be better then keeping stuff on relays, because relays dont have any guarantee to store things.
A relay is just a store and forward server. I don’t see why the concepts from the dwn could be combined with a relay into a single concept.
Agree that #nostr doesn’t have key rotation- that’s something we need to figure out. Unsure if the DID is the right approach. I am leaning toward a trusted #nip05 service that could provide recovery and key history.
Yes, nip05 better than DID, but they have big businesses pitching key management. Marketing is powerful.
DWN is a fairly poor way to do personal storage. But I guess it could be used with nostr.
FAR better to use regular cloud with nip-98, or course. Which is mature, works, and scales.
I think verifiable key history needs to be addressed. I think it can be simply done with an array of {key,nbf,exp} that is signed in the did.json or nostr.json served up by a nip05 server.
I think key rotation (recovery, history) is a higher level service that requires a social component, not just cryptography. My current thinking is baking key rotation into the did:method is a mistake. I think it can be addressed with a trusted nip05 service.
did:method definitely a mistake
All the stuff I’ve seen on key rotation using cryptography means protecting even harder the root key. If that key gets leaked, you’re really screwed over.
Very good point. But there must be a better way. I dont think we'll find it until we try things, though. Like an evolution rather than a one shot answer.
