feat(node): meshbay-node group add — host another of your groups

Attaching a group to a node meant hand-editing node.toml with a UUID
copied from a browser URL, restarting, and knowing that gek-init exists.
Nothing in the CLI said so, and on a node reached over SSH there is no
paste buffer to carry a UUID across in the first place.

    meshbay-node group add grenet --dir ~/grenet-share

The name is resolved against the operator's groups on the hub by the
daemon, which is the process holding the session. The [[groups]] block is
appended to node.toml as text rather than round-tripped through a TOML
writer: the file is hand-written and its comments explain decisions worth
keeping. The directory is created, and the command says what remains —
restart, then gek-init for that group.

It refuses a name it cannot find by printing the groups it can, with
their ids. That listing is the useful half of the answer and it was
missing everywhere: _daemon_api now renders an `available` list from any
endpoint that offers one.

The key is per group and pairing is not, which is the part that reads as
a gap until it is written down: one paired browser covers every group the
node hosts, while each group's key admits only its own members. §4 of the
user guide now says all three of those in one place.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 34 insertions, 0 deletions

diff --git a/docs/USERGUIDE.md b/docs/USERGUIDE.md
index 8a1e405..e2193f0 100644
--- a/docs/USERGUIDE.md
+++ b/docs/USERGUIDE.md
@@ -373,6 +373,40 @@ argon2_memory_cost  = 262144  # 256 MB
 argon2_parallelism  = 1
 ```
 
+### Hosting another of your groups
+
+A node can host several groups, each with its own directory and its own key.
+Create the group in the web app first, then, on the node:
+
+```bash
+meshbay-node group add grenet --dir ~/grenet-share
+# grenet (480d553f) added to /home/cbesson/.config/meshbay/node.toml
+#   shared_dir   /home/cbesson/grenet-share
+
+# restart the daemon, then:
+meshbay-node gek-init --group grenet
+```
+
+`group add` looks the name up among your groups on the hub, appends a
+`[[groups]]` block to your `node.toml` — comments and all, it is appended, not
+rewritten — and creates the directory. The daemon reads its config at startup, so
+it needs a restart before the group exists for it; `gek-init` then generates that
+group's key.
+
+Three things follow from the design, and are worth being explicit about:
+
+- **Each group's key is its own.** Members of one group cannot read another's
+  files, and admitting someone to one says nothing about the other. That is why
+  `gek-init` is per group.
+- **Pairing is not.** `meshbay-node operator pair` pairs a *browser* with the
+  *node*: one paired browser can invite to, and delete files in, every group the
+  node hosts. It takes no `--group`.
+- **Members are per group.** `meshbay-node member invite alice --group grenet`
+  admits alice to that group only. The roster keeps one row per group.
+
+`meshbay-node status` prints what the node hosts, with each directory — the
+quickest way to see whether a group made in the browser is attached here yet.
+
 ### Environment variables (alternative to node.toml)
 
 | Variable | Equivalent config |