feat(hub): make mailing an invitation a remembered choice

A "Send the invitation by e-mail" box under the Invite member field,
checked by default and stored as the invite_email preference. Unchecked,
invite-notify is never called and the hub never sees the code.

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

1 files changed, 12 insertions, 1 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index a47cea0..f42fa69 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -371,7 +371,8 @@ Four properties, each load-bearing:
 1. **No public key is ever fetched from a directory.** The joiner's keys arrive
    from the joiner, both signed together in one transcript (`meshbay:join:v1`), so
    the identity key vouches for the encryption key.
-2. **The code binds a key to an account**, and the hub never sees it. 40 bits,
+2. **The code binds a key to an account**, and the hub never sees it — unless
+   the inviter ticks *Send the invitation by e-mail* (below). 40 bits,
    Crockford base32 rendered `XXXX-XXXX`, single use, valid for exactly one
    account in one group, stored only as `sha256(code)`. A password KDF over 40
    uniformly random bits would buy nothing. Guessing is bounded by 5 attempts per
@@ -419,6 +420,16 @@ being bob on his first connection:
 | Safety-number comparison | Nothing — but it needs two humans reading digits at the worst moment | correct, unusable as a default |
 | **One-time pairing code** | **Nothing: the code never reaches the hub** | **adopted** |
 
+**Mailing the code is the inviter's choice, and it gives up the row above.**
+The Members tab can ask the hub to mail the code to the invitee's address on file
+(`invite-notify`); that request carries the code, so an active hub holds it and
+can join in the invitee's place. It is offered because a code that arrives on its
+own is worth more to most groups than the property, and it is stated rather than
+hidden: the box reads *"Send the invitation by e-mail (may land in spam)"*, is
+checked by default, and is **remembered per account** (the `invite_email`
+preference), so an operator who unticks it once is not asked to again. Unticked,
+the hub is never called and the table above holds exactly. The CLI mails nothing.
+
 **Delegation is designed and deferred.** `invite_create` is authorised as a *role*
 check against the roster rather than an equality test against the operator, and
 the `delegate` role value is reserved, so a group admin who does not run the node