Add owner-rooted node management

README.md

@@ -27,13 +27,17 @@ registry, module router, local metadata store, and synchronized data structures.
 Most non-daemon commands talk to the daemon through a local Unix socket at
 `$GETH_HOME/run/geth.sock`.
 
-`geth keychain init --admin-key <public-key> --signing-key <private-key>` records
-the keychain initialization/admin-key operations and signs their canonical
-payloads through `ssh-keygen -Y sign` using the
+`geth init --admin-key <public-key> --signing-key <private-key> --node-name
+<name>` records an owner/admin keychain, the local user/device/node binding, and
+signs canonical keychain payloads through `ssh-keygen -Y sign` using the
 `geth.keychain.v1@geth.local` namespace. This is the bootstrap path for
-admin/YubiKey-rooted trust. `geth keychain status` reports the number of stored
-keychain signatures plus how many currently verify with OpenSSH; rejecting
-unsigned or invalid replicated keychain ops is still future work.
+admin/YubiKey-rooted trust. `geth keychain sync <node>` pulls the signed
+keychain operation log from an imported peer and imports only operations with
+valid OpenSSH signatures from currently trusted admin keys. `geth node list`
+shows the active reduced node view, and `geth node rename/revoke` require
+`--signing-key` so device-management changes can replicate as verified admin
+statements. `geth node grant/revoke-grant` records the current resource-scoped
+capability prototype.
 SSH certificate-flow and revocation records carry agent-key signed provenance
 over canonical payloads, and sync import rejects new unsigned or invalidly
 signed records.
@@ -82,10 +86,16 @@ metadata from an authorized peer over Iroh.
 The bootstrap implementation provides:
 
 - `geth init`
+- `geth init --admin-key <public-key> --signing-key <private-key> --node-name <name>`
 - `geth daemon run`
 - `geth daemon service install|uninstall|start|stop|status|print`
 - `geth status`
 - `geth node id`
+- `geth node list`
+- `geth node rename <node-or-name> <name> --signing-key <private-key>`
+- `geth node revoke <node-or-name> --signing-key <private-key>`
+- `geth node grant <node-or-name> <resource> <capability> [--grant-id <id>]`
+- `geth node revoke-grant <resource> <grant-id>`
 - `geth peer export [--out <path>]`
 - `geth peer import <path>`
 - `geth peer list`
@@ -95,6 +105,7 @@ The bootstrap implementation provides:
 - `geth resource create <kind> <name>`
 - `geth keychain init [--admin-key <path>] [--signing-key <path>]`
 - `geth keychain status`
+- `geth keychain sync <node-id-or-name>`
 - `geth secret status`
 - `geth secret create <resource>`
 - `geth secret rotate <resource>`
@@ -327,6 +338,40 @@ cargo run -p geth -- cas add /tmp/hello-geth.txt
 cargo run -p geth -- cas list
 ```
 
+## Owner And Node Management
+
+The intended owner setup is SSH-admin-rooted:
+
+```sh
+geth init \
+  --admin-key ~/.ssh/id_ed25519_sk.pub \
+  --signing-key ~/.ssh/id_ed25519_sk \
+  --node-name laptop \
+  --capability resource:ssh-proxy:local=ssh_proxy.admin_shell
+```
+
+When any owner setup option is used, both `--admin-key` and `--signing-key` are
+required. This prevents accidentally creating an unsigned owner/device/node
+statement that cannot be accepted by another node during keychain sync.
+
+This records signed keychain operations for `KeychainInit`, `AdminKeyAdd`,
+`UserAdd`, `DeviceAdd`, `NodeAdd`, and `AgentBind`. The current node identity is
+stable above endpoint rotation: future endpoint bindings should attach to the
+node, not replace it. Node management is done through the reduced keychain view:
+
+```sh
+geth node list
+geth node rename laptop work-laptop --signing-key ~/.ssh/id_ed25519_sk
+geth node grant work-laptop resource:ssh-proxy:local ssh_proxy.connect
+geth node revoke work-laptop --signing-key ~/.ssh/id_ed25519_sk
+```
+
+`geth keychain sync <node>` pulls signed keychain operations from an imported
+peer over Iroh and rejects operations that do not have a valid OpenSSH signature
+from a currently trusted admin key over the canonical keychain payload. This is
+the current replicated device-management substrate. It is still a pull-based
+operation log, not yet a CRDT or Keyhive-style convergent authority.
+
 ## Authorization Direction
 
 The MVP defines the split between: