feat: particle cloud (no discrete dots) + geo-IP country preselect on login
All checks were successful
Deploy to Production / deploy (push) Successful in 1m1s
All checks were successful
Deploy to Production / deploy (push) Successful in 1m1s
Two coordinated polish moves the owner asked for.
## 1. Hero particle field — "no white dots, just a glow that follows the mouse and is always in motion"
Previous tuning (uPointSize 2.8, uBaseAlpha 0.6) gave discrete indigo
dots that additively saturated to near-white in dense clusters. The
owner wanted no granular dots visible at all — a continuous indigo
cloud that the cursor pulls toward itself.
Changes:
- **Render fragment**: replaced the anti-aliased disc SDF
(`smoothstep(0.5, 0.42, d)` — hard edge) with a Gaussian falloff
(`exp(-d * d * 6.0)` — smooth blob, no edge). Each particle is now
a soft volume that blends seamlessly with neighbours.
- **Sim fragment**: replaced the outward-gradient ring push with a
mouse-halo attraction. Particles drift toward an ideal radius
(~0.20) around the cursor, with exp-bell falloff so they don't
collapse onto the cursor or feel influenced from across the canvas.
`ringField()` helper is now unused but kept for future use.
- **JS uniforms**: `uPointSize` 2.8→14 (256-tier) / 3.6→20 (128-tier);
`uBaseAlpha` 0.6→0.055. Individual particles are below the
perception threshold for "dot" but 65k of them additively composite
into a continuous cloud. With the much lower per-particle alpha,
the cumulative brightness never saturates to white.
- **ParticleField tick loop**: asymmetric ring-active fade — `alpha
= 0.14` ramping in (fast cursor response), `0.012` decaying out
(slow glow trail after the pointer moves away). Matches the brief
"glow longer + attractive to mouse but always in motion".
- **ParticleHero index.tsx**: added an always-on indigo radial
gradient behind the WebGL canvas, so the hero never reads as
visually empty between frames — the canvas additively paints the
dynamic cloud on top. Removed the white-dot stipple from the
static fallback (it was the most likely source of the "weisse
punkte" complaint for any visitor on the fallback path).
## 2. SMS login — pre-select country picker from visitor's geo-IP
The country picker on `/login` previously defaulted to `'CH'` for
everyone. Visitors from DE / AT / US / etc. had to manually scroll
to their dial code — small friction but it sits on the highest-stakes
conversion step in the funnel.
- **New API route** `apps/api/src/routes/geo.ts` →
`GET /v1/geo/country` returns `{ country: 'CH' | 'DE' | … | null }`
by reading Cloudflare's `CF-IPCountry` header. Public, no auth —
reading a 2-letter country code from a geo-IP header isn't PII
under GDPR / DSG. `'XX'` and `'T1'` (CF's "unknown" + Tor) are
normalised to `null`. Outside CF (dev), header is missing → null.
- **Login page** picks up the result in the existing `useEffect`,
guards against codes not in our country list, and calls `setCountry`
to override the `'CH'` default. Stays at `'CH'` if the detection
fails or the visitor is on a Tor exit. Verified live: the endpoint
returns `{"country":"DE"}` from CF's German edge.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -10,6 +10,7 @@ import { accountRoutes } from './routes/account.js';
|
||||
import { adminRoutes } from './routes/admin.js';
|
||||
import { authRoutes } from './routes/auth.js';
|
||||
import { billingRoutes } from './routes/billing.js';
|
||||
import { geoRoutes } from './routes/geo.js';
|
||||
import { oauthRoutes } from './routes/oauth.js';
|
||||
import { serverRoutes } from './routes/servers.js';
|
||||
import { settingsRoutes } from './routes/settings.js';
|
||||
@@ -81,6 +82,7 @@ await app.register(templateRoutes);
|
||||
await app.register(billingRoutes);
|
||||
await app.register(supportRoutes);
|
||||
await app.register(accountRoutes);
|
||||
await app.register(geoRoutes);
|
||||
|
||||
// Loud warning if STRIPE_PRICE_* env vars are set to product ids (prod_…)
|
||||
// instead of price ids (price_…). Stripe Checkout would silently 400 — easier
|
||||
|
||||
33
apps/api/src/routes/geo.ts
Normal file
33
apps/api/src/routes/geo.ts
Normal file
@@ -0,0 +1,33 @@
|
||||
import type { FastifyInstance } from 'fastify';
|
||||
|
||||
/**
|
||||
* GET /v1/geo/country → { country: 'CH' | 'DE' | ... | null }
|
||||
*
|
||||
* Returns the country derived from Cloudflare's `CF-IPCountry` request
|
||||
* header, which CF adds to every request before it reaches our origin.
|
||||
* The header is an ISO-3166 alpha-2 code (or 'XX' for unknown / Tor).
|
||||
*
|
||||
* Used by the login page to pre-select the dial-code in the country
|
||||
* picker for SMS auth — visitors hitting the page from Germany see +49
|
||||
* already selected, etc. No IP is exposed to the client; only the
|
||||
* country code.
|
||||
*
|
||||
* Returns `country: null` when:
|
||||
* - Request is hitting the origin directly (dev / outside CF)
|
||||
* - CF couldn't classify the IP ('XX' is normalised to null)
|
||||
*
|
||||
* Public route — no auth required. Reading a country code from a
|
||||
* geo-IP header is not PII under GDPR / DSG.
|
||||
*/
|
||||
export async function geoRoutes(app: FastifyInstance) {
|
||||
app.get('/v1/geo/country', async (req) => {
|
||||
const raw = req.headers['cf-ipcountry'];
|
||||
const header = Array.isArray(raw) ? raw[0] : raw;
|
||||
if (!header) return { country: null };
|
||||
const code = header.toUpperCase();
|
||||
if (code === 'XX' || code === 'T1' || code.length !== 2) {
|
||||
return { country: null };
|
||||
}
|
||||
return { country: code };
|
||||
});
|
||||
}
|
||||
Reference in New Issue
Block a user