Geo vs substrate subdomain prefix — pa/ny/uk vs evernote.gf.cx pattern (parked 2026-05-23)

DARE.CO.UK · PARKED SKETCH · 2026-05-23

Mirrored from ~/.claude/.../memory/parked_sketch_geo_substrate_subdomain_pattern_2026-05-23.md. This is a design sketch parked for future build — read for context, not as a current deliverable.

Dan’s open question on URL structure for the portfolio. Two candidate schemes — geographic prefix (pa.gf.cx, ny.gf.cx, uk.gf.cx) holds locale, then substrate is a path segment (/evernote/coop/); OR substrate prefix (evernote.gf.cx) with location as path. Sketch the trade-offs + recommend.

Dan 2026-05-23: “how would I solve this problem — I need a structure that allows us to use any of the three locations for links (pa/ny/uk) so it might be https://ny.gf.cx/evernote/co-op/ — meaning coop lives in NY, or https://uk.gf.cx/evernote/london/flat. does that logic work across surfaces, or is it screwy. Or we do it very strictly, pa.gf.cx/evernote (local to that only), or evernote.gf.cx/coop ? Thats messy.”

The three candidate schemes

Scheme A: Geographic prefix · substrate as path

https://pa.gf.cx/evernote/co-op/         (pa-located Evernote co-op note)
https://ny.gf.cx/evernote/co-op/          (ny-located Evernote co-op note)
https://uk.gf.cx/evernote/london/flat/   (uk-located London flat note)
https://pa.gf.cx/amazon/orders/          (pa-located Amazon orders)
https://ny.gf.cx/amazon/orders/          (ny-located Amazon orders)

Pro	Con
Dan’s mental model already uses pa/ny/uk as scopes	Cross-location queries are awkward — e.g. “all my insurance docs across all locations” needs three queries
Clean root → location landing	The substrate (evernote, amazon) is repeated under each location; duplication of path patterns
Location is the dominant grouping (matches household reality)	A note that doesn’t have a single location (e.g. travel, AI tools, generic learning) doesn’t fit

Scheme B: Substrate prefix · location as path

https://evernote.gf.cx/pa/co-op/
https://evernote.gf.cx/ny/co-op/
https://amazon.gf.cx/pa/orders/
https://claims.gf.cx/pa/046414618/

Pro	Con
Substrate is the constant; cross-location queries within a substrate are one subdomain	Way more subdomains (evernote/amazon/claims/contractors/…)
Each substrate gets its own CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF Pages project, its own CI/CD, its own taxonomy	More config overhead; sandbox.gf.cx template needs to scale to many subdomains
Location is just a folder — easy to add a new one (au.gf.cx? gr.gf.cx?)	“Where’s the dashboard?” — no single landing for “my whole life”; have to know which substrate first

Scheme C (current): Mixed — pa.gf.cx is the household; substrate-specific subdomains for utility

https://pa.gf.cx/evernote/...        (everything PA-scoped lives under pa)
https://pa.gf.cx/amazon/...
https://pa.gf.cx/home-insurance/...
https://payload.gf.cx/...            (binary CDN — substrate-as-subdomain, only for infra)
https://assets.gf.cx/...             (web primitives — substrate-as-subdomain, only for infra)

Pro	Con
Status quo — already working for pa/	Doesn’t extend to ny/ or uk/ without picking A or B above
Infra subdomains (payload, assets, io, ask-opus) stay as their own thing	When ny.gf.cx and uk.gf.cx come online, we still need to decide

Recommended direction (sketch, not decision)

Scheme A with infra-subdomain carve-outs (essentially Scheme C extended).

pa.gf.cx, ny.gf.cx, uk.gf.cx — three location subdomains, each holds its own location-scoped substrate (evernote/amazon/insurance/etc).
Cross-location workstreams (career, AI tools, generic learning) live under a new neutral subdomain — e.g. me.gf.cx or stay on pa.gf.cx/_global/ until the volume justifies splitting.
Infra subdomains stay as-is (payload.gf.cx, assets.gf.cx, io.gf.cx, future ask-opus.gf.cx).
Each location has its own CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF Pages project cloned from sandbox.gf.cx template.

Where Scheme A gets screwy

Truly multi-location items: a piece of equipment that moved Brooklyn → PA still lives in pa.gf.cx/... (current location wins) OR gets a redirect from the old location (ny.gf.cx/equipment/<x> → 301 → pa.gf.cx/equipment/<x>). Need a rule: which subdomain “owns” an item, and how does history get preserved?
Substrate that spans locations: Amazon orders shipped to BOTH brooklyn AND pa addresses — single substrate, multiple buckets. Either duplicate the substrate render (one per location) OR route by ship-to. The current Amazon ship-to-bucket logic (BROOKLYN / NEW HOPE badges) already handles this within pa.gf.cx/amazon/.
Conventional naming risk: if pa.gf.cx keeps its Pennsylvania-house meaning, but Dan sometimes uses “pa” as shorthand for “personal admin”, that’s a clash. Disambiguate now.

Decisions still open

Confirm location codes: pa / ny / uk — or use full names (pennsylvania, newyork, unitedkingdom) — or city codes (new-hope, brooklyn, london)?
What happens to existing pa.gf.cx/amazon/?ship-to=BROOKLYN URLs when ny.gf.cx comes online? Migration path?
Does me.gf.cx / global.gf.cx exist for cross-location content, or is that just pa.gf.cx/_global/?

Resume conditions

Dan returns with a preferred scheme (or a refined sketch)
A new piece of content NEEDS to live somewhere ny-specific or uk-specific and forces the decision
The sandbox.gf.cx subdomain-template work begins — at that point we want the answer locked so the template can be cloned for ny/uk

Cross-references

parked_sketch_sandbox_gfcx_subdomain_template.md — the template work that depends on this answer
feedback_declarative_pages_for_infra_subdomains.md — the infra-subdomain landing rule
user_pa_gfcx_as_country_house_operating_system.md — pa-specific framing context
feedback_pre_2019_brooklyn_default_artifacts.md — the legacy ny address gotcha to keep in mind during any cross-location migration

Source: parked_sketch_geo_substrate_subdomain_pattern_2026-05-23.md · Rendered 2026-05-23 11:24