diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-10-07 22:12:54 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-10-07 22:20:45 +0200 |
| commit | 462d76898a306981fbeac859cd54da1468e80639 (patch) | |
| tree | 9a49723da751b4a7225e3dd37181ecceed192f3a /docs/MESHBAY_NODE_PROTOCOL.md | |
| parent | 92e6b9823119b5461efc304a81e79e186a928e6d (diff) | |
| download | meshbay-462d76898a306981fbeac859cd54da1468e80639.tar.gz | |
fix(node): name members admitted without an invitation name
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 <noreply@anthropic.com>
Diffstat (limited to 'docs/MESHBAY_NODE_PROTOCOL.md')
| -rw-r--r-- | docs/MESHBAY_NODE_PROTOCOL.md | 7 |
1 files changed, 5 insertions, 2 deletions
diff --git a/docs/MESHBAY_NODE_PROTOCOL.md b/docs/MESHBAY_NODE_PROTOCOL.md index 0b5213c..0045f78 100644 --- a/docs/MESHBAY_NODE_PROTOCOL.md +++ b/docs/MESHBAY_NODE_PROTOCOL.md @@ -489,8 +489,11 @@ absent. `verify_proof` compares with `hmac.compare_digest`. | *(after the proof)* the roster admits `sub` for `group_id` — an active member row, or the node-wide operator row | `This node has not admitted you to this group`, code `not_authorized_for_group` | the key proves possession and the token the hub's view; the node's own answer is the roster. Someone revoked here but still a hub member, holding the key, is refused a session | `AuthorizedPeer` carries `user_id`, `group_id`, `username`, `jti` — and deliberately -**no user public key**. `username` is read from a `username` claim that neither the MNP -token nor the hub session token carries, so it is empty in practice. A key arriving in a token would be a key the hub chose, and the +**no user public key**. `username` is the MNP token's `username` claim, the account's +hub name (cut to 64 characters). It is a label, never authority: after the handshake the +node writes it into the roster for an account whose pinned name is empty — admission +by link, by device or into an open group carries no name — and an invitation's name is +never overwritten. A key arriving in a token would be a key the hub chose, and the node records the uploader's key in order to decide who may later delete a file: that would let whoever issues tokens decide it instead. Identity keys are pinned by the node's roster. The hub certifies accounts, not keys. |