Michael A. CojocariandClaude Opus 5
dee32e4c2c
The other half of the request. The previous commit made a scoped message resolvable to a region NAME; this is the list that decides which names are on offer. Until now the registry only filled itself from our own default region and per-channel scope overrides, so a region you can see traffic from but do not participate in could never be named -- which is most of them. Settings -> Radio, under the region-scope field, opens "Known regions": a field plus Add, and a row per region with Remove. Deliberately placed next to the region we SEND under, because the distinction is the confusing part -- that field is the region we transmit in, this list is the regions we can RECOGNISE, and a region only has to be named to be recognised, since its key is SHA256 of that name. You do not need to be in a region to identify its traffic. Remove is a RETIRE, not a delete. The slot and name stay bound; the region simply stops being matched from that point on. Freeing the slot for reuse would hand it to the next region added and silently relabel every message already received under the old one -- the exact failure #271 warned about, and the reason slots were never list indices. Re-adding a retired region revives its original slot, so its old and new messages stay one region rather than splitting in two. The persisted slot file gains an active mask and a magic bump (RGS1 -> RGS2). An RGS1 file still loads, with every assigned slot treated as live, which is what it meant before the mask existed. Two failures are reported rather than silently doing nothing: the list being full (all 14 slot bindings used, retired ones included -- they are permanent), and a name that canonicalises to nothing, like blank or a bare "#". Not board-gated -- the page uses the standard app-page chrome, so it inherits the tall title bar, the back chevron and focus-group navigation on the keyboard-only boards the same way Blocked users does. Laid out and reasoned about on the T-Deck for now; the short-panel boards want a look on real glass before anyone calls it done there. The page title is untranslated, matching every other app page here (Blocked users, Spectrum, Discover). All 8 S3 envs build. Four new strings in 13 .lang files, English both sides per 4709c81; the audit's 3 remaining gaps are pre-existing on main from the beta_68 SDK work. Not hardware-tested: adding a region is verifiable on-device, but whether a message then resolves to it needs real scoped traffic from a second node. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
wadamesh.com infrastructure
Distribution stack for wadamesh: a VPS nginx origin behind Cloudflare.
tiles.wadamesh.com →CF (HTTP, edge-cached) → nginx → OpenStreetMap / OpenTopoMap
firmware.wadamesh.com →CF (cache bins) → nginx → /srv/wadamesh/firmware
flasher.wadamesh.com →CF (HTTPS) → web flasher (TODO — see below)
wadamesh.com →CF (HTTPS) → landing page (later)
Map tile styles. The default /{z}/{x}/{y}.jpg route serves OpenStreetMap
(the firmware default). An opt-in OpenTopoMap topographic style is served from
/opentopo/{z}/{x}/{y}.jpg (explicit OSM alias at /osm/...); the device requests
it only when the user enables Map → Options → Topographic map. Legal: OpenTopoMap
map tiles are © OpenTopoMap (CC-BY-SA) over © OpenStreetMap contributors
(ODbL) + SRTM — the touch UI shows that attribution when topo is active, and the
14-day disk cache keeps each tile hitting OpenTopoMap at most once per fortnight
(their tile-usage policy asks for a contactable UA + caching, both of which the
transcode service provides). Deploying the topo routes = update
tiles.wadamesh.com.conf + tile-transcode.py, then
systemctl restart wadamesh-tile-transcode && nginx -t && systemctl reload nginx
and purge the Cloudflare cache for tiles.wadamesh.com/opentopo/*.
The firmware fetches tiles + the update-check over plain HTTP (on-device HTTPS isn't viable — mbedTLS needs ~30 KB heap, only ~5 KB is free post-Wi-Fi), so the tile + firmware hosts must stay reachable over HTTP. Cloudflare provides the edge cache, HTTPS for the flasher, and hides the origin IP (so no IP lives in this repo or the firmware).
1. VPS (origin)
sudo apt install nginx
sudo mkdir -p /srv/wadamesh/firmware/releases/TOUCH /var/cache/nginx/wadamesh-tiles
sudo cp deploy/nginx/tiles.wadamesh.com.conf /etc/nginx/sites-available/
sudo cp deploy/nginx/firmware.wadamesh.com.conf /etc/nginx/sites-available/
sudo ln -s /etc/nginx/sites-available/tiles.wadamesh.com.conf /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/firmware.wadamesh.com.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
2. Cloudflare
- DNS:
A/AAAArecords fortiles,firmware,flasher,@→ the VPS IP, all Proxied (orange cloud). - SSL/TLS: mode Flexible (CF↔origin HTTP) is enough since the origin is
HTTP-only. Do NOT enable "Always Use HTTPS" on
tiles.orfirmware.— the firmware needs plain HTTP there. - Cache Rules:
tiles.wadamesh.com/*→ Eligible for cache, Edge TTL ~14d.firmware.wadamesh.com/releases/*/*.bin→ cache, Edge TTL ~1d.firmware.wadamesh.com/releases/TOUCH(the listing) → short TTL (~60s) or Bypass, so new releases appear promptly.
3. Publishing a release
From a wadamesh checkout (builds both boards, refreshes the listing, rsyncs up):
WADAMESH_VPS=user@your-vps scripts/release.sh beta_2
The on-device check GETs http://firmware.wadamesh.com/releases/TOUCH, finds the
highest beta_<N>, and (once OTA-over-Wi-Fi is re-enabled) pulls
…/releases/TOUCH/beta_<N>/<board>.bin.
Done
- Web flasher ✅ at
flasher.wadamesh.com—deploy/flasher/(esp-web-tools / Web Serial, board picker, manifests pointing at the rolling/latest/merged bins;release.shrefreshes/latest/each publish). - Apex
wadamesh.com301-redirects to the flasher — activate by pointing thewadamesh.comA record at the VPS in Cloudflare (it's still on the parking IP).
TODO before public launch
- Re-enable OTA-over-Wi-Fi in the firmware (currently it version-checks then defers to manual flashing).
- Flip
wadameshrepo public = launch. - Decide tile-proxy sharing: dedicated
tiles.wadamesh.com(this config) vs reusing the meshcomod proxy.
Never commit the VPS IP, SSH keys, or
WADAMESH_VPS. Cloudflare fronts the origin; the deploy target is supplied via the environment at publish time.