fix(hub): the admin allow-list grants an account, not a username

Each name in admin_usernames is pinned to the first active account seen
holding it (admin_pins), so a name freed by a deletion grants nothing.

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

1 files changed, 11 insertions, 0 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index e7b29d0..cd97aa2 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -2025,6 +2025,17 @@ they received, so the hub and the nodes then disagree until each operator clears
 **Moderator is not administrator.** The user-patch handler is split by field: a
 moderator may act on the fields moderation needs and may not write `role`.
 
+**The configured administrators are accounts, not names.** `hub.toml`'s
+`admin_usernames` names the accounts to make administrators, and each name is
+pinned (`admin_pins`) to the first active account seen holding it — at start-up,
+or at that account's first request if it registers while the hub runs. The pin
+is what grants the role. A username is not an identity: deleting an account
+releases its name, and a list of names used to hand the administrator role to
+whoever registered a freed one next. A pinned name that changes hands now grants
+nothing, across restarts too. Removing a name from the list drops its pin at the
+next start, so handing a listed name to a new account is: remove it, restart,
+list it again, restart.
+
 **A file is reported by a member of the public group it was seen in, and an
 administrator decides.** An unauthenticated endpoint that blocklists a content hash
 after two reports is a network-wide censorship and DoS primitive for anyone who