Once again, I am becoming more confident that #nostr and its signed event model is the right way to go. This time around, the model has helped to clarify the distinction between #identifier and #identity.

We’ve all been guilty of using these terms interchangeably, if not as equivalent. I often refer to my npub as my ‘identity’, the shorthand way of referring to my ‘identifier’. I also think of them as being the same, with the knowledge that my ‘identity’ actually exists outside of any one system.

Now with #nostr, the distinction has been clarified: my ‘identifier’ is my npub (straightforward enough) however my ‘identity’ is my npub PLUS a set of events of events signed by my npub.

At its most rudimentary level, my identity is my npub + a kind 0 event with metadata. What is interesting, my identity can change over time if I sign and publish a new kind 0 event.

As well, my identity might look different to different people - the best example is a signed nip04 event that is encrypted and readable by only one other npub. My identity is different to that one npub as it would be to another npub that does not have access to that nip04 message.

This line of thinking about ‘identity’ opens up a way to rotate npubs (use a different identifier), yet keep the same ‘identity’. A possible approach is to create a new npub that signed in a way to be used next in the chain if the old npub is compromised.

Anyway, just some thoughts on the distinction between ‘identifier’ and ‘identity’ - it’s the addition of signed events.

Reply to this note

Please Login to reply.

Discussion

Yeah, I am working on this too! Have you seen how self sovereign identity (SSI) protocols do it? You need a wallet client that helps you manage all of your identities.

Where my current thinking is - how to replicate key pre-rotation in #nostr. This is the essence of the #keri protocol which you can read all about it at keri.one

Cool, I am doing some with unique key per relationship and credentialing with those keys.

I am pretty sure there is a simple model underneath it all. Just haven’t figure it out yet. I think it’s something like generating a new npub, publish a kind xxxx event that this is the next npub.

Do we have good tools for hierarchical keys in Nostr? I think cold card has something but it is experimental still.

Not sure. We could do something similar to hkd with xpub, but I think the way to go is to publish events that point to the next valid npub. The trick is absolute ordering, so that if the original npub is compromised it can’t trick you to a bogus new npub.

original npub is master xpub? or original in an event? I think if npub gets compromised you would use a prior npub to announce/verify another new npub right?

Yeah, that the idea. The trick is the ordering of npubs so that (n+1) npub can announce that (n) npub is no longer valid. Similarly, someone can determine which events were valid and at which point they are invalid. Likely will require an open timestamp.

wouldn't there be a case where you could announce validity of npub (n) with (n-1) or any prior npub that is still good?

TBH, I haven’t thought it through completely. The question, I believe is specifying the validity period or state of a prior npub with something like “expired”. The problem is that the prior npub, if compromised, could specify a bogus n+1 pub. I think this is an open timestamp-like problem.

I'll check this out!

I was playing around with tbd which is jack Dorsey's project: https://developer.tbd.website/projects/ssi/

I am not sure where that is going TBH (pardon the pun). The leadership is too opinionated for my liking.