Seed phrases and multiple identities per radio: a derivation scheme other clients could share

[kNoAPP]

Hi all. I maintain kn0.app, a browser client for MeshCore companion radios. I've added two things to it: a way to back up your radio's identity as a BIP-39 recovery phrase, and a way to derive multiple identities ("personas") from that phrase and switch between them. I searched issues, PRs and discussions here for mnemonic, seed phrase, bip39, sub-identity etc. and found nothing, so I'm assuming nobody has defined this yet.

The problem is that a phrase is only really useful if it restores in more than one client. If every client invents its own scheme, a phrase from one app is useless in another. And once people have minted identities from a phrase, the scheme can't change without orphaning them. So I'd rather ask now while there are very few users than find out later that someone else went a different way.

The full spec with test vectors is here:
https://github.com/kNoAPP/MeshCore-WebAgent/blob/cea83e431a9474bb863f5314dad3104c86b6bc7d/docs/identity-derivation.md

The short version:

Phrase to key. Standard BIP-39 (English wordlist, no passphrase) gives a 64-byte seed. The first 32 bytes go through the same expansion ed25519_create_keypair does, clamp(SHA-512(seed32)), and the 64-byte result is what CMD_IMPORT_PRIVATE_KEY takes. This only works in one direction. The radio stores the expanded key, not the seed, so an identity the radio generated on its own can never be given a phrase afterwards. You have to deliberately generate a new identity from a phrase and import it.

Multiple identities. SLIP-0010 over ed25519, hardened only, on the path m/77698372'/0'/index'. 77698372 is "MESH" as decimal ASCII codes, the same trick BIP-85 uses for its purpose number. Branch 0' is radio identities, 1' is used for a local storage key, and the rest are reserved. Since ed25519 has no non-hardened derivation there's no xpub, so nothing short of the seed can link two of your identities together. I consider that a feature and want to keep it that way.

The skip rule. validatePrivateKey rejects any key whose public key starts with 0x00 or 0xFF (about 2 in 256). When an index lands on one of those it is skipped and the next index is tried. The primary identity has no index to skip to, so a phrase whose primary key is rejected is discarded and a new one is generated. Any other implementation has to do exactly the same or the same phrase gives different identities.

Test vectors. The expansion matches RFC 8032 §7.1 test 1. I've also imported that key on a Heltec V4.3 (companion firmware v1.17.1) and it reported the expected public key. The spec has a full worked example from the abandon ... about phrase down to individual sub-identities, including one that gets skipped.

What I'm hoping for:

• If you maintain a client, would you consider supporting this, or tell me what you'd want changed?
• If the firmware devs have opinions on the purpose number or the path layout, now is the time.
• If there's already a plan for something like this that I missed, point me at it.

The scheme is already live in kn0.app, so changing it now would mean supporting both the old and new path. That's still doable while the user count is tiny, and I'd rather do it than end up with two incompatible schemes.

[kNoAPP]