Skip to content

Gate admissions on notification acknowledgement - #190

Draft
ael-dev3 wants to merge 4 commits into
mainfrom
codex/farcaster-notification-admission-gate
Draft

Gate admissions on notification acknowledgement#190
ael-dev3 wants to merge 4 commits into
mainfrom
codex/farcaster-notification-admission-gate

Conversation

@ael-dev3

@ael-dev3 ael-dev3 commented Aug 4, 2026

Copy link
Copy Markdown
Owner

What changed

  • gates admission on provider acceptance, fresh same-FID Farcaster Quick Auth, a one-use ticket, and the exact notification launch ID
  • requires a forced fresh host credential for acknowledgement; browser session credentials cannot satisfy the gate
  • uses the additive /v2/access/admission-grant-context Worker-first route and revalidates the exact pending request tuple with request-CAS immediately before admission
  • persists signed notification consent changes while delivery is paused, while continuing to fail closed for every send
  • adds an operator-only, bounded reissue path with a token-free sidecar that survives pause, expiry, opt-out, and rollback-compatible record reads
  • serializes acknowledgement and reissue per FID, enforces a five-minute provider-acceptance cooldown, and limits each exact request to two reissues
  • fixes transient REQUEST SENT copy and unlocks only after an explicit authoritative not-requested check
  • replaces both admission-alert variants with a realm-neutral Hegemony welcome that remains inside Farcaster's title/body limits
  • publishes a reusable public notification playbook, token-free failure map, canary checklist, and separately releasable technical note

Why

Provider successfulTokens proves handoff to Farcaster's notification service, not display, reading, or a click. The owner canary ultimately observed a real alert from the legacy already-admitted reconciliation path, proving transport while also confirming that transport success and admission ordering are distinct concerns. This change binds future admission to the exact alert launch plus fresh same-FID authentication.

User impact

A disabled player sees SUBMITTING REQUEST until SpacetimeDB confirms REQUEST RECEIVED. Admission remains unchanged until the exact notification is opened in the verified Farcaster account. The alert now reads Welcome to the Hegemony Empire and contains no realm or world identifier.

Validation

  • 3,028/3,028 repository tests across 270 files, run single-worker
  • 339/339 auth-bridge unit tests across 12 files
  • 12/12 workerd tests
  • frontend, bridge, and workerd typechecks
  • Worker deployment bundle dry-run
  • local Markdown link and whitespace checks
  • production build, manifest, and asset checks on the preceding source-equivalent frontend head
  • SpacetimeDB module build plus complete additive protocol-v14 proof on the preceding module-identical head
  • exact module artifact SHA-256: 22a9efe53568125ff7eabb76f8906dc9831351a27625d737c81a07559361e3f9

Production evidence and boundary

The owner reported the real Farcaster alert visible. Protected token-free live diagnostics classified the retained legacy generation as admitted / already-sent after six attempts with zero authority-verification failures. That evidence proves transport, not notification-before-admission ordering.

Publish or prove the reviewed additive module first with data deletion disabled, deploy the matching bridge while preserving the live attested configuration, then allow the matching frontend deployment. The technical GitHub release is intentionally not a new game version. No production mutation is included in this pull request.

@ael-dev3
ael-dev3 marked this pull request as ready for review August 4, 2026 03:45
@ael-dev3
ael-dev3 marked this pull request as draft August 4, 2026 14:34
@ael-dev3

ael-dev3 commented Aug 4, 2026

Copy link
Copy Markdown
Owner Author

Blocked by the single-notification invariant in #192. This branch currently permits post-admission/reissue generations (up to two reissues), which can produce more than one user-visible alert for one admission. Before this PR can return to review, rebase onto main and remove admitted-epoch delivery, every reissue surface, and any transport retargeting; retain only the exact pending-request generation, stable request ID, one FID-bound target, and monotonic terminal receipt. No code from this PR is approved for merge in its current form.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant