BUZZ-268: Durable invitation revocation and restricted claims

[bradseiler]

Summary

Permanently revoke v2 relay invitations when their issuer or verified current owner is banned. Serialize mint and claim policy checks with restriction and owner writes so a committed ban or timeout cannot race past admission, membership creation, or invite-use accounting. Verify first-use owner credentials without user writes. Commit ownership only with a successful invitation claim, together with membership, policy evidence, and v2 consumption. Reject a conflicting owner with 403.

Apply the same historical revocation repair through migrations and desired-schema reconciliation, including quiescing and tombstoned communities without disabling deletion fences. Keep v1's natural expiry and add an optional UTC cutoff; legacy retirement still requires a fleet rollout and drain from the last possible v1 issuance.

This draft includes the shared mesh receive fix needed for independent validation. It retains a pending receive across housekeeping ticks and adds a production-consumer regression. The boot_lifecycle metrics scraper also retains the last scrape or error until its deadline instead of discarding useful failure diagnostics.

Related issue

BUZZ-268. Replacement for the older draft #8162, which remains unchanged. No other replacement draft found.

Testing

Current corrective head fed8e8fed08b83425881d04f66c221fd5efa2e3d passed just ci, just test, complete DB/relay packages and doctests, and the complete isolated PostgreSQL lane (952/952). Normal commit and push hooks passed without bypasses.

The signed HTTP rehearsal used a fresh local relay and a Redis observer. Invalid and banned-owner claims created no identities or controls. Successful v1/v2 claims bound ownership atomically and published one control for each new mapping. Retries and owner mismatches created no extra rows or controls. The private harness needed two compilation corrections before this passing run; production source stayed unchanged.

Restoring pre-admission materialization makes the new regression fail with two unauthorized user rows instead of zero. The reviewed fix was restored and all 24 focused cases passed. The destructive lookup-failure fixture now requires the wrapper's exact disposable database and restores its renamed table before assertions.

Issuer and verified-owner timeouts temporarily block claims on existing invites. They do not revoke them durably; claims resume after expiry. A distinct IssuerRestricted outcome preserves that distinction. The v2 restricted-claimant, restricted-issuer, and revoked-invite outcomes now log and explicitly roll back. Owner-mismatch errors in both formats and v1 restricted denials still roll back when the transaction drops; these paths do not log those outcomes. User-creation metrics count only committed inserts.

Independent review found no remaining blockers in the corrective delta. Optional trigger tuning, the conservative backfill comment, and splitting the already-validated shared remediation remain deferred. Human testing and fleet evidence remain pending.

Previous-head evidence retained below:

Validated fdd2db5c0390c73ddf4fae81cc418676ab7f63d3:

• just ci, just test, and an additional explicit workspace integration run with stderr visible passed with normal repository recipes.
• Full buzz-db / buzz-relay packages and doctests passed; the complete discovered PostgreSQL suite passed 946/946.
• A freshly built relay passed the signed live invitation workflow. Migration and desired-schema upgrade fixtures cover active, quiescing, and tombstoned communities.
• Removing the production claim lock makes the race regressions fail; removing the production push timestamp guard makes all four fixture cases fail. Both were restored before validation.

A first push attempt hit the existing ACP keepalive wall-clock fixture under concurrent validation load. The full normal hook retry passed with one test worker and the other validators idle; the source head stayed unchanged. Full CI also emitted an existing ACP pipe-test leak warning while completing successfully.

The shared PostgreSQL fixture now derives lease ordering from the persisted receipt timestamp rather than comparing host and database clocks. Normal CI selected and passed the new mesh production-consumer regression. Infrastructure-dependent tests skipped by ordinary package runs were exercised separately by the full PostgreSQL run. Human and fleet testing remain pending.

Independent review at fdd2db5c0390c73ddf4fae81cc418676ab7f63d3 found a blocker: invitation claims wrote user identities before admission. Commit a35acef9779e97c55c8d03b8bb0916fcd64e524d fixed it by committing ownership only with a successful claim. Reviewer V2 confirmed the fix at fed8e8fed08b83425881d04f66c221fd5efa2e3d. Production admission-lock removal makes the claimant race regressions fail. Live signed HTTP covers banned nonmember denial without consumption, successful claim after unban, issuer mint denial, permanent v2 revocation after unban, and verified owner denial on an agent's first claim.

Draft only: human testing, fleet deployment, and legacy v1 drain/cutoff evidence remain outstanding. No readiness attestation is included.

Companion drafts

Regression coverage: BUZZ-269. Staging runbook: BUZZ-270. Live-session revalidation: BUZZ-271. Webhook owner policy: BUZZ-272.

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: 30873ba46b5e08602ae61a2a0592ecedd37f7289...fed8e8fed08b83425881d04f66c221fd5efa2e3d
• Model: gpt-6.1-sol

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

---

Review Summary

Overall Risk: MEDIUM

The new admission lock can deadlock invitation claims against concurrent agent-owner materialization.

Findings

[MEDIUM] Acquire the admission lock before locking user rows

• Category: Concurrency
• Location: migrations/0061_invite_revocation.sql:55 (source)
• Description: PostgreSQL locks an updated tuple before invoking this BEFORE ROW trigger. Invitation claims acquire invite_admission_lock first, then update the claimant's user row in persist_claim_owner. Concurrent NIP-OA materialization calls set_agent_owner_with_operation, which can lock that same user row and then wait for the admission lock in this trigger. The claim subsequently waits for the user row, forming a deadlock. Neither call path retries the aborted transaction.
• Impact: Concurrent legitimate claims and NIP-OA authentication can fail with database errors, rejecting onboarding or authentication. Other user and restriction writes in the community also wait behind the admission lock until the cycle is resolved.
• Recommendation: Acquire the community admission lock within the owner-write transaction before issuing UPDATE, and enforce the same lock order across restriction writers. Update both migration and desired-schema definitions and add a concurrency regression covering overlapping claim and owner materialization.

Notes

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

---

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