Geo ID Specification
Format
COUNTRY-PROVINCE-LOCALITY-LASTNAME-FIRSTNAME-SUFFIX
Example: CA-BC-Wasa-Smith-John-260203| Segment | Source | Rules |
|---|---|---|
| Country | Cloudflare request geo | Valid ISO country code |
| Province | Cloudflare geo | Valid subdivision code |
| Locality | User-selected from curated list | Canada Post + StatsCan named places |
| Last name | User input | Required |
| First name | User input | Required |
| Suffix | Auto-generated or vanity | See suffix rules below |
Suffix Rules
- Default: Registration date as YYMMDD (e.g.
260203= February 3, 2026) - Same-day collision: Append letter:
-260203a,-260203b - Vanity upgrade: After claiming, replace date with a custom word (e.g.
-Landmax). The old ID becomes an alias that still resolves.
Key Properties
Permanent locality. Your locality is where you planted your flag, not your current location. A realtor in Wasa, BC who travels to Mexico for a month is still CA-BC-Wasa-.... Moving does not change your ID.
One person, one ID. Single identity with multiple profiles (not multiple independent identities). Tag profiles for different contexts: :office, :home, :cabin. Different peers see different profiles.
Direct to Nebula. The Geo ID IS the certificate name field. Peers see your human-readable name on every mesh handshake:
name: "CA-BC-Wasa-Smith-John-260203"
groups: ["claimed", "realtor", "cranbrook-market", "txn-2026-0142"]Geographic Verification
Cloudflare’s edge provides passive evidence on every request: IP, country, city, ASN, IPv6 prefix. This creates a network fingerprint that validates the claimed locality over time without requiring the user to do anything.
A user claiming to be in Wasa, BC, connecting from a Cranbrook-area ISP, is plausible. The same user suddenly connecting from Bucharest is flagged — not rejected, but flagged. People travel. The system accounts for that. But a pattern of consistent location over months is difficult and expensive to fake.