Every capability, side by side

Nordic UART, one notify per frame — no </> envelope, because the firmware sets the MTU to a whole frame and running a frame decoder over that data discards every byte. Filed as Platform in this document until 2026-09-02, and it was a Gap; meshcore/ui/ble_transport.py is a port of android/src/blelink.cpp against the same Qt API, and the phone was the working reference for it. The desktop half has never met a radio — see the caveat above.

No VID/PID whitelist; a port is a candidate until the handshake says otherwise.

transport/discovery.py probes each port.

Matches on the NUS UUID, not on the device name. The desktop sorts the advertisers to the top of its picker rather than filtering down to them.

The same 12s LE discovery on both, from the same constant.

Shown anyway, so a mis-flashed node is still reachable — a peripheral only lists its service UUIDs when the advertisement has room. The desktop drops just the nameless non-advertisers, which have nothing to show and nothing to suggest they are radios.

The desktop now has two, deliberately: "Choose port…" enumerates instantly and "Connect over Bluetooth…" scans for twelve seconds, and folding them into one list would make the fast case wait for the slow one. Mobile: "Radios nearby".

The desktop now remembers a pair — which transport, and which device on it (ui:last_transport, ui:last_ble) — because a Bluetooth address left in last_port would be handed to a port probe on the next run. last_port is still read when nothing says which transport was used, so an archive written before BLE existed is not handed a blank slate. Mobile keys on the Bluetooth address.

Twelve seconds of discovery per attempt is what makes a retry ladder unaffordable; on the phone it is also the thing Android suppresses once the screen is off, which is the only place reconnect matters. Finding a radio in the first place stays the picker's job on both.

meshcore/transport/reconnect.py: pure stdlib, free of Qt, owned by neither transport, so the caller owns the timer and this owns only the decision. Serial and BLE ask the same object what to do next. A second backoff growing beside the first is how two links on one machine give up at different times for different reasons and neither matches what the status bar says.

A behaviour change on the desktop, and worth knowing: serial previously retried without limit. Ten attempts on both. The phone's ladder then stretches to 60/120/300s, for two reasons that are true there and not on a mains-powered laptop — a failed BLE dial to a radio that is not there occupies the radio for about thirty seconds before Android answers, and a phone has a battery.

Both settle on the same sentence. The desktop's is a status-bar QLabel, so nothing about the line itself is clickable and the retry is really the Connect button or the tray entry — the wording ("tap to retry") slightly oversells what is there. The phone's header line is tappable on every page, the Radio page grows a card explaining what happened, and a notice goes to the shade when the app is not in front.

A drop an hour later is a fresh fault, not a continuation of the last one — and treating a flapping link like an absent one would make the first look like the second within a quarter of an hour.

Distinguished from every accidental drop on the phone by exactly this call: asked-for takes the backoff and the foreground service down with it.

The phone now shows four states, not two — connected, handshaking, working on it, given up — with a slow pulse while it is trying, because "trying" and "stopped" are the difference between something to do and nothing to do. The desktop still shows state only on the tray icon.

Desktop probes candidates one at a time; a BLE scan is a single operation.

Opening a serial port blocks for seconds, so the desktop probes on a worker QThread. Both BLE paths run on the UI thread and must: QLowEnergyController is not thread-safe, and Qt Bluetooth is asynchronous by construction, so there is nothing to marshal from and nothing that blocks.

Names the dialout group and the exact usermod command.

QTBUG-112164.

The desktop's picker offers it and then re-checks rather than assuming it worked, because an rfkill block is not the app's to lift.

Every attempt made while Bluetooth was off failed for a reason that has just stopped being true, so the budget resets and the next attempt is now — including from having already given up, which is the common case: somebody switches it off for a flight and on at the other end.

115200, deliberately not a setting.

Both issue it; the order relative to app-start differs and does not matter.

The desktop now carries the active profile's key in the rail chip's tooltip, and the full key in each switcher entry's; there is still no labelled field anywhere.

The phone uses max_contacts for its "contacts full" warning but shows no capacity field.

Same 250ms tick and retry discipline; the C++ core is a deliberate port.

Notes

Desktop clamps with a spin box; the phone parses free text.

Spin box vs slider, both bounded by the reported maximum.

Getting these wrong takes the node off the air.

On the desktop it lives with Channels rather than in Settings.

Automatic and drift-aware on the desktop, a manual button on the phone.

The OS pairing dialog handles it; the firmware command is not exposed.

A dialog on the desktop, two buttons on the phone.

Cosmetic; extra paint code the QML delegate never gained.

Both deliberately ignore the sender's clock — UI.md §5.

The phone's long-press "Message details" dialog; the desktop meta line is always abbreviated.

Same inverted-0xFF convention on both.

Not a URL on either — the route is a local row and the map is local.

Tick when acknowledged, "sending N/3" before that, failed after.

The phone only recolours the border. Not deliberate, just less paint code.

Bytes, not characters, and both escalate colour at 85%.

Literally the same shared C++ function on the phone.

@name becomes @[name], two bytes longer.

Protocol. Text frames carry no attachment payload.

The phone disables the button; if the path is reached anyway it returns silently.

Same 3s grace and 3 attempts on both; the C++ side is a deliberate port.

The cure for a stale path that goes nowhere.

Broadcast has no receipts; counting attempts would never finish.

Guarded in SQL on both.

600s on both.

The form every other MeshCore client writes and parses.

Hand-ported; "@Bob" does not match inside "@Bobby".

Desktop is relative ("3m", "2h"); the phone shows a clock, weekday or date.

Bug on mobile. The desktop hashes the public key precisely so a rename keeps the colour; the phone hashes name.length, so a rename changes the colour and equal-length names collide.

Right-click on the desktop, long-press on the phone.

The list is derived from messages and contacts, not a deletable object.

Divergence. The desktop deliberately files a room server with people — "you log in and talk to it". The phone treats anything of advert type ≥ 2 as infrastructure, so a room server appears only under Repeaters and its unread is left out of the chat badge.

Both learned the same way: one box wired to two lists silently emptied the chat.

The phone shows the key in the Nodes action sheet, not from an open chat.

Both only add from something already on file.

The name follows the radio's contact record on both.

The desktop defines the three protocol calls and never uses them; they are not in the C++ core at all.

The firmware has no such command.

Desktop hazard. In its default hashtag mode the desktop re-derives the key from the new name, which breaks the channel for everyone already on it. The phone only derives a key when the slot has none.

The phone's Store::upsertChannel now carries region through its ON CONFLICT branch. Until it did, a region set on a slot that already existed was shown as saved and silently dropped — and a channel with the wrong flood scope is not merely unread, every repeater drops it (PROTOCOL.md 10a), so what looked configured transmitted into nothing. is_favourite is still deliberately left out of that update, because the caller that writes a channel from a radio read builds a fresh record and never fills it in.

Same swap-and-restore design, written twice.

dk, #dk and DK are three different scopes.

Same window and de-duplication on both.

Cache directory set before the plugin is built, as QtLocation requires.

Same reasoning on both: a filtered map hides where people are.

Divergence, not obviously deliberate.

Desktop draws 500m to be honest about advertised precision.

The desktop always opens on the same fixed coordinate.

One click on the desktop; the phone interposes a card, which suits a fat finger.

Near-identical algorithm, kept in step deliberately.

The desktop cannot assume which Qt is installed; the phone ships its own.

Desktop uses sortable columns; the phone folds signal and hops into one subtitle.

Both match the name and the public key. The desktop matches the whole 64-character key rather than the shortened form in the column.

Desktop has one Repeaters screen; the phone splits all-repeaters from my-repeaters.

Mobile bug. The phone's sheet hardcodes setMine(key, true), so it can mark but never unmark from this screen.

Identical thresholds, drawn twice.

Same algorithm; both skip nodes with no saved password and say so.

Desktop has its own decoder; the phone uses the shared C++ core.

Byte-identical curve on both.

Needs no admin login — a guest may ask.

Role comes back from the node; neither client chooses it.

Same storage key, so a restored archive carries it to the other client.

The desktop ties it to the "remember" checkbox instead.

Generated from one source.

One get per key — the node answers one command at a time.

Mobile bug. The generated table says all four go together and the firmware rejects a partial set; the phone sends them individually. The correct adminSetRadio exists in the bridge and nothing calls it.

The phone shows the range as a hint and relies on the node to refuse.

Same parse, same handling of an ambiguous key prefix.

Desktop embeds a second map in the admin window; the phone hands off to its one shared map. Both say how many could not be placed.

Not implicit on either — the firmware keeps it in RAM until told.

Diff-only, depth-first, with a trailing save. Ported deliberately.

Both say plainly that what was already sent stays on the node.

The phone folds everything that is not sent-or-reply into one "note" kind.

Desktop has 12, the phone 11.

Console-only on both, deliberately.

Not built on either.

qt/firmware_catalog.h is generated from the Python catalogue.

Heltec_t114_without_display beats Heltec_t114.

Same format deliberately, so one library serves both after a restore.

Desktop uses a file dialog; the phone must use Android's document picker.

Both compute and store it; only the desktop shows it.

Same JSON keys.

Written from esptool's own source; held to its byte layout by cpp/tests/test_esp32boot.cpp.

Consequence of the stub: the ROM loader's own limit is smaller, so the phone is slower.

Nothing to guard against without erase.

The phone has no stub to manage a rate change, so it syncs conservatively.

Automatic inside esptool on the desktop; explicit and non-fatal on the phone.

Desktop scrapes esptool's output; the phone counts its own bytes.

Same rule, ported deliberately.

Guards against the cable being moved in between.

Correct UF2 semantics on both.

The desktop uses the kernel's driver; the phone hand-rolls one.

Vendor requests implemented in Java on the phone.

The desktop does not filter at all, so the question does not arise.

esptool does it on the desktop; the phone reimplements it in Java per bridge type.

Same wording.

Same JSON format, readable by either client.

The phone offers three fixed bundles instead of free checkboxes.

The phone deletes on one tap with no confirmation at all.

Desktop: in the profile chip and switcher tooltips only, never as a field.

One migration, written once as MIGRATIONS[9] in meshcore/store/db.py and generated from there into schema/migrations/010.sql and the APK's resources. adverts, contacts, channels, messages, node_paths, positions, repeater_state and the scoped settings all carry profile_key.

contacts, channels and repeater_state are rebuilt: a public key, a channel slot number and (public_key, key) are each unique only within one radio.

idx_messages_dedupe is UNIQUE on five columns that are identical when two radios hear the same channel message. Without the scope in front, the second insert is silently rejected and the loss looks like a bug somewhere else.

store.db.pre-v10-<epoch>, beside the archive, never deleted automatically. Desktop takes it with SQLite's backup API; the phone checkpoints the WAL first, because a plain copy in WAL mode omits exactly the messages that arrived most recently.

Each device stamps its rows with the key it already holds, so the migration cannot be applied to the wrong archive.

Keyed by the radio's own public key rather than a local number, so two archives can be compared later without two devices' "profile 5" colliding.

64 hex characters becomes the profile key; anything else becomes pending:<random> and the rows are stamped with that. Nothing ever guesses a key or stamps rows with a value that looks real.

It acquires one when a radio first says who it is.

One transaction per scoped table, and the provisional profile is deleted as its rows leave.

The unscoped key is '', which is also where last_port, ui:* and the attached-radio pointers live permanently; a blanket update would carry this machine's /dev/ttyUSB0 into a profile that a later phase would hand to another device.

Folding two populated scopes needs a merge rule — which last_seen wins, what happens to a slot both radios use — and that is a later phase. The answer for a radio that already has a profile is to switch to it.

One classification function per client, and tests/test_profile_scope.py holds the two to each other and to the migration.

The safe direction to be wrong in: it stays put rather than following a switch. A test forces the decision to be made — but it walks the Python package only, so a phone-only key such as android:keep_connected is device-local by default and unexamined.

Sixty-odd SQL sites on each side; one missed predicate would show one radio's contacts inside another's chat list, silently. A source-inspection test reads both store/db.py and qt/store.cpp back and fails on any statement naming a scoped table without naming profile_key.

Desktop: a chip at the head of the rail, because the answer scopes every destination below it. Mobile: a Profile page under More.

A name is a label — it can be renamed and two radios can share one. Desktop puts it in the chip and menu tooltips, the phone in the row itself.

The desktop chip names the profile on every page. The phone's toolbar names the attached radio, which is a different question the moment one profile is being read while another radio is connected.

The scrollback belongs to the profile that was active when it was loaded; leaving it on screen under a new name is the exact confusion scoping exists to prevent.

Switching for the user moves them out of what they were reading; re-pointing the profile at the new key would relabel one radio's whole history as another's.

Region read, contact sync, channel read and the message drain all write into the active scope, so all four stop until it is answered. Losing a minute of a sixteen-deep queue is a far smaller loss than sixteen messages filed under a radio that never heard them.

Controller.use_profile and Radio::useProfile pick up where the handshake stopped.

Desktop puts it in the status line, the phone in the header status. Quietly resuming the sync into the wrong scope is the failure both are avoiding.

Desktop opens a modal named after what each button does. The phone brings the Profile page to the front, because a stopped sync with nothing on screen to explain it is indistinguishable from a broken app.

The desktop menu offers it whenever the attached radio has no profile. On the phone a new radio becomes a profile only through the connect-time offer.

The desktop says "Sends via " whenever it can send. The phone shows the line only when it cannot, so the ordinary case is unlabelled.

Reading is always allowed — the archive is offline — but a message typed under one profile and transmitted by another radio cannot be taken back. The desktop disables the button and repeats the refusal in Composer._emit, because Enter never goes through the button. The phone gates the QML button only; Radio::sendText does not re-check.

The archive is offline. Only transmitting needs a radio.

The map's own-node marker included: it takes the active profile in preference to settings.self_public_key, so a route still starts at the radio that heard it.

Both stores re-read the active profile as the file is replaced, and both rebuild their lists. The desktop leaves the rail chip and the composer line naming the previous profile until the next event refreshes them.

The desktop store has rename_profile and nothing calls it; the phone has no method at all. The label follows the radio's own name.

Store.delete_profile exists and is tested — for received messages the archive is the only copy, so it is not something to wire up without a confirmation designed for it. Nothing on the phone.

Not what §18 does. The merge rules fold two archives together and are explicit that a row never moves between profiles; folding one radio's history into another's is a different act, needs an answer to which last_seen wins and what happens to a slot both radios use, and inventing one silently is what phase 1 exists not to do.

Desktop: a checkable entry in the rail's profile menu, because that is where the question of scope already lives. Mobile: a toggle on More → Profile. Off by default on both, and stored device-locally under ui:all_profiles — how you are looking is not a property of the archive.

The desktop disables it and says why ("Only one profile — nothing to merge"); the phone hides it. Both also refuse at the read — _merge_scopes and mergeScopes return nothing below two profiles — so a setting left over from a deleted profile cannot produce a "merged" view of one thing.

Both filter the merged set the same way: infrastructure advert types, held as a contact by some radio.

Chat, the conversation list, unread counts and the nav badges stay scoped whatever the switch says. tests/test_merged_views.py asserts it directly on the desktop, down to the chat views not even having the setter; on the phone it is structural — the conversation reads are the ordinary scoped ones — and there is no test.

A node both radios heard is one pin and one row.

Name and type from whichever radio heard it last, because that is the radio that heard it renamed; contact and mine are true if any radio says so. MergedNode in meshcore/store/models.py and in qt/store.cpp are the same rules written twice, function for function.

Both are answers about your radios collectively rather than numbers attributed to one of them.

They live in the sightings. Averaging two radios' SNR would invent a reading nothing took.

"Horsens Havn, 3 hops · ADT-DK8700, direct" — a Heard by column on the desktop's tables, a third line on the phone's rows.

"Route" means two different things and both clients had already chosen: the repeaters list shows the outbound route from each radio's contact record, because the question that list answers is whether you can reach the thing, while nodes and the map show the inbound path of the last advert. provenance() and provenanceText() each take an outbound flag for exactly that.

Each client built one of the two surfaces SYNC.md §5b.1 names. The desktop draws a dimmer second line under the pin's own name label; the phone's pins carry no label at all, and its provenance is on the card a tap opens — which the desktop does not have, because a click there goes straight to the conversation.

Mobile bug. MergedNode::gpsLat walks the sightings and returns the first one holding a fix — and the sightings are ordered active-profile-first, then by name, never by time. So the phone shows the active radio's position however stale it is, and the alphabetically-first other radio's when the active one has none. The comment directly above the loop says the newest wins. The loop does not.

The phone's repeaters list is built from the conversation list rather than from contacts, so the merge is split down the middle: the world half of each row merges, the conversation half comes from the active profile alone, and a repeater only the other radio has ever seen gets no badge and no preview. Tapping it opens a chat, an empty one, in the active profile. That is the truth rather than a bug. The desktop's list is built from contacts and has no such seam.

The desktop appends "across all profiles" to the summary line on all three views. The phone does it on Nodes and the Map and not on Repeaters.

Argued rather than overlooked (SYNC.md §5b.5). is_mine is a per-profile flag, and the page's question is "is my infrastructure still up", answered by last_seen from the radio that watches it. Merging would produce a page saying a node is fine because the other radio heard it, which is the opposite of what somebody opens it to find out.

Every merged read runs the already-scoped query once per profile and stacks the answers (Store._scoped_to, store::Store::ScopeFor). Provenance falls out of the stacking rather than being reconstructed after a flattening, every statement underneath still carries its profile_key predicate, and two profiles cost two queries on a table of a few thousand rows.

A merged query that selects profile_key for provenance mentions the column all day and constrains nothing, so "it's a merged view" would have been a phrase big enough to hide a real leak behind. One pre-existing statement was caught by the tighter rule and is on the allowlist with its reason.

Because the SQL scanner cannot see a merged read at all, and wrapping messages() in _scoped_to is exactly as easy as wrapping discovered_nodes(). MERGES_ON_PURPOSE names four functions, one at a time with a reason, and fails on a dead entry. The phone's half is a scan of qt/store.cpp for uses of ScopeFor, with a canary assertion so the test cannot silently prove nothing.

(profile_key, origin, seq). A row's id is a per-file AUTOINCREMENT and cannot travel — archive A's message 500 and archive B's are unrelated, and B cannot adopt A's ids without colliding with its own. Indexed as the range scan a resumable log wants.

Connecting the phone's radio to the desktop — to flash it, or because BLE is being awkward — makes both machines write into that radio's profile. Keyed on the profile, both count from their own highest row and a merge folds unrelated rows together in silence. Keyed on the device they are distinguishable and the union is simply correct. Single-writer survives as an optimisation, never as something correctness rests on.

A lazily-minted uuid, classified device-local in both stores, because two archives sharing one would allocate colliding sequence numbers. It is announced in a sync hello — which is how two devices that turn out to be copies of one archive are refused rather than merged.

legacy:<profile_key>, with seq taken from id. It has to be deterministic across copies: two copies of one v10 archive must migrate to the same row identities, or restoring last Monday's backup would insert every row a second time.

The price of that determinism is that two devices which both wrote to one profile before v11 genuinely share a legacy origin, with overlapping sequence numbers. So identity is checked first — an indexed lookup, and the whole answer in every normal merge — and only the colliding rows are then compared by payload. A row with no payload-equal counterpart here is one this archive does not have, whatever its label claims, and it is re-homed onto a free sequence number rather than dropped. rehomed counts them; before this they were the rows the unique index rejected in silence.

Absence is also what "I have not heard of it yet" looks like, so without them the union puts every deleted row back and the next exchange undoes every deletion the user has ever made — silently, and repeatedly. The desktop writes them from its only two deleting paths, delete_contact and repeater_forget (which is also how a saved password is forgotten), and honours them. The phone honours what it receives and writes none, because it deletes nothing locally: removing a contact there tells the radio and leaves the archive's row alone.

A contact the radio has re-advertised is newer information than its removal, and first_seen — when this archive met it — is what says so.

It takes a whole radio's history with it, and for received messages the archive is the only copy. A tombstone would make that destruction contagious: delete on one device, and the next merge deletes on the other. It stays a local act, and a merge will happily bring the profile back. The safe direction to be wrong in. (_tombstone's own docstring still says a profile is tombstoned. The code is right and the comment is stale.)

contacts.is_favourite, contacts.is_mine, channels.is_favourite, channels.region, the scoped settings and a repeater_state reading — each with its own stamp. Per row rather than per field is what produces "I renamed it on the phone and a stale favourite flag clobbered the rename": one timestamp cannot say that the favourite is old and the name is new.

Name, type, flags, route and gps are one observation, already stamped lastmod by the radio. Splitting them field by field would assemble a contact record no radio ever held. first_seen takes the earlier and last_seen the later, because between two radios both are true.

Which makes every rule a maximum over a total order — commutative and idempotent, so the order merges run in cannot matter. It also settles the one tie that actually occurs: every row migrated from v10 carries stamp 0, and 1 > 0 means a favourite set years ago beats an archive that never knew about it.

A marker's value is a messages.id, the per-file counter that cannot travel; the other archive's "read up to 412" says nothing about this file's row 412. So the id resolves to the row it names, that row's (origin, seq) finds the same message here, and the local id is what gets compared and stored. A marker that cannot be resolved leaves the local one alone — wrong in the safe direction, because the badge reappears rather than a message being silently marked read.

origin and seq on the rows it creates, favourite_at, mine_at and settings.updated_at on the edits it makes, so a row created there is identifiable wherever it ends up.

Changed on both. Restore used to overwrite the database wholesale; both dialogs now offer Merge and Replace over the same rules a sync runs. The desktop makes Merge the default button and reports what it folded in; the phone offers two equally-weighted buttons.

The merge is the one operation whose subject is the file rather than the profile on screen — a backup holds every profile, and restoring only the active one's half of it would be a quiet way to lose the rest — so ten of its statements are exempt from the scope scanner, named one at a time with what each does. The functional half is a test that writes a second profile's backup into a store showing the first and asserts every row lands under the profile_key it arrived with.

TCP 45737. Two roles and not two programs: either device may dial, and the exchange is symmetric.

Both clients can show a code and type one. Ten characters of Crockford's base32, normalised before use — uppercased, dashes dropped, O read as zero and I/L as one — because somebody copying a code off a screen writes O for zero every time, and refusing it teaches them nothing.

Said plainly rather than dressed up: this is not a PAKE, and an attacker who reaches the pairing listener and gets one confirmation out of it can attack the code offline. So the defence is arranged differently — a wrong code closes the listener, the window closes itself, and 200,000 PBKDF2 iterations make that one offline attempt cost about half a second a guess.

No CA and no hostname check: a peer is an address the user typed and the certificate that was pinned, which is a much smaller set than "something that verifies". Load-bearing rather than belt-and-braces, because saved repeater passwords are in scope for the merge and therefore cross this socket.

Desktop through cryptography; the phone through the OpenSSL that Qt's TLS backend already loads, because Qt can use a certificate and cannot make one.

The receiver sends a high-water mark per (profile, origin, table) and the sender selects above it — the seek (profile_key, origin, seq) was designed to make possible. An origin the receiver has never seen is absent from the map, reads as zero, and that whole history follows, which is how a row relayed through a third device arrives without the two ends ever meeting. Nothing rewrites origin, so re-exchange stays idempotent.

Profiles, contacts, channels, repeater state, settings and tombstones: a few hundred rows against forty-odd thousand positions, so a watermark for them would be complexity bought with nothing — and their merge rule is a maximum over a total order, so re-sending is idempotent by construction.

At the sender and at the receiving merge, deliberately twice. A listen port that followed the archive would have every paired device fighting over one socket.

Rows land in a scratch archive and are folded in with one call to the same merge a restore uses, in one transaction. A connection that dies halfway leaves the archive exactly as it was and the cursor exactly where it was, so the next attempt simply repeats.

Received rows go through meshcore/store/merge.py and qt/merge.cpp — the same code a restore uses. Two would disagree, and the one that only ran over a socket is the one nobody could test.

conformance/sync.json covers the framing, the pairing derivation, the code alphabet and normalisation, and the value codec — everything that is arithmetic over bytes — replayed by both ports. It is the corpus's first authored group: every other one describes a radio's protocol and is authoritative because the hardware says so, while this one describes a protocol this project wrote, so disagreeing with a vector means the code and the specification have parted company and one of them has to give.

tests/test_qt_sync.py builds the phone's sync code for the host and runs it against the desktop's service over loopback, because the corpus cannot pin a TLS handshake, a pinned certificate or a delta computed from a peer's cursors — and a phone in a drawer is not a test that runs on demand.

identity.pem and peers.json, 0600, packed into no backup. A peer list that merged would turn "A paired with B" and "B paired with C" into "A trusts C", which is authorisation nobody granted.

And that is the whole trigger.

Both show the local IPv4 address rather than the network's name.

The phone's wording names Wi-Fi; the desktop's is the flatter "Not on a network."

Three states that are easy to conflate, said apart on both.

A fact rather than a guess. The phone's peer record even carries a reachable field and deliberately never exposes it to the UI.

The desktop confirms first; the phone unpairs on one tap.

The radio's own storage is smaller and destructive; the app is the only full copy.

Same reasoning: the radio deletes a message once you have read it.

Android's per-app sandbox already does this.

The .sql files are generated from the Python source and embedded in the APK as resources. At v11, which is where §18's row identity and tombstones arrived.

Verified on both — a natural thing to assume otherwise.

Same format deliberately, so a phone backup opens on the desktop.

Desktop uses SQLite's backup API; the phone checkpoints then copies.

The phone always takes everything.

New on both, and the rules are §18's. Replace is still offered; it is no longer the only answer.

Was the open decision here; it is taken. allowBackup is false and both rule files exclude everything, because the two are not alternatives: from Android 12 allowBackup="false" switches off cloud backup and leaves device-to-device transfer running, so dataExtractionRules answers that half and fullBackupContent covers Android 11 and earlier. The archive holds every message the phone has seen, saved repeater passwords, and — where an identity was captured into a profile — node private keys. D2D was the closer call and is excluded anyway: the app already has two deliberate ways to move an archive, and both keep the property that makes them safe, which is that the archive only moves when somebody moves it. The cost is written down rather than hidden — restoring a new phone from an old one brings MeshCore back empty. Confirmed on the handset with dumpsys package.

Five steps: where you are, find a radio, radio settings, your name, done. Gap on the phone, which drops a new install straight into an empty Chat.

Every one of its signals lands on a path that already existed. See above.

A marker file beside the archive and a setting, because they fail differently: a fresh install that has merged a backup has the setting and not the marker, and should still be walked through. An archive that already holds messages, contacts or a remembered port and has neither is quietly adopted as set up rather than interrogated.

Skip is offered on every step and closing the window counts as one. Settings › General carries "Run setup again…" and a line saying which of finished, skipped or adopted actually happened.

One device-local setting. Not profile-scoped, deliberately: it is where the operator is sitting, not a property of a radio, and two radios in one country is the normal case — scoping it would ask the same question once per radio and let the two answers disagree.

Frequency, bandwidth, spreading factor and coding rate.

meshcore/country.py has no apply of any kind. Choosing a country fills nothing in until a button is pressed, and even then the numbers land in the spin boxes and wait for the ordinary "Change radio parameters?" confirmation.

A question and not a clamp: an operator with a licence and a reason may well mean to go higher, and what they must not do is go higher without being told they have. The note that comes with it is the only place the table says its number is conducted power at the radio rather than radiated power at the antenna, so the two are one label and never two — split them and the claim becomes a lie by omission.

Alongside two project links, which are shown whatever the country.

Denmark, one band, EU868. The mechanism is general and the data is not, on purpose: an unverified band must not ship, and a test enforces the rule rather than trusting it.

qt/country_table.h is generated from meshcore/country.py and held fresh by a test, exactly as the firmware catalogue and the repeater config table are — and nothing in the APK includes it yet. Data plumbing laid ahead of a UI, which is worth knowing before somebody reads the generated file as evidence the phone has the feature.

Desktop adds the build date and the manufacturer, which it already decoded and the phone still drops (§2).

The only way to answer "is this radio actually transmitting" without a second one.

The desktop uses its status bar.

D-Bus on the desktop, the Android shade on the phone. Not mobile-only, as is easy to assume.

The phone posts it on the foreground service's own low-importance channel, so it cannot make a sound and silencing one silences both — and only when the app is not the thing on screen, because a notification for something you are looking at is noise. The desktop's give-up goes to the status bar and nowhere else.

Flashes the taskbar, and says so in Settings. Degrading to silence is fine; pretending to have notified is not.

Both defer to the OS.

The phone shows three and overflows the rest.

General on the desktop; the phone hardcodes the Chat slot.

Off until asked for, and withdrawn entirely on a channel: a channel has no node behind it — no key, route, signal or position — so the toggle goes with the panel rather than sitting there doing nothing.

Long-press is the touch equivalent, and the phone has it.

The phone returns to wherever admin was opened from.

Same choice, twice: nothing to package, and they recolour with the palette.

The phone gets it free from launchMode="singleTop"; the desktop has none.

The phone is translation-ready; the desktop has no i18n mechanism at all. Neither ships a translated build.

Fine for any recent phone; the bundled OpenSSL is arm64 too.