From 375ad7d0435a176ad593a32045a5f0182a36d505 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Sun, 20 Sep 2026 18:56:58 +0200 Subject: fix: removing someone who never redeemed their invitation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A member row appears only when a code is consumed, so revoking someone invited to the wrong group was refused for having no row — and the node's refusal aborted the browser's removal before its hub half, leaving them a member everywhere with a live code. Revoking now cancels unredeemed codes for that group, and a node refusal no longer cancels the hub removal. Co-Authored-By: Claude Opus 5 --- docs/MESHBAY_DESIGN.md | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'docs/MESHBAY_DESIGN.md') diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md index b9fdbdc..555d0f1 100644 --- a/docs/MESHBAY_DESIGN.md +++ b/docs/MESHBAY_DESIGN.md @@ -383,6 +383,14 @@ Four properties, each load-bearing: rotation propagates by itself and revocation actually takes effect. (Rotating the key after a revocation is still required — the ex-member holds the current one, and no protocol can take that back.) +5. **Revoking somebody cancels the code they have not redeemed yet**, for that + group and no other. There is no membership until a code is consumed, so an + invitation sent to the wrong person is the whole of their access, and a + removal that left it usable would be a removal in name only. It is also the + case removal is asked for most: an invitation is undone before it is + accepted, not after. Nothing to rotate then — they never held the key, and + `member_revoke` says so by returning no reminder rather than by leaving the + caller to work it out. Node authority is established the same way, once per node: `meshbay-node operator pair` prints a code, the operator types it into their own browser, and the node -- cgit v1.2.3