[bradseiler]

Summary

Add BUZZ_NIP_FI_REQUIRE_NEW_COMMUNITIES, default false, so operators can require Federated Identity (NIP-FI) for new tenant communities without upgrading existing ones. Both operator creation modes persist the requirement at generation 1 in the same transaction as issuer bindings. Existing rows and idempotent retries retain their policy and bindings.

Enabling this setting requires the database community source and a valid provision binding. New unbindable hosts return a coded HTTP 400, including in Off mode. Deployment/control-host startup bootstrap keeps its existing behavior, including an unrequired, unbound reserved control host. The creation setting is independent of BUZZ_NIP_FI_UPGRADES_ENABLED, which gates upgrades of existing communities.

Stage the database source and issuer configuration first, then enable this setting when the issuer can sign users into new communities. In Shadow, verify a new community's NIP-11 requires_nip_fi and operator issuer binding, while an existing optional community stays optional. Disabling the setting affects future creations only; born-required communities remain required, with no per-community rollback endpoint. Mode semantics stay unchanged: Off bypasses FI relay-wide, Shadow enforces stored requirements, and Enforce requires FI everywhere.

Related issue

No duplicate creation-default change found. Related: merged #8991 handles existing-session closure after policy upgrades. This change adds a creation default; it adds no schema migration or retrofit of existing communities.

Testing

A local relay passed 16 signed HTTP scenarios across restarts with the setting absent, enabled, and disabled. Both operator modes preserve existing rows, create required rows with issuer bindings, and return coded 400 refusals for unbindable new hosts. Reserved control-host bootstrap stays unrequired and unbound. Disabling the setting preserves stored requirements; NIP-11 still reports the Off-mode bypass.

At b3d067e87877995be6a029e440dd2fb81dfa9fa4: 1,967 relay/db package tests and 1,339 PostgreSQL tests passed, as did all-target Clippy, the standalone build, and normal pre-push hooks. The full repository gate passed at the earlier integration head 9d8d18f7; unrelated desktop/mobile checks were not repeated after the final relay-only merge.

To reproduce the database journeys with local PostgreSQL and Redis configured per TESTING.md, run scripts/postgres-test-run.sh --locked -p buzz-db -p buzz-relay --lib --tests. The new journeys cover creation, retries, binding preservation, coded refusals and bootstrap.

Independent source, final merge and PR description review found no remaining blockers. The three regression tests passed their baseline; all ten deliberate mutations failed assertions, including issuer replacement on retry and each creation/bootstrap/config guard. Human runtime confirmation remains pending; this PR stays draft.

Generated with Codex

[github-actions]

🔐 Codex Security Review

Note: This is an automated, security-focused review generated by Codex.
Use it as a supplement to human review; false positives are possible.

Scope

• Exact PR diff: 1bb2ad443d4ee4512dd0927888ad21a4a1c041bc...b3d067e87877995be6a029e440dd2fb81dfa9fa4
• Model: gpt-6.1-sol

💡 Click "edited" above to see earlier reviews for this PR.

---

Review Summary

Overall Risk: NONE

No concrete security, correctness, or reliability regressions found in the authorized PR range after tracing provisioning authorization, transactional policy creation, retries, issuer bindings, caching, and admission enforcement.

Findings

No concrete security, correctness, or reliability findings were identified.

Notes

• Review used read-only source and history inspection. Builds and tests were not executed, as instructed.

---

_{Generated by Codex Security Review |
Requested by: @bradseiler |
Workflow run}