fn blob_key(ns: &str) -> StringExpand description
Single-entry key holding all three tokens as one JSON blob. Two different
roles depending on platform (see muxbus_load_tokens / muxbus_save):
- Windows: legacy (pre-2026-08-03) only. Windows Credential Manager
caps a single entry’s blob at 2560 bytes (
CRED_MAX_CREDENTIAL_BLOB_SIZE) — a Cognitoid_tokenalone can approach that, and combined withaccess_token+refresh_tokenreliably exceeds it (seedocs/specs/PLAN_MUXBUS_KEYCHAIN_WINDOWS_BLOB_LIMIT_2026_08_03.md). Kept only as a one-time migration source there; every Windows write goes through the chunked per-field layout below instead. - macOS/Linux: the CURRENT, preferred format. These platforms have no
comparable blob-size cap, so the chunked layout’s only purpose there
was to be platform-uniform with Windows — but each of its ~12 separate
keychain entries is its own OS-level access-consent decision, and macOS
Keychain prompts per-entry until each is individually trusted. Granting
“Always Allow” on one entry just surfaced the next entry’s own prompt,
making the whole flow look broken (retro-macos-muxbus-keychain-prompt-
storm-2026-08-19.md). One combined blob means one prompt, that one
“Always Allow” click actually sticks.
The blob lives at the namespace itself (
muxbus:globalfor the host-wide set), the split fields under it (<ns>:access, …).