The previous pass made the labels friendlier but didn't actually explain
what the Gate does. A real user (correctly) read "trusted networks" as
"any guest outside my IP is treated as fraud," which is the opposite of
what's happening — and missed the entire value prop: stopping forwarded
invitation links from being used by uninvited people. That's the central
pain GuestGuard solves; the Gate page has to lead with it, not bury it
under controls.
What changed on the Gate card:
- Big value-prop block at the top in plain language: "Every guest gets
their own personal invitation link. The Gate watches each link and
stops forwarded or shared invitations from being used by people who
weren't on your list." Also explicit: "Real invited guests don't
notice it. You don't need to set anything up — the Gate is on by
default with sensible settings."
- New "How does the Gate work?" collapsible explainer with a 4-step
walkthrough using Aunty Patience as the protagonist. Covers what
signals the Gate looks at, when guests *do* get flagged, and the
reassurance that normal day-to-day variation (Wi-Fi → mobile data,
changing rooms) doesn't trigger anything.
- Preset descriptions rewritten to talk about the actual pain instead
of generic strictness levels. "Stops forwarded links from being used
by people who weren't invited" lands much harder than "Recommended
for most parties."
- Trusted networks section opens with an explicit "What this is and
isn't" panel that directly addresses the misconception: adding a
network here is a *speed-up* for guests on your Wi-Fi, NOT a
whitelist that classifies everyone else as suspicious. Empty state
reads "No trusted networks — and that's fine. The Gate is doing its
job" so a host doesn't feel they've missed a setup step.
- Pill on the section header tags it "Optional · most hosts don't need
this" to drop its prominence. The button copy went from "Use my
current network" (which read like "approve myself") to "Trust the
network I'm on right now."
No backend changes. Internal Go names (FraudThresholds, /security/*
endpoints) untouched — never user-visible, renaming would churn for
zero end-user benefit.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The original Block G UI was correct but felt like a firewall config panel.
The audience for GuestGuard is wedding couples, party hosts, and event
planners — not network admins. Three concrete problems:
1. "Fraud detection" / "Risk score" frames every guest as a suspect.
"Gate" is the metaphor every host already uses ("gate the guest
list", "doorman"). It's the same idea, friendlier.
2. Three threshold sliders (0–100) are abstract. Hosts can't reason
about "block at 85" without context. Replaced by four presets —
Relaxed / Balanced / Strict / Very strict — each with a sentence
that explains the kind of event it fits. The sliders survive under
an Advanced disclosure for the rare power user.
3. CIDR notation is gibberish to a layperson. "Trusted networks" is
what they're actually doing. A "Use my current network" button
detects the host's apparent IP, widens IPv4 to /24 (typical home
block), and pre-fills the form. Manual entry stays for cases
where the host knows what they're doing.
Plus two leaks fixed on the guest-facing RSVP page: removed the
"Risk score 72 · high" line from both the confirmation and the
blocked-attempt cards. Guests should never see internal scoring
detail — the blocked message now reads "Something about this
attempt looked off" instead of "suspicious access attempt".
Backend
- New GET /me/public-ip (authed) — echoes the caller's apparent IP
so the frontend's auto-detect button doesn't need a third-party
ipify call
Frontend
- New components/GateCard.vue with preset cards + advanced disclosure
+ trusted-networks UX with auto-detect
- Removed components/SecurityCard.vue
- Event tab nav: Security → Gate. Hash-link alias preserves any
/events/<id>#security bookmarks
- RSVP page: leaked risk-score lines removed; blocked-attempt
message reworded for non-technical guests
Internal storage / API names stay (FraudThresholds, fraud_v2,
/security/* endpoints) — they're never user-visible and renaming
them would be a breaking change for no end-user benefit.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Kwaku Danso