Skip to main content

blob_key

Function blob_key 

Source
fn blob_key(ns: &str) -> String
Expand 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 Cognito id_token alone can approach that, and combined with access_token+refresh_token reliably exceeds it (see docs/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:global for the host-wide set), the split fields under it (<ns>:access, …).