Proxy identities

[Evanfeenstra]

New proxy submodule for logic to create and manage virtual identities. You can have multiple virtual ids on a single hardware

• pluggable persister (SD card on ESP32) for a keystore. Only the "node id" key is needed (for signing invoices, signing arbitrary data, and decrypting onion blob)
• ESP32 will need to also store the onion blob to pass to the phone (re-encrypted of course)
• Phone needs to be able to plug into this as well
• This way a "lite" user can decrypt everything on the phone and send nothing back to relay (does not need relay at all). Contacts and Chats table will be completely client-side, and Sphinx will have no metadata about a user

[Evanfeenstra]

R+D question... should this inherit the policy + velocity settings from VLS?

[Evanfeenstra]

I think this RPC is what we can use to avoid revealing the contents of the TLV to the server https://docs.corelightning.org/reference/lightning-sendonionmessage

we need to use LDK to create the onion fully on the client side

[Evanfeenstra]

Receiving:

• mailbox stores incoming onion blobs from htlc interceptor (and "forward amount")... if client is not online, payment fails, sender retries to the "root" key (without the TLV). The mailbox now has the sats and the onion.
• when user comes online, they can fetch the onion and sats.
• new pubkey/routehint for each tribe/contact you have (like simpleX - no "user id")
• no "contact key" needed (drop all RSA encryption)

Sending:

• app calls "queryroute", and constructs the onion client-side (with Rust lib)
• submits raw onion to CLN

Apps will need to totally refactor: no connection to relay for "lite" users. Instead cross-compiled rust lib to construct onions from route + sphinx TLV fields

[irriden]

A couple of relevant links, from a convo with Ken:

https://github.com/lightningd/plugins/tree/master/noise

https://github.com/ElementsProject/lightning/issues/6578