diff options
Diffstat (limited to 'docs/MESHBAY_DESIGN.md')
| -rw-r--r-- | docs/MESHBAY_DESIGN.md | 32 |
1 files changed, 28 insertions, 4 deletions
diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md index ea1dab0..5325ac7 100644 --- a/docs/MESHBAY_DESIGN.md +++ b/docs/MESHBAY_DESIGN.md @@ -569,6 +569,13 @@ application needs no fallback: it holds its identities, keeps the new `M` aside until the hub has accepted the change, and re-seals a node's bundle the next time it connects to it — it records which key sealed each one. Every refresh-token family is revoked. +The command-line client (`account passphrase`) carries each copy as a browser +does — opened under the old `M`, the same keys sealed under the new one, never +its own keys in their place — and sets them back if the hub then refuses. It +keeps the `M` it changed away from, so a copy on a node that was out of reach is +carried at its next connection there; a copy that opens under no `M` it knows is +never rewritten, because it may be sealed under a passphrase set elsewhere and is +then the one the browsers open. **Recovering a lost passphrase** splits into what each key can reach: @@ -3024,9 +3031,9 @@ MSE string) fed to a source buffer, with the node holding one slot per viewer. ### 8.6 The command-line client `meshbay-cli` (`packages/meshbay-cli`) is a member's groups and files from a -terminal: `login`, `logout`, `groups`, `invitations`, `join`, `decline`, +terminal: `login`, `logout`, `account`, `groups`, `invitations`, `join`, `decline`, `leave`, `ls`, `search`, `get`, `stream`, `put`, `rm`, `chat`, `devices`, `trust`, -`browser-access`, `help` (what `--help` prints), and with no argument an interactive two-pane view (Textual) +`browser-access`, `mkdir`, `completion` (bash and PowerShell), `help` (what `--help` prints), and with no argument an interactive two-pane view (Textual) over the same library. It is not an operator tool — a node is administered through `meshbay-node` and its loopback API (§6.7) — and it plays nothing itself: `stream` hands a file to a media player. English only. @@ -3103,7 +3110,24 @@ refusal by the node stops the stream (exit 5); Ctrl+C, or closing the player (§5.4): the node accepts the uploading account's devices and the operator's. The client checks the same rule against the index first (`uploader_id`, and the `role` the join result gives its key) and refuses the whole run, before asking -anything, when one file falls outside it. +anything, when one file falls outside it. `rm -r` takes a folder with all it +holds: the files first, then the folders deepest first, each an empty +`dir_delete` — the node never deletes recursively, and only its operator removes +a folder — so the run is the operator's, a group's root is never in it, and the +one confirmation counts every file and its size. `mkdir` is `dir_create`, which +any member may send where the root is writable; `--parents`, not `-p`, which is +the passphrase in every action. + +**Tab completion** asks `meshbay-cli __complete` for the word under the cursor: +actions, verbs and options from the parser, and remote paths from the hub and +the node for the account this machine remembers. It asks nothing — no +passphrase, no device approval — and opens a node the way that never makes +keys, as a passphrase change's connections do; what a group holds is cached two +minutes, so Tab after Tab is instant. Anything that fails is no candidate. + +The join result names `operator` for a key whose account holds the node-wide +operator row, whatever its row in the group says: the client offers what the +node will accept, and the node still checks every admin operation's signature. **Browser access is the application's setting, kept per machine** (§3.7): `browser-access on` leaves a copy of the identity sealed under `M` on each node @@ -3349,7 +3373,7 @@ each removable root. Entries from unavailable roots are filtered out. ### 9.6 Chat -Messages, threads, attachments, and link previews (§6.5). The composer gates on the +Messages, attachments, and link previews (§6.5). The composer gates on the connection having identified a device (§3.3) and on a writable root existing for attachments; the attachment directory is a single writable folder chosen by the operator, and the paperclip is disabled with a stated reason when it is not usable. |