[nkuhn-vmw]

A desktop deployment with its own NIP-FA/NIP-FI authority currently has to compile the authority into Buzz. This change lets a desktop built with an empty sign-in registry load one nonsecret descriptor, federated-identity.json, from its existing federation store at startup. The configuration guide covers installation, permissions, and removal.

A nonempty compiled registry takes precedence and Buzz never opens the local file. Standard downloads compile bb-public. Standard and mixed registries retain Builderlab customer routing, saved customer hosts, and per-server session slots. A local descriptor selects a single authority and cannot enable Builderlab customer discovery, even if it copies the built-in descriptor.

In a build with an empty registry, an absent file leaves federation unconfigured. An invalid or unreadable file stops startup. Unix checks the opened file's type, owner and write mode, refuses a symlink at the final component, and bounds the read. The operator must protect the parent path and ACLs. Windows relies on the user's application-data ACLs. Sessions keep their existing profile and descriptor fingerprint. Installed plugins still need a matching explicit grant.

Trust decision for review. Someone with write access as the user could place a descriptor and change which organization prompts for sign-in after restart. Is enabling that local choice for builds shipped with an empty registry acceptable? The earlier review left this decision to the project owners.

Validation on 804133e, rebased onto 3a1eb56. On November 9 I tested an unsigned arm64 debug bundle in a macOS VM with an existing Buzz identity and a relay that enforces NIP-FI. I built it from this commit with the pinned dependencies and BUZZ_BUILD_FEDERATED_IDENTITY_CONFIG=''. The guest executable matched the built binary (SHA-256 2152b29ca1d7c536ab5b779a2bded539a7a0d4b5b0512ea1c2e6b598c21d93e9).

1. Browser sign-in completed. The native exchange, session check and relay assertion returned 200. The private channel opened and accepted a new message.
2. Organization sign-out replaced the channel and composer with “Sign in to open this community.” A protected relay query returned 401. With the composer gated, there was no signed-out message submission in this run.
3. Reconnect completed a second exchange and obtained a fresh assertion. A second message was accepted, and both messages were visible after switching away and reopening the channel.

The local checks passed: 152 native federation tests, 10 build-configuration tests, 231 relay tests (2 existing ignores), the import fixture, 245 renderer tests, formatting and the repository pre-push checks, including workspace Clippy. Regression coverage includes restoring a Builderlab customer after restart and opening that same store with a local-only descriptor. Independent static review by Claude Opus 5.5 found no blocking defect.

This run covers an existing Mac identity. Fresh enterprise signup, a signed distribution, and adding another authority to the standard download remain outside this change. The previous Mac run and contributor's Windows run cover earlier heads.

GitHub's proposed merge has the same source tree as the tested commit (10087f0a131c0cc932a289c5c8d4a80f47709265). The hosted application CI run requires maintainer approval and has run zero jobs. Please approve that run so the project checks can execute.

[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.