meshbay.git/docs/MESHBAY_NODE_PROTOCOL.md, branch 0.19

fix(node): name members admitted without an invitation name

2026-10-07T20:20:45Z

A member who joined by link, by a new device or into an open group was pinned in the roster with no name, so the audit log showed only the first characters of their id. The hub's MNP token now carries the account's username, and after the handshake the node writes it into the roster for an account whose name is empty. An invitation's name is never overwritten; the name is a label, authority stays on `sub`. Co-Authored-By: Claude Opus 5.5

refactor(mnp): remove ten operator messages no client sent

2026-10-02T08:51:19Z

node_status, node_settings_set, roster_read, denylist_read, denylist_clear, node_reload and the signed gek_rotate, member_unpin, transfer_limits, group_detach leave MNP 6.0; the Node page and the CLI do this work over loopback. Their ops keep their tests, moved to the ops level. Co-Authored-By: Claude Opus 5.5

fix(client): no confirmation dialog for adding a folder or its flags

2026-10-02T08:32:18Z

Removes confirmFolder (addRoot, attachGroup) and the writable confirmation added in e4f6177, with their two catalogue keys. Co-Authored-By: Claude Opus 5.5

feat(mnp): sharing a folder is decided on the node's machine only (MNP 6.0)

2026-10-02T08:20:09Z

root_add, root_update and group_attach leave MNP: adding a directory and switching writable/removable go through the loopback API (native dialog in the desktop app) or the CLI. The operator's Settings tab still lists the roots from any browser, read-only. The desktop app refuses to sign those ops; a loopback flag change now reaches open pages (publish_roots). Co-Authored-By: Claude Opus 5.5

fix: an MBK2 bundle is opened once and stored again as MBK3

2026-10-01T11:06:32Z

Transitional. The Argon2 run that makes M makes A, the key MBK2 bundles were sealed under; a session keeps it as a decrypt-only key (IndexedDB in a browser, the key storage in the desktop app). A client meeting an MBK2 bundle opens it — or its recovery copy — and stores the same identity as MBK3 once connected; the desktop app reseals or withdraws it as browser access says. A session without A asks for the passphrase once. Older formats stay refused by name. Replaces the unpin-and-reinvite step the 0.17 flag day required on every node. Co-Authored-By: Claude Opus 5.5

fix(node): one member holds a share of the node, sized past real use

2026-10-01T08:34:26Z

128 peer sessions on the node, at most 64 per account (the hub names the account with each offer; the node's own account is not counted). One account plays at most half the stream slots, rounded up, and runs two subtitle extractions at once. Frames after the handshake are 8 MiB (was 64), decoded with per-container bounds, and a frame refused for either ends the session instead of jamming its buffer (F-16). Sized for the heaviest real member: twenty groups on one node, three devices and a tab, up to 52 sessions. Measured: ~0.15 MiB and one fd per idle session. Co-Authored-By: Claude Opus 5.5

docs: state the pepper's proof, signing by kind and device retirement as they are

2026-09-30T19:04:39Z

Co-Authored-By: Claude Opus 5.5

docs: state the pepper, MBK3, the desktop keyring and browser access as they are

2026-09-30T15:26:59Z

Design §2.2-§3.7, §4, §5.6, §7.7, §8, §9.10 and the registers; protocol §7, §7.1, §7.1a and §13; the user guide; CLAUDE.md's parity rule. Co-Authored-By: Claude Opus 5.5

docs: state hosting, invitations, the roster check and link previews as they are

2026-09-30T10:00:58Z

Present-tense statements of what holds, in place of before/after phrasing: host designation (§7.2, AV32), invitations (§3.4, §7.3, AV33), the roster check at the handshake (§5.2, protocol §6.3), the wrong-code lock (protocol §8.3), and what the link-preview gate does and does not refuse (§6.5). Co-Authored-By: Claude Opus 5.5

fix(node): the roster, not the key alone, decides who gets a session

2026-09-30T09:57:03Z

The handshake opened a session for anyone holding the group key with a hub token naming the group; the roster was consulted only when wrapping the key in a join. A member revoked or unpinned on the node but still a member on the hub kept a full session with the key they already held — and was handed the chat epoch their removal had just opened, since chat keys go to any session. An honest client never met this (it asks for the key through join_request every time); one that kept the key did not have to. - After the proof, the node asks the roster and refuses with `not_authorized_for_group` unless the account is an active member of the group or the node's operator. - A removal from any door — MNP, the node page, the CLI — now opens a new chat epoch in each group the person could read, broadcasts it, and closes every connection they hold (`ops.members._after_removal`). The CLI and the node page did neither. - Design §5.2, protocol §6.1, §6.3, §14.2. Co-Authored-By: Claude Opus 5.5