OpenStreetMap answers referer-less tile requests with a 403 'Access blocked'
image. A reverse proxy adding Referrer-Policy: no-referrer (seen with Traefik)
made every map in the app show that instead of tiles. Setting referrerPolicy
on the tile images overrides the document-level policy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The optional HTTPS proxy is defined in the repo's docker-compose.yml behind the
"https" Compose profile, which only git-checkout installs have. Docker Hub /
GHCR installs write their own compose file from a README heredoc that had no
npm service, so COMPOSE_PROFILES=https matched nothing and started the app
alone - exit 0, no warning. The same gap swallowed MC_TRUST_PROXY,
MC_BIND_ADDRESS and MC_DEMO*, which the compose file passes to the app.
Add docker-compose.image.yml - the image-based counterpart of
docker-compose.yml, maintained here and downloaded instead of hand-copied, so
the npm service and every variable stay in sync. The image tag becomes
MC_IMAGE in .env so the file itself needs no editing and can be re-downloaded
when something is added to it.
Docs: README Option A downloads the file (and .env.example) instead of pasting
one, and switches tags via MC_IMAGE; https-setup.md Step 1 splits into the two
install paths, tells image installs to refresh the file, notes that
MC_TRUST_PROXY / MC_BIND_ADDRESS need it too, adds the curl for
npm-default-site.conf (no docker/ folder there) and a troubleshooting row for
"only mc-webui starts, no error".
Verified with `docker compose config` in a scratch project directory: the old
hand-written file plus COMPOSE_PROFILES=https in .env resolves to mc-webui
only, the new file to mc-webui + npm with MC_TRUST_PROXY passed and port 5000
bound to 127.0.0.1; `config --images` lists both images, so update-image.sh
pulls and recreates them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Renaming the device in Settings changed the firmware's node name at once,
but mc-webui kept its cached copy until the next reconnect. Own messages
were stored under the old name, and their raw_packet snapshot and echo
candidates were built from it: Resend then broadcast a second packet under
the old name, and messages sent after the rename never got a repeater
badge. Open pages kept the old name in the navbar and on each message
sent, even across a container restart, until a reload.
set_param('name') now cuts the name to the firmware's 31 bytes on a
character boundary (the firmware cuts mid-character, the lib drops the
fragment on read-back), reads SELF_INFO back under the send lock - also
when the command failed or its reply was lost - and adopts the reported
name through _set_device_name(), which _connect() uses too. That updates
runtime_config and emits device_name on /chat; the page applies it to the
navbar, MC_CONFIG.deviceName and the mention rule, and loadStatus() catches
up from /api/status for a page that missed the event.
Also: send_channel_message reads the name under the send lock; the
self-echo guard no longer compares the sender's name, so a resend of a
message from before a rename is still recognised; get_device_info no
longer caches an ERROR reply as SELF_INFO; the observer reloads its MQTT
clients on a rename; Settings sends the name only when it changed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Also restores the "## 2.17.0" heading over its entries. That release was
titled on main only, so on dev its content was still sitting under
Unreleased and would have been republished as part of 2.18.0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The version check already worked for an installation running the published
image - CI freezes the version before building, so version_frozen.py ships
inside it - but "Update now" never appeared, because the webhook behind it
was installed from scripts/, a folder such an installation does not have.
And update.sh could not have served it anyway: it does git pull + rebuild.
- both installers accept being piped through bash (curl | sudo bash). They
then download what they need into /opt/mc-webui-{updater,watchdog} and
find the instance by looking for docker-compose.yml. A checkout install
keeps running its scripts from the checkout, unchanged
- updater.py picks the update path per request: git checkout -> update.sh,
bare docker-compose.yml -> the new update-image.sh (pull + recreate).
Resolved per request, so cloning the repo later flips it without a restart
- both update scripts end with MC_UPDATE_RESULT=updated|no_change, which
the webhook parses and /api/updater/status passes on. The UI used to
watch only for the version to change and then claim it timed out after
two minutes - the normal outcome right after a push, while the image for
that commit is still building. It now says so as soon as the run ends,
in a neutral state rather than a red cross
- the marker prints only when stdout is not a terminal, so mcupdate output
stays as it was
Also corrects the claim, in the README and in updater.py's own docstring,
that the webhook listens on localhost. It binds 0.0.0.0 - the container
reaches it over the Docker bridge - and sends no token, so port 5050 is
worth keeping off untrusted networks.
Verified: update-image.sh reports updated then no_change against a real
docker compose project; the standalone installer installs, runs and
uninstalls cleanly under systemd (WSL), with the app reaching it through
host.docker.internal and a triggered run coming back changed=false; the
resulting modal checked in a browser in both en and pl.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An instance published behind an access list or Cloudflare Zero Trust gets
an HTML login or error page in place of JSON once that session expires.
`resp.json()` then throws "Unexpected token '<', "<!DOCTYPE "...", and the
repeater panes printed that at the user. Diagnosed on the production
server 2026-09-08: the origin had answered a clean 504 JSON ("No reply
from repeater within 10s") and nginx passed it through untouched, so the
HTML could only have come from in front of it.
New window.fetchJson() (fetch-utils.js, loaded from _head_i18n.html so all
eight entry points get it) returns the parsed body — `data.success` and
`data.error` checks are unchanged — and reports anything else in the same
shape the API uses: {success:false, error, http_status, non_json|offline}.
A 401/403 with a non-JSON body is named as an expired login, since that is
the case the user can act on; an error the API sent as JSON keeps its own
message. 88 call sites converted; those that deliberately inspect the
response (resp.ok/status, blob, uploads) still use fetch directly.
Also stops three catch blocks in the repeater panes from rendering the raw
exception text.
Verified in a browser: normal calls unchanged, an HTML answer comes back
as a readable sentence, a refused connection as a network error, and all
seven pages load with no console errors.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"SNR | Hops: 4 | Route (5): 2 bytes | Region: pl" took two rows on a
phone even without a region, and the words carried nothing the icon and
its tooltip don't. Hops, route and region now show as an antenna,
a signpost and a map pin, each with the word it replaces as its title;
the SNR keeps its label, being short already. The icons match the rest of
the UI: bi-signpost-split is the project's path icon and bi-pin-map the
status bar's region indicator.
The hash size joins them as "2B" — the SI/IEC symbol, upper case for byte
— with the spelled-out "2 bytes" kept for the tooltip. Each fact is also
nowrap, so "(5) 2B" can no longer break across rows mid-value.
On a 390 px phone nothing wraps any more: 0 of 500 Public messages and 0
of 11 on a channel carrying regions, where before every region message
took two rows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
They describe the copy the node decoded and arrive with the message
itself, so they are there even when no echo was heard — otherwise such a
message had nothing under it at all — and a hop count at a glance says
whether the routes popup is worth opening. The rest stays: hash-size
label, region, and the popup with the Direct entry and the received
marker.
The popup's last-resort placement changed too: when neither edge of the
tap target keeps a wide popup inside a phone's viewport, it is pinned to
the viewport's left margin instead of overflowing on the right.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The line under an incoming channel message showed the SNR and hop count of
the one copy the firmware decoded, while the popup listed only the copies
relayed by repeaters. With the sender in direct range that read as a
contradiction ("Hops: 0" above, "Hops: 1" on every popup entry), because
the direct copy has an empty path and was filtered out of the echo arrays.
The line is now just "Route (n): <hash size> | Region: <name>", and the
popup carries everything it used to: the echo arrays include every copy
heard, in the order heard (ties on the 1 s received_at broken by id), a
direct copy is listed as "Direct" with 0 hops and no copy/analyzer action,
and the copy the node actually decoded is marked "received" — matched on
hop count and SNR against the message row, so a copy missing from the RX
log never mis-marks the next one.
The hash size is coloured red / orange / green for 1 / 2 / 3 bytes,
semi-bold, with per-theme tokens kept at or above 5:1 on the bubble; the
whole line goes from 0.7 to 0.8 rem and --text-meta from ~2:1 to 4.5:1,
since it was hard to read on a big screen. The popup now opens to the
right of its tap target: with the route first in the line, a
right-anchored popup ran under the channel sidebar on a desktop.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The meta line under an incoming channel message used to print the first
route inline ("Route (3): 142C→1122→271C→EE6C"), which with 2- or 3-byte
hashes and a few hops crowded everything else off a phone screen. It now
names only the per-hop hash size ("Route (3): 2 bytes") and stays the tap
target for the routes popup, which lists every route as before.
The line also ends with "Region: <name>" when the packet was flood-scoped
to a region this instance knows. The region name never travels: a
TRANSPORT_FLOOD packet carries a 16-bit transport code (HMAC of the scope
key over the payload) that _on_rx_log_data used to discard. Echoes now
keep those 4 header bytes in a new echoes.transport_codes column, and the
API recomputes the code for every configured region (Settings → Channels)
to find the one that reproduces it; own messages fall back to their
raw_packet snapshot. calc_transport_code() is shared with the raw-resend
packet builder, so both sides derive the stamp from one place.
Verified against on-air packets from the test server on #mcwebui: pl,
pl-ma and pl-kra each resolved to exactly one configured region.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Top-right now holds only the maximize button, and the toggles no longer
sit over the hop labels that cluster near the top of a drawn route.
Bottom-left was the last free corner: zoom is top-left, attribution
bottom-right. Verified at 412x915 and 1440x900, both themes - 10px from
both edges, no overlap with the attribution.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
On a phone the map view gives the map a fixed ~45vh strip under the
message list, which is too small to read a multi-hop route on. A control
in the map's top-right corner now expands #paMap over the frame and asks
the parent to hide the modal header, so the map really does get the whole
screen; the same button becomes a labelled Close, and Escape works too.
CSS overlay rather than the Fullscreen API: the panel runs in an iframe
and inside the Android WebView, where requestFullscreen on a plain
element is unreliable. The position rule needs !important — Leaflet
writes position:relative on the container as an inline style.
Verified live at 412x915 and 1440x900, both themes, in the modal, as the
standalone page and through a chat deep link: the map fills the frame,
the drawn route and the panned viewport survive both transitions, and no
console errors.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds "Move to another region" to the per-region menu. Until now the only
way to re-parent was to delete the region and add it again under a new
parent. `region put <name> <parent>` on an existing name already
re-parents it (RegionMap::putRegion), so the command was there; what was
missing was doing it safely.
Two firmware behaviours make a blind put unsafe, both confirmed live on
MarWoj Mobile Observer, and both settled by the one tree read the move
now does up front:
- The only cycle check is `region->id == parent_id`. Moving a region into
one of its own descendants is accepted, and detaches that branch from
the wildcard root: it disappears from the `region` listing entirely
(printChildRegions recurses down from the root) while still holding
table slots. Verified — after `region put zza zzb`, both vanished from
the tree while `region get zza` still answered ` zza (zzb) F`. Nothing
in the UI could then show them, let alone fix them. Forwarding is not
at risk: findMatch scans the flat array and never walks parents.
- The put branch sets `region->flags = 0`, so moving a flood-denied
region silently re-allows flood, and the reply says
`OK - (flood allowed)` without hinting anything changed. Verified: zzb
was denied before the move and came back allowed.
So the move reads `region` first, refuses self/descendant/wildcard
targets, then puts, then re-applies `denyf` when the region was denied.
A lost restore is surfaced rather than swallowed — the region has moved
but is forwarding traffic it was set to drop. The picker filters the same
descendant set client-side, so the guard is not a surprise at the end.
Moving a region carries its nested regions with it, which is the point:
verified moving zzc (holding zzb) under zza.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The backend already accepted a parent (`region put <name> <parent>`) and
the list indented nested regions correctly, but the Add form always
created at the root. It now carries an "Inside" picker listing the known
regions, defaulting to top level.
Verified end to end against MarWoj Mobile Observer: `zzpar` at the root,
`zzkid` inside it, the tree coming back as `* / pl / zzpar / zzkid` with
the child indented one level, and the firmware refusing to delete a
parent that still has children (`Err - not empty`).
Also fixes a status code this endpoint got wrong from the start. A
repeater answering `Err - not empty` or `Err - unknown region` is
enforcing its own rule, not failing as a transport, so it now comes back
200 with `ok: false` like the sibling /action and /neighbours/remove
endpoints, rather than 502. 502 was misleading and put a spurious error
in the browser console, where it could mask a real one. `dirty` is now
computed from `ok`, so a refused action can no longer mark the map as
having unsaved changes; the frontend checks both through one helper.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A repeater's flood-scope map was only reachable by typing `region`
commands into the console and reading back an indented text tree.
My Repeaters -> Settings -> Regions now renders that tree as a list with
per-region actions, an Add form, and a Default scope card.
Placed as a row at the foot of the Settings pane rather than a seventh
tile: region management is a list with its own add/remove and an
explicit save, not the scalar get/set fields the accordion is built for.
openToolPane() already accepts any descriptor, so REGIONS_TOOL reuses
the pane machinery; _paneCurrent/_paneParent make the pane back arrow
return to Settings instead of jumping two levels to the grid.
Two firmware facts shape the design, both verified against a live
repeater (MarWoj Mobile Observer, 2.2.15):
- put/remove/allowf/denyf mutate the map in RAM only and are lost on
reboot until `region save` writes flash. Edits therefore stage behind
an explicit Save with a warning banner, and leaving with changes
pending asks first. `region default` is the exception -- the firmware
calls saveRegions() itself -- so it never sets the dirty flag.
- The bare `region` reply is an indented tree (indent = depth, `^` =
home, trailing ` F` = flood allowed) capped at 160 bytes by
exportTo(reply, 160). Suffixes are stripped right-to-left because a
region may legitimately be named `F` or end in `^`, and a clipped
tail is reported rather than hidden.
The binary AnonReqType.REGIONS request stays unused: it answers with
exportNamesTo(), a flat list of allowed names with no hierarchy, deny
flags or home marker -- most of what this screen shows.
Names go through the existing is_valid_region_name() before any command
is built, which also blocks CLI injection through a name.
28 new unit tests cover the tree parser (nesting, the `F`-named-region
ambiguity, `#` stripping, truncation) and the command builder.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A channel used to have two settings: every message or nothing. Now it has
three - muted, every message, or a named profile of rules (mentions me,
message contains, sender contains; any or all must match). A channel on a
profile counts only matching messages: the unread badge, the navbar bell,
the app-icon badge and the browser/Android notification all follow the same
rule. Direct messages are untouched.
- app/notify_profiles.py: rule matching (case- and diacritic-insensitive,
same table as the chat filter), validation, storage in app_settings
- read_status.notify_profile column, written together with is_muted so a
mute never leaves a profile behind; migration added
- /api/notification-profiles CRUD, PUT /api/channels/<i>/notifications;
/api/read_status and /api/messages/updates report channel_notify_profiles,
the latter counts a profiled channel's unread through the profile
- Manage Channels: the bell opens a menu (Off / Every message / profiles /
Manage profiles...) instead of toggling; profiled rows get a green badge
- Settings > Notifications: profile list with in-use counts and an editor
- app.js evaluates the same rules for socket-delivered messages, and a
state version guard stops an in-flight poll from undoing a fresh
mute/favorite/profile change
- i18n en/pl (43 keys), docs (user guide, architecture, whatsnew), tests
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Built from 8b5ed4c and run for five hours on a Galaxy S20 FE: 115 wake ticks,
two of which found the socket dead and put it back, and notifications still
arriving at the end. The previous upload predates the wake, so the checksum in
the docs pointed at a build that still went silent after an hour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Measured on a Galaxy S20 FE with the service running: the app process, the
service and the WebView's own renderer process all stayed alive for an hour and
a half, and the page still stopped after 56 minutes. Notifications were posted
correctly from 11:29 to 12:25 - 45 of them, traced through the PendingIntent
each one creates - and then nothing, while the server went on emitting messages
at 12:28:46, 12:28:53 and 12:29:12. The server saw the client time out at
12:29:52 and no reconnection was attempted for the next 29 minutes, although
socket.io retries forever by default. Delivery came back only when the activity
was resumed.
Ruled out with evidence rather than reasoning: Doze (the phone was charging and
only reached full at 13:05), Wi-Fi (wpa_supplicant heartbeats every 10s, no
drop), Samsung's Freecess freezer (it froze a dozen other apps by name that
afternoon and never this one - the foreground service did its job), a killed
renderer or app process (neither appears in any kill line), and socket.io giving
up (reconnectionAttempts defaults to Infinity).
What is left is that Chromium suspends the work of a hidden page. A foreground
service buys the process; it does not make Chromium run the page inside it. That
gap is not something the Stage B plan knew about.
So the service now nudges the page every two minutes. evaluateJavascript is the
lever: injected script does not queue behind the throttled timers the page's own
setTimeout calls sit in. The script re-opens the socket if it has died, which is
what mc-webui would have done a second later had its timers been running, and it
reads mc-webui's own chatSocket rather than anything added for this, so it works
against whichever server version the user typed in.
The wake logs one line every two minutes under the McPageWake tag. That is
deliberate: it is the only way to tell "the page answered" from "the page never
ran the script" after the fact, which is exactly what the next measurement has
to distinguish.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Built from 9adb98d and verified on a Galaxy S20 FE: installs over the Play
build as an update, keeps the saved address, and the foreground service starts
and stops with the notification toggle.
The Play row in docs/android-app.md deliberately stays at 2.0 - the Store still
serves that until the release passes review.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Found on a real device: after Change server, Back did not offer the leave
prompt but reversed into the previous server's pages, leaving the app showing
one instance while it was set to another. The address form is reached through
Back, so switching twice was enough to get there.
The behaviour predates the recent-servers list, but that list is what turns
switching servers into an everyday action rather than a once-a-year one.
Only a deliberate choice of server clears the history - typed in, picked from
the list, or restored at startup. Following a notification into a conversation
still goes back the way it came.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes the last open [CLAUDE] item in the Play release plan. The section only
covered the .apk in this repository; the app has been on Google Play since
2026-09-05 and the two have to go out together or they drift apart. Adds what
Play needs on top - an .aab rather than an .apk, a versionCode that has not been
used, release notes per listing language, and the declaration a foreground
service always triggers - plus the promote-from-library shortcut that made the
first production review take hours instead of days.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two changes to the Android wrapper, shipping together as app version 2.1
(versionCode 6).
Notifications stopped arriving a few minutes after the app was backgrounded,
and no setting on the phone could prevent it: Android freezes a process with
nothing in the foreground, and a frozen process runs no JavaScript and holds
no socket. MeshWatchService is a foreground service of type remoteMessaging
that does no work of its own - it exists so Android leaves the process alone.
Every notification is still built by the mc-webui page, so mutes, blocked
senders, channel names, translations and deep links stay in one place rather
than being duplicated in Kotlin.
The service follows mc-webui's own notification toggle, read from localStorage
by the shim rather than asked of the page, because the wrapper connects to
whichever server its user typed in - very often an older mc-webui. The shim
also wraps Storage.prototype.setItem, since localStorage fires no event in the
document that wrote it. Android's own switches have the last word, so a revoked
permission or a silenced channel stops the service too.
setRendererPriorityPolicy goes with it: the page renders in a process of its
own, and WebView waives that process's priority once the view stops being
visible, so a service saving only the host process would still lose the
renderer under memory pressure.
Separately, the address screen now lists the servers reached before, so running
more than one instance no longer means retyping the whole address to switch.
Only addresses that answered are listed, which keeps typos out.
Also replaces the deprecated setDecorFitsSystemWindows with enableEdgeToEdge,
which is what Play Console has been flagging twice. Its default navigation-bar
scrim is overridden, or it would paint over the strip the wrapper colours to
match the page below Android 10.
Docs, the privacy policy (both languages) and the app-vs-PWA comparison are
updated: three of them said the app ran nothing in the background.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The wrapper was published to the Play Store today, so three places that told
readers it was not distributed there are now wrong: the Android guide, the
user guide and the README.
Each now leads with the Store and keeps the .apk as the deliberate second
route, with the fact that matters to existing users stated where they will
look for it: both builds carry the same signing key, so installing from Play
updates a repository build in place and keeps the server address.
Historical whatsnew entries are left as written; the change is announced in a
new Unreleased entry instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
--global writes to the config of whoever runs it, so a user updating with sudo was still prompted after applying the fix. Confirmed by a user on Raspberry Pi OS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
--global writes to the config of whoever runs it, so a user updating with sudo was still prompted after applying the fix. Confirmed by a user on Raspberry Pi OS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GitHub's HTTP/2 front end began answering the anonymous git-upload-pack
POST with 401 for the git 2.39 / libcurl 7.88 build that ships with
Debian 12. Git reads any 401 as a credential request, so update.sh sat
on "Username for 'https://github.com':" against a public repo, on every
server at once, with nothing changed locally.
Pull with http.version=HTTP/1.1, which GitHub still serves anonymously,
and set GIT_TERMINAL_PROMPT=0 so a genuine auth failure errors out
instead of blocking on stdin forever. Documented in troubleshooting,
README and whatsnew, including the one-off git config for installs too
old to carry the fix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both are copies of files already in the untracked .claude/ directory --
AGENTS.md of .claude/CLAUDE.md, .agents/skills/ of .claude/skills/ --
written by the agent tooling, not by hand. They were never tracked, and
a `git add -A` sweeping them into an unrelated commit is exactly what
this prevents.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Expanding a Settings section fired one `get` per field, each a full mesh
round-trip. Seven questions to a repeater four hops away, answered one at
a time, to change the one field you came for -- and often a batch that
timed out halfway and left the section blank.
Nothing is read until asked for now:
- every field has its own read button beside the control (same row, so
no extra line per field), and `Read all fields` at the top of the
section still does the whole batch
- GET /settings takes an optional `fields=` subset so a single field is a
single round-trip; the section still defines the order
- reads are queued client-side. The device already serializes CLI traffic
behind one lock, so parallel requests would only tie up server threads
waiting for it
- values are remembered per repeater in localStorage, so a section opens
with the last readings instead of empty boxes. A remembered value is a
usable baseline -- Apply writes an absolute value, so editing from a
stale reading still sets what was typed -- and is marked with a clock
per field plus a note at the foot of the section saying when it was
read. Apply and unsupported replies update the cache too
- a failed read no longer wipes what is on screen: the remembered value
stays, still editable, still marked
- field hints moved from a text block under the control into an info icon
by the field name (the pattern the app's own Settings modal uses), and
every field has one now instead of the 9 that did
Verified against a live repeater from the local container: expanding all
8 sections makes 0 requests, a single-field read sends exactly
`?section=advanced&fields=rxdelay`, the value survives a reload from cache
with the stale note, and Apply still round-trips (dutycycle rewritten to
its own value).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Settings -> Advanced carried txdelay and direct.txdelay but not rxdelay,
which CommonCLI has had all along for every repeater and room server
(get + set, float 0-20, 0 = off by default). Reaching it needed a raw
CLI command.
It is a distinct mechanism from the tx delays: calcRxDelay staggers the
repeating of flood packets by packet score, so a strong copy repeats
sooner and a marginal one waits and drops the repeat as a duplicate.
Adds the field to _REPEATER_SETTINGS_FIELDS and SETTINGS_SECTIONS (the
two lists must stay mirrored) plus en/pl labels and help. `af` stays out
on purpose: dutycycle replaced it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The path list is a retry order, so the same route twice means retrying a
route that has just failed while a genuinely different one waits. Both
editors (contact info and My Repeaters) POST to the same endpoint, so the
guard sits there: adding or editing a path onto a route the contact
already has is refused with 409 duplicate_path, and the modal stays open.
Paths are now normalized to lowercase on write and existing duplicates are
collapsed on startup (keeping the primary copy), which lets a unique index
back the check. The index is created in the migration rather than
schema.sql, which runs before duplicates are removed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
