From bf5b9d5af4e34fc4b5985fc94dbc37395d5eb51d Mon Sep 17 00:00:00 2001 From: Alain Brenzikofer Date: Fri, 11 Sep 2026 07:16:20 +0000 Subject: [PATCH] docs: the wallet is not only for names The seed, the accounts and the derivation are a wallet. Owning a name is the first thing it is used for, not what it is, and the title and the problem it solves now say so. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Rvc3HbiWBTqbAvRT45G5oX --- ...ship-keys.md => 2026-09-10-wallet-keys.md} | 20 ++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) rename docs/rfcs/{2026-09-10-name-ownership-keys.md => 2026-09-10-wallet-keys.md} (89%) diff --git a/docs/rfcs/2026-09-10-name-ownership-keys.md b/docs/rfcs/2026-09-10-wallet-keys.md similarity index 89% rename from docs/rfcs/2026-09-10-name-ownership-keys.md rename to docs/rfcs/2026-09-10-wallet-keys.md index 7f9df0daae..cc5bd1c671 100644 --- a/docs/rfcs/2026-09-10-name-ownership-keys.md +++ b/docs/rfcs/2026-09-10-wallet-keys.md @@ -1,13 +1,15 @@ -# Keys that own names +# Wallet keys ## Problem -A name bought in the app has to be owned by an address, and the client has to -derive that address again after a restart, after a database restore, or on a new -device. Otherwise the name is lost with the device. +The client needs keys of its own, outside the messaging protocol, at addresses +it can derive again after a restart, after a database restore, or on a new +device. Otherwise whatever an address holds is lost with the device. -Buying is not here. The key lands first, so the key material can be reviewed on -its own, before the names protocol, the registrar and signing. +The first of those is name ownership: a name bought in the app is owned by one +of these addresses. Buying is not here. The keys land first, so the key material +can be reviewed on its own, before the names protocol, the registrar and +signing. ## Design @@ -51,9 +53,9 @@ purpose `44'` is used here. The plan is one meta address per profile: a spend key and a viewing key, whose public halves are published with the chat profile, opt-in. A sender derives a fresh destination from it without a handshake, so one meta address serves any -number of names received that way, and those keys are not at a derivation path. -That is why it belongs at the profile level, while the names a profile buys sit -at the address level. +number of incoming destinations, and those keys are not at a derivation path. +That is why it belongs at the profile level, while what a profile buys sits at +the address level. ## Commands