6.7 KiB
Regress — Design Notes (v0)
A location-based capture game in the spirit of Ingress, running as a nostr-native app on Archipelago. Instead of Niantic's fictional "portals," Regress uses real Bitcoin-accepting merchant locations pulled from BTC Map as the capturable objects. First scope: Madeira, Portugal.
1. What Ingress actually does (researched)
- Portals are real-world landmarks agents physically travel to and interact with via the app. In Regress, a BTC Map place (merchant/ATM/etc.) is the portal-equivalent.
- XM (Exotic Matter) is the fictional currency/fuel players collect by walking around; spent on all actions. Needs a Regress equivalent (see open questions below — sats? a synthetic in-app resource? nothing at all?).
- Capturing a neutral portal: deploying a resonator claims it instantly for your faction. Up to 8 resonators per portal ("fully resonated").
- Mods: optional items that buff a portal's defense/utility.
- Keys & Links: hacking a portal yields a key to it. That key, used at a different fully-resonated friendly portal, creates a link between the two — you cannot link a portal to itself.
- Control fields: three mutually-linked portals form a triangle that "fills in" — this is the actual territory-capture unit, not the portals themselves.
- Factions: Enlightened (green) vs. Resistance (blue); an AI-controlled third faction, Machina (red), exists in later content.
- Attack/defense: XMP bursters and Ultra Strikes destroy enemy resonators; a portal with zero resonators reverts to neutral and can be recaptured.
- Anomalies: live, time-boxed global events tied to real Ingress storyline/lore — probably out of scope for v0.
Sources: ingress.com, Fev Games Ingress guide, Fev Games glossary
2. BTC Map as the location data source (researched, live-tested)
BTC Map (teambtcmap/btcmap-api) is a real, actively maintained, crowdsourced
map of Bitcoin-accepting places, backed by OpenStreetMap tag data. It has a
public, unauthenticated REST API v4 at https://api.btcmap.org/.
Key endpoints we'd actually use:
GET /v4/places?fields=...— chronological sync of every place, withupdated_since/limitfor incremental sync (bring-your-own cache pattern, good fit for a self-hosted Archipelago app that wants an offline-resilient local copy).GET /v4/places/search/?lat=&lon=&radius_km=— places within a radius. This is what a "load the map around me" or "load this island" view would use.GET /v4/places/{id}— single place detail (name, address, phone, website, socials,osm_id/osm_url,verified_at, icon).GET /v4/places/{id}/comments,/v4/places/{id}/areas— community comments and country/community area membership.GET /v4/areas?lat=&lon=— which named areas (country/community) contain a point;GET /v4/areas/{id|alias}— area metadata + icon image.
No API key needed for reads. Write/RPC endpoints exist for community editing but aren't needed for a read-only game client.
Live-tested against Madeira right now: a 45 km radius search centered on Funchal (32.7607, -16.9595) returns 167 real, currently-tracked places — comfortably covers the whole island (~57 km × 22 km). Category breakdown from the actual data:
| Count | Category (icon) |
|---|---|
| 35 | restaurant |
| 14 | café |
| 13 | storefront (general retail) |
| 10 | pharmacy |
| 7 | hotel |
| 6 | bakery |
| 5 each | fitness, hair/barber, "business", medical |
| ... | long tail: bars, dentists, spas, tour operators, ice cream, a boat charter, a surf shop, a music venue, a bike rental, etc. |
This is real, not a mock — it's what the live API returns today. Full raw
dump saved at data/madeira-btcmap-2026-08-04.json for reference (167
records: id, lat, lon, name, icon, osm_id, verified_at).
Source: btcmap-api docs
3. Proposed Regress concept (draft — needs your input)
Every BTC Map place in scope starts unclaimed (Ingress's "neutral grey"). Players claim it, link claimed places together, and linked triangles form a control field over that territory — same core loop as Ingress, but the portals are real Bitcoin-accepting businesses instead of public art/landmarks.
Open questions before I design further
- What does "claiming" cost/require? Ingress ties everything to XM
gathered by physically walking near portals. Options for Regress:
- Physical presence required (GPS check-in via phone, like Ingress) — most faithful to the genre, but means players must actually be in Madeira.
- Sats/Lightning-gated — claiming costs a small zap/payment (fits the Bitcoin theme hard, ties into podsteadr's existing Cashu/Lightning plumbing you already have running).
- Nostr-native "proof of visit" — e.g. NFC/QR at the merchant, or a merchant-signed nostr event, so it's cryptographically real rather than GPS-spoofable.
- Some combination.
- Factions or free-for-all? Ingress's whole metagame is two-faction conflict. Do you want teams, or is this more like an individual/community "claim businesses you actually support" thing?
- Does "unclaimed" ever mean anything to the real business owner? i.e. is there a path for the actual merchant to claim their own listing (like podsteadr's owner-exemption pattern), or is Regress entirely player-vs- player over data about businesses that don't participate?
- Archipelago integration shape — same fork as podsteadr had: does
Regress run standalone on its own domain (external, identity-aware via the
nostr-provider.jsshim like we just wired for podsteadr), or does it need full orchestrator-managed packaging? I'd default to the podsteadr pattern (external + identity-aware) unless you want it embedded differently. - Nostr event shape for claims/links? Worth defining a custom kind (or piggybacking parameterized replaceable events) early since that's the actual interop surface other clients could read.
4. Next steps once the above is answered
- Pull the full Madeira dataset via
/v4/places(chronological sync endpoint) rather than the radius search, so we get a clean incremental-sync foundation instead of a one-off snapshot. - Define the Regress data model: place (from BTC Map, cached locally) → claim → link → field, plus whatever resource economy answers question 1.
- Stand up the repo skeleton (backend + frontend, matching the podsteadr stack unless you want something different) and wire BTC Map sync as the first real feature.