Nostr uses asymmetric cryptography for practical reasons; the entire system hinges on it. I will assume that this part of the story is already understood. If not, please watch this presentation where I explain it: https://www.youtube.com/watch?v=Tbt3jL1Ms0w.

Because the npub and its associated signatures are so central to Nostr, it is an easy trap to conflate identity and keys. But the problems in doing so are obvious; because losing access, or losing exclusive access to the private key are immediately catastrophic. Another problem of this conflation is the tendency to search for mitigations, or worse, solutions, in the same realm of key-pairs. The result of which is increased complexity while fundamentally not actually solving anything; in the best case you merely delay the rate at which you reach the same type of catastrophe. The catastrophe is the failure of automated formal systems where the set-up is binary in nature: you are safe, until you are completely compromised; the fact that you tied your fate to the conflation of identity and key immediately works against you. In other words, you locked up your identity high in the tower of this magnificent fortress, and when that fortress is inevitably captured you find yourself outside of its gates. What first protected your identity, is now the same thing that prevents you from reclaiming it; your attacker stole your defensive advantage.

My claim here is that the identity is not the key, and for the sake of that argument I will ask you to ignore the obvious issues (especially introduced by the power of modern A.I.’s) in the following example, but rather focus on what I am getting at:

Assume you know me, the way I speak, the references I use, the people I engage with, the sound of my voice, the way I look etc. In other words, you are familiar with my identity.

I could start using a different key-pair for every post that I make; as long as my expression in those posts are quintessentially ‘me’, and I somehow figure out a way to ensure those posts end up in your feed, there is fundamentally no issue. There is the identity, and there is an Npub that that identity uses during a period of time. In other words, you are not actually relying on the Npub to identify me, the Npub is just a practical convenience in the realm of computer based systems. The problem of a compromised private-key is essentially that of the story/movie trope where some evil clone/twin/shapeshifter tries to confuse a third person as to who the authentic of the two is. Robbed of the ability to go off on appearances (i.e. the Npub), the third person has to rely on the identity; they have to rely on the expected behavior in the context of the relationship. In the situation of losing access to the private key, it is like the trope of the princess that finds herself all muddied on the outside of the castle, having to convince the guards she actually belongs on the inside.

In any event, these situations are ultimately resolved based on identity, and not by visible markers used by that identity.

Framed this way, the Npub is merely a tool of convenience, and not the linchpin the entire system rests on. Question is, can we figure out a way in which we can actually swap Npubs as an identity, without having to start over again and again. I think we can.

To summarize all of the above, there are just these three things:

My expression;

My relations;

A technical pointer (the npub) which can be derived from the two above.

Premise 1:

I can convince my relations that a particular pointer/Npub is me; this could be via any means, the fact that I gave them the pointer/Npub away-from-keyboard, or how i communicate, whatever the case may be)

Premise 2a:

The relationship between an identity and a pointer will be consistent most of the time; i.e. people won’t be losing their keys every 5 minutes, things wont get compromised every other day.

Premise 2b:

Within a cluster of relationships, failure in the link between ID and pointer/Npub will only be a marginal phenomenon in a particular moment in time; i.e. it is unlikely a large part of the group all get compromised at the same time.

Conclusion:

Given premise 1, and 2, and 2b;

Any ID-Npub failure can be dealt with/restored within a cluster of relations

To be explicit: because the people in the group can identify the new Npub (premise 1), and because the group itself does not fail (premise 2b), because failure itself is rare (premise 2a).

Additionally:

Premise 3:

''members'' of a group are themselves also parts of other ''groups'', in a manner that ''identity theft'' on a group level is impractical to pull off; i.e. When you try to successfully pretend to be Bob to the outside world, you also have to successfully pretend to be Alice, Carrol and David; in order to successfully pretend to be Alice and Carrol, you also have to successfully pretend to be Alice's other friends John, Hank and Frank and Carrol’s other friends Jan, Piet, Klaas. Etc.

Ergo:

Web of Trust is the only sensible solution to the problem if relating identity and public key.

People will figure out ways to take care of premise 1 that are sensible to their context. This could be anything. Easy ways are when you interact away from keyboard, perhaps because you live in the same house, go to the same school, be in the same soccer-team etc. But even in the digital realm, people interact in various ways, perhaps because you play some computer game online together. The point is that it is not formalized via some abstract standard anywhere. Yes, especially now in a world with A.I. that can trivially mimic voices, appearances, manners of speaking and what not, things in certain situations might be more difficult than we would like them to be. But to be clear, I am not proposing some water-tight solution here, just something that will probably work most of the time in most cases. I also can’t ensure that switching Npubs won’t be without consequence/impact. But it is important to realize that the more significant a target is, the odds are it is harder to ‘attack’ their social network simply by the fact those relationships take things more seriously. Stupid people have been falling for Nigerian prince schemes since the start of the internet, and no fancy A.I. was involved in that; and those same stupid people can be convinced they are chatting with some celebrity that is supposedly in love with them, regardless of how absurd it is. No system, scheme and endless amounts of education can save someone from their own delusions. But can we please agree that saving mankind from their own fallibility is an unreasonable ask to make. And can we also please realize that we use all kinds of systems on a daily basis that probably perform much worse than what I propose here, and the world is still spinning. People lose phone-numbers, email-addresses, living somewhere else and changing address can be a huge hassle and people can even lose their government identity because they are presumed dead. Its a cliché but making perfect the enemy of good is a real tendency in these types of discussions.

As for this portion, I would like to conclude the seeming irony that cryptographic verification is supposed to be our shield against all the A.I. crap, whilst I made this whole argument against formal cryptographic verification is not lost on me. But please note the nuance here; yes your systems (that being your clients) should definitely go off on npubs and verify the signed notes and other stuff that are being transmitted by the relays. I am only arguing that way of doing things creates this broader context of npubs relating to each other; and subsequently this context can be leveraged in those hopefully scarce moments in times where the crypto stuff fails us, and we need to transition in order to continue using the crypto stuff.

Ok, but how? Obviously there is the concrete technical side of things. Shouting ‘Web Of Trust’! won’t get us anywhere. That subject is its own hole can of worms. But I have a concrete proposal.

In general WoT looks at interactions between npubs, it’s an analysis that of behavior expressed posts, mentions, reactions, follows etc. and through inter-connectivity in associations you can start to make sense of things. This already happens at places within the Nostr ecosystem and for various reasons. Essentially those reasons boil down to ‘relevance’, and has many aspects to it that I won’t go into right now. Reason being that relevance by itself entails an entire paradigm shift in moving away from central platforms concerning things like follow-counts, the illusion of ‘Global’ and what not. My proposal initially is not about those things, it is primarily about the subject of the relationship between identity and npub.

My idea is to add a thing, which could serve as a relatively simple efficient abstraction of these associations into single events. So instead of for example trying to look for mutual follows (bob follows Alice; Alice follows Bob, so we infer association of some kind) , Bob and Alice create a musig signature event together, representing an abstract handshake. This can be done between two or more people. To clarify, Musig is a technique where multiple key-pairs can produce one signature under one pubkey, effectively creating a new identity that verifiably consists of all the participating identities. Yes, I am aware I just wrote an entire piece on how keys are not identities, but this stuff is complicated as it is, you can apply that caveat yourself. Imagine a boy-band, where they post their music, using a musig, consisting of all the members of the group. Musig already exists for Nostr, but other than a rough implementation in NAK where the whole signing procedure has to be done manually, I am not aware of it being used anywhere.

Using this Musig technique, "association" is abstracted into easily traceable compact data. Association here is explicit, the signature is a direct result of a coordinated conscious action among the participants. It is easy to trace because this musig interaction creates its own specific Npub relating to the combination of the two or more participating Npubs. And it is compact because one single event represents the association between two or more people. This is in contrast to for example looking at mutual follows, where for each Npub you need to include an additional follow-list in the analyses to compare.

The reason why people associate is not important. It does not matter that someone decided to associate in this way because they live together, or because they play Call of Duty online every Thursday evening; the only thing that matters is that they decided to associate, and explicitly declare the social context of their identity.

The idea is to put expiration dates on these handshake events. This way signals 'die out' the moment association stops between Npubs. By ‘signal’ I mean the fact that a cluster of associations has its own Npub that you (or well, your client rather) can follow. By including an expiration date you have an explicit expectation as to when at the very least you expect a new handshake. If such an update does not occur, the association is over and that fact becomes immediately apparent.

A signal dying out is cause to look for other association events. The fact that no association updates occur might be simply because they stopped playing Call of Duty with that particular set of people and one of them dropped out. In that case, a new association Npub, with roughly the same participating Npubs will emerge, and that one can be followed from there on out. But the interesting case for us here is when a key gets compromised.

The nice thing about these Musig association events, is that all parties involved engage in (hopefully) deliberate (hopefully) conscious action. This means:

If you lose access to your keys, no update can be produced;

If your keys get compromised, odds are no updates will be produced because the others won’t engage with that npub any longer. This is because it is Thursday evening, and you show up under a new Npub and are able to identify yourself to the group just fine based on the fact that they know YOU as an identity, and not just you as an Npub. Meanwhile, the attacker might control your Npub, but is unlikely to effectively identify himself as you to this group. This is the evil twin/clone/shapeshifter scenario I described earlier. The story is similar when you lost your keys, but then its the locked out princess scenario. Either way, the result is that the association event won’t get updated, right then and there. At the same time, a new musig Npub and subsequent association event will be created that now includes your newly acquired Npub.

As an outsider, this looks as follows:

You follow Bob. Bob has an association event with Alice, Carrol and David. Now you may or may not be aware that Alice, Bob, Carrol and David play Call of Duty every Thursday evening, and that that is the basis for their association, but that does not matter. All you care about is that they associate, and with followings Bob’s Npub, you also decide to follow this association Npub, along with all the other associations Bob is involved with.

At some point, while expecting updates on these associations, you notice you are not getting any. Perhaps you try a bit harder, but to no avail. You decide to take a look over at Alice, of which you know was part of one of Bob’s associations. You find that among all the associations Alice is involved with, a new association popped up that just so happens to include the same Carrol and David you know from Bob’s association events. Interestingly, this new association also includes a Bob, but whilst everyone’s Npub is the same, this Bob is using an Npub you have not seen before.

Now if this is only the case for this particular association, it is perhaps a bit curious, but when you check more of Bob’s former associates, and you start to see the same thing where there is this new, same Npub, claiming to be Bob, among all these associations, it might be fair to conclude that Bob, for whatever reason, migrated to this new Npub.

And there you have it, a means of leveraging social context, to infer the relationship between identity and key. Sure this type of analyses is non-trivial, but please note that you are not required to do an analyses of hundreds of various types of events, be they follows, reactions, likes etc. in order to do cross-referencing among them, whilst at the same time taking into account that part of that dataset might be heavily polluted by the attacker that compromised the key in the first place. You have to be somewhat aware that its not guaranteed that 100% of these associations are foolproof 100% of the time. But it is important to note that whilst it’s Bob’s responsibility to pick trustworthy associations, it is also Bob explicitly telling you what are the trustworthy associations. If you were simply going off on reactions and likes and follows and what not, you don’t even know what portion of that stuff is even useful to begin with. At the same time, the amounts of data that you are using to perform your analysis is greatly reduced to just a handful of events.

What follows is that I am not suggesting to do this with everyone, on the contrary: you are in control of what associations are meaningful in relation to your identity, and you effectively tie your identity to them. This could of course cause problems, but are the system is ultimately subjective and hopefully less catastrophic in nature as ‘objective’ key-based schemes. These associations also don’t have to be merely social, but could also be institutional. The events themselves are just evidence of apparently a conscious decision to interact in a particular moment in time. What leads up to that is up to the participants themselves. Some super fancy procedures for really important people; just the fact your bro joined the voice-chat during the weekly gaming sessions; or because… you live in the same house. How many, and what combination of various associations results in the most robust trust-network to fall back onto, is up to you. It has to, because it is completely context dependent. If it’s my online gamer-nym, and I don’t want it to be easily tied to my ‘real’ identity, I have to go about it in a different way, than if I can just simply leverage daily life AFK contacts.

Bottom-line is that 'you' whatever ‘identity’ that may be, are defined by what you do as much as who you associate with; and what Npub you’re using is expressed in both, and may change over time. I posit that with this, we have a method of keeping track of that.

Nostr.

*Ceterum censeo NIP-03 omnibus esse utendum *

PS:  am fairly convinced of all this myself, but above all, this is a starting point for discussion. Online identity is a hard problem, and there are no easy answers. Still, together we must come up with viable alternatives to the centralized systems we use today, which are becoming increasingly problematic.