meshcore-client

Commit Graph

Author	SHA1	Message	Date
Benjamin Wiechel	e054d894f5	Merge pull request #744 from OffbandMesh/feat/726-preset-catalog epic(#726): in-app radio preset catalog and picker (Companion/Observer)	1 month ago
diffwireauto	04025cb070	test(#748 ): fetch the real preset files so a 404 fails CI Every preset test faked the network, so presets missing from config-profiles main passed them all and reached the owner as "Couldn't update presets" on a test build twice. The live test refreshes from the real URLs and fails on any refresh error; a second live test proves a missing file comes back as HTTP 404. The picker test now checks that a good refresh shows no error. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	1 month ago
Strycher	a8780facf0	fix(#713 ): short-sync banner no longer blanks the app window The banner sits in MaterialApp.builder, above the Navigator, where there is no Overlay. Its close IconButton had a tooltip, and a Tooltip without an Overlay throws ("No Overlay widget found"). In the owner's release build that painted the window gray the moment the pointer reached the button. The close button drops the tooltip and keeps the accessible "Close" label on the icon. New tests mount the banner in MaterialApp.builder, as the app does, and hover the close button; both failed before the fix with the Overlay error and pass now. The earlier tests mounted it under home:, which has an Overlay, so they could not catch this. Epic #668. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	1 month ago
Strycher	8fdac486ed	feat(#674 ): tell the owner when a contact sync comes up short A short contact sync is now loud (SAFELANE 6). A banner above the whole app says the radio reported N contacts but sent M and that the saved contacts were kept; it stays until dismissed. When the automatic retry is short too, a modal asks: Keep my contacts (the default, focused, so Enter keeps) or Use the radio's list, which states how many contacts it would remove. Owner decisions on #670. The banner sits in MaterialApp.builder next to the storage banner (#385), above the Navigator, so the modal is drawn in place rather than pushed as a route. Strings are English; other locales fall back through untranslated.json, as the storage banner's do. Widget tests cover hidden, shown with counts, the no-total wording, dismiss, the decision's default and both choices; with the Keep default removed, two fail. Epic #668. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	1 month ago
diffwireauto	2f0f036eb6	feat(#729 ): group the preset picker by region and label each preset's source Radio Settings now takes its presets from RadioPresetService instead of the hardcoded list, which is removed (radio_settings.dart keeps only the LoRa enums). The picker, extracted as RadioPresetPicker for reuse on the remote-node screen, groups presets under non-selectable region headers, labels each MeshCore or Offband, and shows where the list came from with a refresh button; a failed refresh stays on screen in the error colour. Selection is tracked by preset id rather than list index, because a refresh can change the list under an open form. Upstream presets carry no TX power, so a preset without one matches any power and applying it leaves TX power as it is. The form refreshes a stale list when opened. Epic: #726 Agent: MagentaHawk (session 5a8922d6) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2 months ago
Strycher	15e4917e12	fix(#610 ): apply Gemini review, harden the card parser and chip Three accepted findings, plus a real defect the adversarial test cases flushed out. A long name overflowed the chip by 405 pixels. The name comes off a public radio channel and is attacker-controlled, so anyone could break a message list by posting a card with a long name. The label is now bounded and ellipsized, with an explicit width ceiling because a WidgetSpan hands its child unbounded width. fromChannelShare no longer scans from the first < to the last >. Two cards in one message were read as a single span running from the first key to the last name. That was reachable: the add dialog passes raw pasted text straight to it. It now takes the first well-formed card via a regex whose name class cannot cross a closing bracket. The known-contact check is O(1) against the connector's existing _knownContactKeys set, through a new isKnownContact. Scanning contacts ran per chip on every notification, and the public knownContactKeys getter copies the whole set, so neither belonged in a build method. Card-versus-mention is now carried on the match instead of inferred from text[m.start] == '<', which would mis-route the day a third bracketed pattern is added. Two findings were rejected on evidence and are justified in the PR body: a claimed missing null terminator (firmware sets it from the frame length itself) and a claimed greedy-regex failure (disproven by test). Epic #610. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
Strycher	3d5e655188	feat(#610 ): render a received contact card as an Add Contact chip The receive half of contact sharing. Until now an incoming <key:type:name> rendered as raw text while the stock app showed a native Add Contact button for the identical payload, so sharing worked outbound only: a stock user could add an Offband user from a card, but not the reverse. Confirmed by the owner on hardware. Reuses the proven mention-chip mechanism in TranslatedMessageContent rather than adding new machinery. Both patterns are now collected and sorted by position, so a message carrying a mention AND a card renders both in the right order; they cannot overlap, since a mention is @[...] and a card is <...>. Tapping opens the add dialog seeded with the card rather than adding silently. A contact is an identity, so adding one stays a deliberate act with the key, name and type visible first. Two deliberate refusals: - A card whose key is already a contact renders inert, mirroring stock, which warned the owner rather than silently re-adding. - A card matching the shape but failing the parser, such as an out-of-range type, falls back to plain text. Showing an Add chip there would promise something the parser will refuse. Parsing already existed from the #611 Gemini review, so this change is rendering and dedupe only. Epic #610 under Feature #609. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
diffwireauto	68e0d5c58e	test(#717 ): pin the frame budget per platform, so this cannot regress silently One getter decides the composer's byte budget on every platform, and it had collapsed that budget to zero on three of them before anyone noticed: Windows (#686), Linux (#717) and Web (#718). Each surfaced as a user reporting "the keyboard doesn't respond", two months and three platforms apart. Nothing exercised the getter, so nothing went red. Extracts the decision into `MeshCoreConnector.resolveFrameBudget`, a pure function of (transport, isWeb, mtuNow). The getter is now a one-line delegate and behaves identically. This is what makes the web branch testable at all: `kIsWeb` is a compile-time constant, so a VM test could never enter it and CI runs the suite on the VM only. 19 new cases, covering what we now know rather than what we guessed: - wired transports are never floored, and ignore a bogus MTU - web is exempt from the floor, and both composers stay usable at MTU 23 - native BLE keeps the #395 write-safety floor: unknown MTU yields 20, never the full frame, because defaulting an unknown link to the largest size would authorize an oversized write - the MTUs actually measured on hardware (Android 247, Windows 176) leave a usable channel composer - the original failure stays reproducible: an unreported MTU still gives a 0-byte channel budget and 4 bytes for a DM, the two numbers users reported Also adds widget tests for the #684 notice, including the disconnect case the pre-PR review caught, and the severity split between a zero and a small budget. analyze clean, 981 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
Strycher	a88c24f44f	fix(#629 ): put Scan contact QR on the contacts menu, not only in the key field Owner feedback from testing: a scan button living only inside the public key field is awkward placement, because scanning is how most people will actually add someone and it should not be reachable only from inside a field they have to open first. Now in both places, routed to the right thing: - Contacts overflow menu, Scan contact QR, opens the scanner and hands the result to the add dialog already populated. Nothing to paste. - The key field keeps its scan button, which fills in place, for when the dialog is already open. Same scanner and same parser either way; only the entry point differs. The dialog gains an optional initialKeyText, and seeds it through the same handler as a paste, so a scanned link populates name and type rather than sitting there as raw text. Platform availability moves to a shared contactQrScanAvailable getter on the scanner screen, since it now has two consumers. Both the menu entry and the field button hide on Windows and Linux, where mobile_scanner has no support and the render half is the desktop path. Epic #619. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
Strycher	d5a306d4a4	feat(#630 ): show how far a contact identity is confirmed Adds a calm three-state indicator beside each contact name, per the owner steer: a green check for advert-verified, a neutral outline check for key-confirmed, a muted key for key-only. No amber and no hazard glyph, because nothing is wrong with a key-added contact. The scale reads as how much we know, never as how risky. The states are not cosmetic: - advertVerified: a signed advert arrived, so the node itself asserted its name, type and position, and the raw packet is stored, which is also what makes the contact re-shareable. - keyConfirmed: a message with this contact went through. Direct messages are encrypted with an ECDH secret derived from the contact key, and the ACK is computed over the decrypted plaintext (BaseChatMesh.cpp:442,451), so this is proof the holder of the matching private key is live. It does NOT prove the person is who the name claims. - keyOnly: someone supplied a key and nothing has confirmed it on air. Costs almost nothing to compute. Contact.isAdvertVerified falls out of the epoch last_advert_timestamp that #627 already writes, and it clears itself when a real advert rewrites the field. The advert check runs first so only an unconfirmed contact pays for a message scan, which keeps a long contact list cheap. Also fixes a defect the epoch sentinel introduced: _formatLastSeen ran the epoch through the relative formatter and claimed a key-added contact was last seen tens of thousands of days ago. It now reads Not heard yet. Epic #619. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
Strycher	cfe533ec18	feat(#629 ): show and scan a contact QR Both halves of the visual exchange, sharing one format and one parser. Render: showMyContactQrDialog puts this device's own identity on screen as a QR plus the same link as selectable, copyable text. It refuses to render when not connected, since an empty key would encode a QR nobody can add. Scan: ContactQrScannerScreen validates with Contact.isValidShareUri, the same check the paste path uses, and pops the raw string. The add dialog routes a scan through the same handler as a paste, so a QR gets no separate code path. The scan affordance is gated to platforms mobile_scanner supports (Android, iOS, macOS, web). On Windows and Linux the QR half is the render side, which is the better desktop flow anyway: put your code on the big screen and let the other person scan it with a phone. Fixes a real defect found by the new test, not a test artifact: QrCodeDisplay built its QrImageView through a LayoutBuilder, which cannot answer intrinsic dimension queries, so any intrinsic-measuring parent threw. AlertDialog measures its content's max intrinsic height, so the dialog crashed on open. The QR is now bounded by a tight SizedBox, which answers the intrinsic itself. This was the widget's first real call site, so the bug had never been exercised. Entry point is provisional alongside Add by key; #632 reorganises. Epic #619. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
Strycher	3f427d2c41	feat(#628 ): add a contact by typing or pasting a public key First user-reachable piece of the identity exchange. A dialog takes a public key, a name and a contact type, and hands the stub to addContactByKey. The key field also accepts a whole meshcore://contact/add link and absorbs every field from it, because that is what someone actually pastes, and a QR is only that link rendered visually. Whitespace is stripped so a key copied across a line break still works. The stub is built by round-tripping through buildShareUri and fromShareUri rather than constructing a Contact directly, so manual entry and a scanned QR cannot drift apart. One code path, one set of invariants. An informational note states plainly that the contact is not confirmed on air and that the name is whatever the user typed until the node adverts. Deliberately informational rather than a warning: nothing is wrong with a key-added contact (#630). Entry point is provisional, sitting in the contacts overflow menu so the feature is reachable. The proper add-contact surface, split away from the advert affordance, is #632 under epic #623. Five widget tests pin what reaches the connector: key, typed name, chosen type, the flood sentinel, and the epoch lastSeen that keeps the firmware replay guard from muting the contact. Also covered: pasted-link prefill, wrapped-key whitespace, an invalid key sending nothing, and the missing-name fallback. Epic #619. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
Strycher	3b39a16edd	chore(#462 ): remove em-dash characters from test/ (and lib top-up) Follow-up to #457. Swept the em-dash character (U+2014) out of the test tree (test descriptions and comments) and cleaned 8 em-dashes that landed in lib comments via the #456 refactor after #457 merged, so the tree is back to zero. Same rules: replaced with commas/colons/periods, preserved the lone "no data" glyph placeholders, left non-English ARB untouched. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 months ago
Strycher	1ecf1ce55d	fix(#389 ): Back pops out of a channel; only top-level tabs background AppShell decided top-level vs detail by `selectedIndex != null`, but pushed detail screens (a channel chat, the LOS map) also set selectedIndex to keep the bottom bar visible. So Back from inside a channel backgrounded/left the app instead of popping to the channel list. Decouple the two concerns: add `isTopLevel` (default true), separate from `selectedIndex`. Detail screens pass `isTopLevel: false` (keep the bar, but Back pops). The decision is extracted into a pure `AppShell.backAction` (drawer -> close; detail with a route below -> pop; else -> background), with an assert that a detail is actually poppable. Unit tests cover the matrix; widget tests exercise the real system-Back -> PopScope -> pop wiring. Follow-up #390 tracks the separate AppBar back-arrow path. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 months ago
Strycher	d68c6dfdd8	fix(#385 ): surface storage-init failure with a persistent warning When the database can't open (e.g. the native sqlite library fails to load), every read/write silently failed and the app opened to an empty, normal-looking screen — the user thinks their history was wiped (SAFELANE §6 violation). Probe the storage layer in main() before any store reads (BlobStore.verifyReadWrite). On failure, a StorageHealthService one-way latch records it, and a persistent, non-dismissable banner is shown above the whole app: history is not lost, storage is unavailable, messages are NOT being saved, restart after fixing. Cross-platform (probe goes through drift, covers web too). Tests: service state/latch + banner show/hide widget test. Gemini-reviewed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 months ago
Strycher	ad29ea3f0e	fix(#238 ): Enter selects the highlighted emoji/mention in autocomplete The autocomplete only completed an unambiguous emoji on Enter; ambiguous queries (e.g. `:shrug` with multiple matches) sent the literal text instead of the highlighted glyph, and mentions only selected via Tab. Enter now accepts the highlighted item (emoji or mention) like Tab, then sends; Tab still selects without sending, Esc dismisses to send literal text. Removes the now-dead _emojiQuery field. (#231, emoji + mentions per Ben) Widget tests: Enter inserts the highlighted emoji (ambiguous `:shr`) and the highlighted mention (`@Bo` -> @[Bob]). Part of #231. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 months ago
Strycher	d39893f120	feat(#235 ): show the reply-to chip above a reply-gif A reply prepends `@[Name] `, so a reply-gif renders the gif (prior commit); this adds the `@Name` reply chip above it so it is clear the gif is a reply. Extracts TranslatedMessageContent.mentionChip + leadingReplyName (shared by inline rendering and the reply-gif header); the channel bubble builder renders the chip above the GifMessage. DMs have no reply feature, so channel-only. Part of #232. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 months ago
Strycher	edd9530c25	fix(#235 ): render inline @[Name] mention chips + reply-gifs Two shared-root render gaps (message tokens were only matched at fixed positions): - TranslatedMessageContent: parse @[Name] anywhere (leading, inline, or repeated) and render each as a chip; messages without a mention keep full link support (#233). - GifHelper.parseGif: strip a leading `@[Name] ` reply prefix before matching so a reply-with-gif resolves to the gif instead of literal text; arbitrary text before a gif is still left as text (#232). Tests: parseGif reply/format cases + widget tests for inline/leading/multiple mention chips. Full suite 402 green. Part of #233, #232. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 months ago
Strycher	d2d7930858	fix(#155 ): manual path entry honors the configured path-hash width The "Set Path" dialog parsed, built, and displayed hop prefixes as a fixed 1 byte (substring(0,2)), so on a 2-/3-byte path-hash mesh manual entry produced wrong-width routing paths and the helper text claimed "1 byte". Make it width- aware from connector.pathHashByteWidth. - parsePathPrefixes(text, width, invalid): static + testable; each entry must be EXACTLY width*2 hex chars (wrong-length / malformed go to invalid, never silently truncated); width clamped >= 1. - _updateTextFromContacts / display / maxLength group by the configured width; the display substring is guarded against short keys. - show() takes pathHashByteWidth; the chat + path-management callers pass connector.pathHashByteWidth. - l10n: reworded the path-entry helper / example / instructions to be width- agnostic (dropped the "2 hex / 1 byte / first byte" claims). The 17 non-English locales keep their prior strings, flagged for re-translation (English fixed). analyze clean; 6 parsePathPrefixes tests (incl. exact-length + clamp). Gemini v1 BLOCKER (unguarded substring) + MAJOR (silent truncation) fixed; v2 MAJORs were the pre-existing refresh button (out of scope), v2 MINOR (1-byte example) fixed. Closes #155 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 months ago

19 Commits (efe4e6e5cbddcf0f3a3d00d941d714e2fa63c466)