rns.recipes

A good question that came up on Limbernode (5585e0763c3cafc65625078ee1b28f3f):

Lately I've been thinking more about the lifecycles of identities and about how to optionally establish chains of trust between different entities. there's no way to "burn" a compromised identity at the moment.

Thinking out loud:
One could use a root identity to create and revoke one's identities, stored securely offline on a hardware security key or paper/metal/etc. To revoke an identity, a special revocation announce could be emitted, signed by the root identity (which must never be compromised obviously), making transport nodes mark the identity as revoked and act accordingly.

Drawbacks:
It would reduce the overall capacity of transport nodes, as they would have to store the root identity's public key for all the identities it knows about. They would also have to remember all revoked identities forever.

Disclaimer:
I'm a crypto noob. This may be a horrible idea for other reasons.

I've been working towards this kind of functionality for some time. There's been a lot of low-level infrastructure that's needed updating and expansion to support this reliably and robustly.

• One of the main goals of the recent complete rewrite of rnid was to provide some of the required building blocks for this.
• The new rsg signature format supports metadata inclusion and cross-signed identity attestations, also a required piece of the puzzle.
• The new rsm signed message format allows self-contained identity inclusion and message signing, and can also include attestation data, and will form part of the mechanism for cross-identity attestations.
• Also, the recent revamp of the identity and known destination data storage and cleanup handling was an important part of the puzzle. Identities and announce data can now be retained if needed locally on a system, and unneeded data will be cleaned faster, allowing identity data to be cached and queried in a much more distributed manner.
• I'm currently working on another important part of this system, the ability to (optionally) include stamps on identites, and using these in core parts of the API, such as link identification.
• After that, the full offline identity import/export scaffolding and functionality has to be set up and integrated.
• After that, the new rns.id destination type functionality has to be completed and integrated in rnid and as API functions, so the network and users can store, query and deploy identity information, both offline and on-network.
• There's still a lot of bits and pieces needed to tie all this together, but we're getting there steadily.

It's the kind of work where I'm taking everything in a very measured, deliberate and calm pace. There's many "invisible" pieces that needs to be put into correct alignment, and you can see traces of that all over the codebase recently, but it will be a little bit yet before it can all be tied together into the final, usable form.

One of the key points to think about here is that not all transport nodes need to store all identity information, attestations and revocations for all users all the time.

With what I'm working towards, you basically only need to store the information for the identities you care about yourself, and when you need information about a new identity, it can be queried from the network, if anyone has it.

If you care about having particular identity information available to the network, you can make your own instance deploy it periodically, or just when you're using a particular application tied to that identity anyway, and let the network cache it in the meantime.

That's good to hear! Lots to digest here. Wise choice to move slowly with this.