dandri/simplex-chat
1
0
Fork 0
mirror of https://github.com/simplex-chat/simplex-chat.git synced 2026-09-27 17:58:47 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: state the hidden profile case, do not argue it

Browse Source 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rvc3HbiWBTqbAvRT45G5oX
This commit is contained in:
Alain Brenzikofer
2026-09-14 10:35:47 +00:00
co-authored by Claude Opus 5
parent 933a8cc42d
commit dcefd6ffdd
1 changed files with 9 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/rfcs/2026-09-10-wallet-keys.md
+9 -31
View File
@@ -132,41 +132,19 @@ signed record edit, not a rebinding of keys.
## Hidden profiles
Nothing about profiles is encoded in the derivation, so the wallet holds nothing
that would disclose a hidden profile, unless one of the registered names gives
away the existence of the hidden profile claiming it. Two channels would, and
each needs its own answer.
A reader holding the seed can run the recovery scan: derive the enumerable paths
and ask the registry which names each address owns. That returns every name the
device holds whether or not anything was recorded locally, so keeping no record
does not help. A name that must not surface this way has to sit at a path the
scan cannot enumerate, derived from a secret the device does not store.
A reader holding a list of names comes from the other side: resolve each one and
check whether what it resolves to is a contact address on this device. The path
never enters that check. Only a name resolving to something not identifiable as
one of the device's profiles closes it.
Such a subtree needs no local state. Given the secret the client scans it exactly
as a reader would scan the public one, so the names, their indexes and the path
are recoverable from the secret and stored nowhere, which matters because a
stored index counter would betray that the subtree is in use. The secret must not
be the profile's own passphrase: changing that means unhiding and re-hiding,
which would move the subtree and orphan the names. The cost is that such a name
is not recoverable from the phrase alone, with no checksum and no scan behind it.
The commands would take the secret where they take an index today:
A hidden profile can own a name, and registering it must not give away that the
profile exists. Scanning a seed for the names it owns must not surface such a
name, so it is not derived at the enumerable path but from a secret the user
supplies and the device does not store. The same secret reaches the name again
to manage it.
```
/_wallet secret=<passphrase> the next addresses in that subtree
/_wallet export name <k> secret=<passphrase> one name key's secret in it
/_wallet secret=<secret> the next addresses in that subtree
/_wallet export name <k> secret=<secret> one name key's secret in it
```
Neither is implemented here, and a named parameter can be added without breaking
the existing form, so what has to be settled before the first such name is bought
is the derivation rather than the signature: how a secret maps to path
components, and whether the subtree hangs under purpose `44'` or its own.
Not implemented here. The parameter can be added at any time; the derivation has
to be settled before the first such name is bought.
## Scope