[nkuhn-vmw]

Desktop deployments using a separate NIP-FA/NIP-FI authority currently need to compile their deployment descriptor into Buzz. This adds a local, nonsecret descriptor read at startup for desktops built without any compiled sign-in servers.

The descriptor lives at the existing federation store root as federated-identity.json; the deployment guide documents each platform's path. A nonempty compiled server registry always wins, without opening the file. Missing local configuration preserves the unconfigured state; malformed, unsafe or unreadable configuration stops startup. Native validation, secure session storage, profile/descriptor fingerprinting and explicit plugin grants remain authoritative. No JavaScript token access or plugin authority setter is added.

This intentionally lets a user or deployment operator choose local authority configuration in a previously unconfigured build. A process already able to write as that user can also plant the file and cause a different organization sign-in prompt after restart. Permissions do not sandbox same-user agents or plugins; operators must trust the descriptor and protect its parent directory. Maintainer agreement on this opt-in local trust model is needed. Compiled policy remains non-overridable.

Unix loading rejects symlinks, special files, unexpected ownership and group/world-writable files using the opened handle, with a bounded read. Windows retains its application-data ACL trust model. The file survives session cleanup and local-data wipes. Changes take effect after restart.

Scope after the upstream multi-server changes

Rebased onto fd21dba; head 2eba153. The constructor preserves all compiled servers, their routing and their individual session slots. The local file still supplies only one server, and only when the compiled registry is empty.

Standard builds now include bb-public and ignore this file. Merging this PR does not let an official download add another organization's server at runtime. The test candidate explicitly sets BUZZ_BUILD_FEDERATED_IDENTITY_CONFIG=''. The docs also cover the existing alternate-Builderlab and pinned-dev rules that produce an empty compiled registry. No additional opt-in flag or runtime overlay of compiled policy is introduced.

This does not retarget the bundled Builderlab plugin's compiled grant, first-run account/key linking or backup, and does not grant community membership. An existing Buzz identity and an enforcing NIP-FI relay are required for the tested organization flow. Fresh independent-enterprise signup remains separate. #2245 closed unmerged; #2710 merged explanatory sign-in copy, not the missing fresh-identity flow.

Validation on the rebased source — November 6, 2026

GitHub’s proposed merge 30a882dd7314fd9591dff17554f971df03922a99 has exactly the tested head’s source tree (15dc2d4c76dac05df5814fe0cbb7c509e043a9b4). This equivalence is specific to the current snapshot.

• 144 native federation tests, 10 build-config tests, 218 relay tests (2 existing ignored), and the native import fixture passed. The new registry regression checks standard bb-public, multiple compiled servers, ignoring an invalid local descriptor, routing and stable per-server session slots.
• 201 focused renderer tests for federation and Builderlab account/first-run handoff passed. Formatting and the repository's pre-push hook, including workspace Clippy with warnings denied, passed.
• Native relay/import fixtures now use an in-memory unconfigured identity rather than reading the developer's real deployment file or credentials. Compiled registry behavior is checked explicitly by the new regression test.
• Independent read-only Claude Opus 5.5 review found no blocking code defect. Its configuration-documentation finding was corrected by describing all existing zero-server build paths; no trust-policy expansion was made.
• An unsigned arm64 debug .app was built with the pinned toolchain. Build caveat: unchanged upstream main fails TypeScript at src/bundled/channels/ChannelsPage.context.test.tsx:248, whose PageNavigation fixture lacks passThrough. I independently reproduced it on clean fd21dba. For this build only, the fixture got passThrough: () => () => {}; its 9 tests then passed. This test-only overlay is excluded from the PR and changes no shipped runtime source. Executable SHA-256: 32753befbcd1de2257a0d562c7e74e2c013b5b55cf6b61a70bf411490d451327.
• In an Apple silicon macOS VM, that exact packaged binary rejected a denied local-descriptor read with the expected path-only diagnostic; allowing the valid file advanced to a deliberately invalid-profile sentinel. The existing descriptor was unchanged and the probe stopped before session access. These are packaged startup checks, not live sign-in acceptance.
• The exact executable is running in the VM and reached the native organization sign-in flow after the existing identity's Keychain prompt. Packaging limitation: this unsigned debug bundle did not launch through Finder; codesign --verify --deep --strict reported code has no resources but signature indicates they must be present. It was launched directly from the guest Terminal. Normal double-click launch and signed distribution are not validated.
• Live cycle passed on this exact executable, November 6: browser callback 302; native code exchange, session check and relay assertion 200; protected write 200. Organization sign-out showed Not signed in, preserved the public key, and a distinct fresh message showed Retry with relay write/query 401. Reconnect obtained a fresh session/assertion and accepted a new write (200). Switching to Activity and back to Chats preserved that new message; the signed-out attempt still showed Retry. The cycle ran from 09:47 to 09:57 Eastern, with human assistance for Keychain access and the first browser sign-in.
• A resumed browser attempt initially returned an identity-provider error before the app callback; a fresh attempt completed. Its cause is not established. VM input automation intermittently dropped clicks/modifiers. Neither is attributed to this patch. Signed credential-helper restart, separately retained-token revocation, Linux native acceptance, current-head Windows acceptance and fresh independent-enterprise signup are not claimed.
• Upstream fixed the unrelated context-navigation test fixture in #2783, now in preview .248.1. The candidate and checksum above remain unchanged.

Application CI for this head is action_required. Please approve the hosted run and confirm the local-authority trust-model decision; the earlier approving review explicitly excluded that decision.

Earlier live evidence, kept separate

On November 5, head 523fc46 and executable f7665806c293caf56a7d0eb459ee3770e39e1261bc452adf3de5243a7215cd4d completed this cycle in an Apple silicon VM with an existing Keychain Buzz identity:

1. Browser login, code exchange, session check and identity assertion returned HTTP 200; a fresh private-channel write returned 200.
2. Organization sign-out showed “Not signed in” and preserved the public key. A distinct write showed “Retry”; relay write and queries returned 401.
3. Reconnect issued a fresh assertion and accepted a new write. Switching away and reopening the channel preserved that message while the signed-out message still showed “Retry.”
4. A different browser account linked to another Buzz key was rejected at assertion time with HTTP 403 and a visible binding mismatch.

The contributor's Windows acceptance covers their earlier locally rebased build, not this head. Neither earlier acceptance nor a merge establishes official distribution or fresh-install onboarding.

[corydouthat-sq]

Windows run of the manual acceptance from the description, against a real enforcing NIP-FI deployment (Block's), in case it helps with the "Windows native execution" item.

Environment: Windows 11 Enterprise 10.0.26300, WebView2 156, existing Buzz identity, relay in NIP-FI enforce mode (plain WebSocket upgrade → 401). Builds made with the repo-pinned Rust 1.98.1 / pnpm 11.8.0, pnpm tauri build --ci --no-sign --bundles nsis --config candidate.json -- --locked, without BUZZ_BUILD_FEDERATED_IDENTITY_CONFIG, BUZZ_BUILDERLAB_URL=https://app.builderlab.xyz (same as the published previews). Descriptor placed at %APPDATA%\.xyz.block.buzz.desktop.federated-session\federated-identity.json as documented.

1. The branch as-is needs a rebase. Built from 04df5c0 (base ec8b29ee8), the runtime descriptor loaded and the existing session restored (Settings showed the account and expiry), but every relay socket ended with invalid-assertion and the sidebar showed "Buzz couldn't confirm your organization sign-in for this community". That is the client-side validate_jwt check expiry - minted > 300 that #2171 removed on 2026-11-02; this deployment's adapter now issues longer-lived assertions, so the pre-#2171 code rejects them before the relay sees them. Not a problem with this PR's code, but anyone testing it against a current adapter will hit it.

2. Rebased onto 1a48ed1 (clean, no conflicts), acceptance on Windows:

Step	Result
Runtime descriptor in a build with no compiled authority	✅ loaded; Organization sign-in shows the authority
Existing session restored into the same slot (no re-prompt)	✅ same <fingerprint> credential/lock reused, consistent with native_owner_uses_same_session_slot_for_equivalent_sources
Relay connects with assertion	✅ sockets open, relay-backed writes resume
Sign out of organization	✅ session credential removed from Credential Manager; relay connections dropped within ~10 s; protected reads refused
Sign in again through the deployment (browser SSO)	✅ twice
Invalid descriptor (truncated JSON / http:// origin / non-JSON)	✅ startup stops with an error dialog "Cannot load federated identity deployment: " (path only, no contents); no WebView or network started
Restore descriptor	✅ normal startup, at-launch sign-in
Build with compiled authority + invalid local file	✅ ignores the file and connects normally

Observations (not blockers):

• federated-identity.json survives sign-out alongside <fingerprint>.lock / .record, as documented.
• While the browser sign-in was still open, Settings briefly showed a red "Sign-in did not finish. Try again." under Organization sign-in; it cleared when the callback completed. Same wording appears in the compiled-authority build, so it's not specific to this change.
• Windows ACL note in docs/configuration.md reads fine; nothing on this side validates the file's ACL, and a same-user write to %APPDATA% is all it takes, as the description says.

Build note for Windows without admin: corepack enable needs elevation, but a user-level pnpm.cmd wrapping corepack pnpm@11.8.0 %* on PATH is enough for beforeBuildCommand.

[nkuhn-vmw]

@corydouthat-sq Thanks for testing this and documenting the Windows results. I verified the lifetime check you identified and rebased onto upstream 92d4c36; the published head is now b130944.

That also brings in the macOS Keychain bundling change. There were two conflicts against this newer base: the configuration docs and the session-store constructor. Both are resolved, preserving upstream's launch guidance and bundled: store::BUNDLED.

Checks on the rebased Mac checkout passed: 113 federation tests, 207 relay tests (2 existing ignored), the native import fixture, formatting, and the mandatory workspace Clippy check. Another 313 existing first-run/sign-in tests passed. Independent Claude Opus 5.5 review found no blockers.

The description now credits your Windows acceptance against the build you tested, separately from our checks on this newer head. We're keeping the PR draft pending packaged Mac/real-Keychain/browser SSO testing, human acceptance and hosted CI. Headless Chromium/WebKit also confirmed the separate first-run limitation: an external community still offers Builderlab signup or an existing key. This rebase doesn't expand into that signup work.

[joahg]

🤖 Read runtime.rs and the FederatedIdentity::open wiring. Compiled config short-circuits before the file is opened, and the Unix loader opens with O_NOFOLLOW, checks the handle's owner and mode, and bounds the read. The PR itself notes that maintainer agreement on this opt-in local trust model is needed; that decision is outside what I reviewed. Branch currently conflicts with main.

[nkuhn-vmw]

Rebased onto current main fd21dba; published head is 2eba153, and the branch is conflict-free again. The multi-server constructor now retains all compiled entries and their session slots. Native federation/relay/import checks, focused renderer checks and the required Clippy hook passed; the description has exact counts and current-source packaged startup evidence.

The important scope change upstream is the built-in bb-public server. Standard builds now ignore the local file, as compiled-policy precedence requires. This PR still helps builds with zero compiled servers; it does not add runtime servers alongside the compiled registry. Could maintainers confirm whether that remaining scope is wanted, or point to the intended mechanism for independently hosted organizations in the official client? I have not broadened the trust boundary to solve that here.

The current CI run requires approval. I also reproduced an unrelated typecheck failure on clean main: the PageNavigation fixture in ChannelsPage.context.test.tsx:248 lacks passThrough. A test-only stub allowed the Mac candidate build and its 9 fixture tests; that overlay is not in this PR. The new candidate's full live SSO round trip is still pending, and the description clearly separates yesterday's successful live test from today's evidence.

[nkuhn-vmw]

The current-head Mac live cycle is now complete on 2eba153, using the same executable SHA-256 32753befbcd1de2257a0d562c7e74e2c013b5b55cf6b61a70bf411490d451327 recorded in the description.

• Browser sign-in → code exchange/session/assertion → protected write: HTTP 200.
• Organization sign-out preserved the Buzz public key. A new message showed Retry; relay write and reads returned 401.
• Reconnect obtained a fresh session/assertion and accepted a new message. It remained visible after switching away and reopening the channel; the rejected message remained Retry.

This used the existing Keychain identity and an enforcing relay in an Apple silicon macOS VM. The validation section retains the packaging limit: this unsigned debug bundle required direct executable launch; Finder launch and signed distribution are not qualified. The zero-compiled-server scope and standard official-download limitation are unchanged. Upstream also fixed the unrelated build fixture in #2783. No additional code was pushed for this test.