meshcore-client

Commit Graph

Author	SHA1	Message	Date
diffwireauto	3a0ad8f273	feat(#750 ): separate what a node calls itself from what the user calls it Task 750.1 of the contact-naming plan: model and storage. Stock MeshCore has a per-node CUSTOM NAME field and keeps the original underneath; Offband could not rename a contact at all. Contact gains receivedName (the name the mesh gave us, wire and storage) and customName (the user's label, client-side only). name becomes a getter returning customName ?? receivedName, so all 85 existing display reads stay correct and a future read cannot forget. Empty and whitespace-only custom names count as unset at both the getter and the store, so clearing the field cannot leave a contact blank with no way back. The constructor and copyWith take receivedName, which made the rename a compile error at every write site. The compiler enumerated 23 of them across 5 lib files and 11 test files; none was found by reading. The advert handler is the one that matters: receivedName now updates while customName is untouched, so an advert improves accuracy without moving what the user sees. That was the defect making a client-held name impossible. customName is deliberately NOT in contact_store. That record is rebuilt from radio contact-sync data where no custom name exists, so a save after a sync would wipe it. It lives in contact_settings_store keyed by pubkey hex, which a sync cannot reach. Both stores persist receivedName, never the getter. The plan's correction on #750 found that persisting the getter is one-way data loss: the custom name would be read back as the received name and the real one destroyed with no advert able to restore it. The ?? 'Unknown' fallback is kept with a comment, since the rename is exactly the edit that drops a trailing fallback and would crash the load for a legacy row. 19 tests, positive and negative. T31 and T32 were falsified before being trusted: breaking the persist and the fallback made exactly those two fail and nothing else. Gates: analyze --fatal-infos --fatal-warnings clean, dart format 0-changed, 1305 tests passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
Strycher	2f1048e7be	fix(#495 ): send routed paths at the contact's width, not width 1 resolvePathSelection returned no width and, on the override branch, a byte count in place of a hop count. preparePathForContactSend then called setContactPath without a width, so encodePathLen packed mode bits 00 and a 2-byte route went out as twice as many 1-byte hops (path_len 0x06 for a 6-hop 2-byte route instead of 0x46). The radio routed on wrong 1-byte prefixes, confirmed on Bandit's 2026-08-01 log and via CoreScope. Direct and flood were immune because neither uses the path bytes. PathSelection now carries hashWidth and a true hop count on every branch, using the contact's pathHashWidth as the single width authority. Both setContactPath call sites thread it. Also addresses the override timeout inflation half of #299 (hopCount was a byte count feeding calculateTimeout). Gemini review found two override/history width edge cases -> split to #494. Refs #299 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	3 months ago

Author

SHA1

Message

Date

diffwireauto

3a0ad8f273

feat(#750 ): separate what a node calls itself from what the user calls it

Task 750.1 of the contact-naming plan: model and storage. Stock MeshCore has a per-node CUSTOM NAME field and keeps the original underneath; Offband could not rename a contact at all.

Contact gains receivedName (the name the mesh gave us, wire and storage) and customName (the user's label, client-side only). name becomes a getter returning customName ?? receivedName, so all 85 existing display reads stay correct and a future read cannot forget. Empty and whitespace-only custom names count as unset at both the getter and the store, so clearing the field cannot leave a contact blank with no way back.

The constructor and copyWith take receivedName, which made the rename a compile error at every write site. The compiler enumerated 23 of them across 5 lib files and 11 test files; none was found by reading. The advert handler is the one that matters: receivedName now updates while customName is untouched, so an advert improves accuracy without moving what the user sees. That was the defect making a client-held name impossible.

customName is deliberately NOT in contact_store. That record is rebuilt from radio contact-sync data where no custom name exists, so a save after a sync would wipe it. It lives in contact_settings_store keyed by pubkey hex, which a sync cannot reach.

Both stores persist receivedName, never the getter. The plan's correction on #750 found that persisting the getter is one-way data loss: the custom name would be read back as the received name and the real one destroyed with no advert able to restore it. The ?? 'Unknown' fallback is kept with a comment, since the rename is exactly the edit that drops a trailing fallback and would crash the load for a legacy row.

19 tests, positive and negative. T31 and T32 were falsified before being trusted: breaking the persist and the fallback made exactly those two fail and nothing else.

Gates: analyze --fatal-infos --fatal-warnings clean, dart format 0-changed, 1305 tests passed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Strycher

2f1048e7be

fix(#495 ): send routed paths at the contact's width, not width 1

resolvePathSelection returned no width and, on the override branch, a byte
count in place of a hop count. preparePathForContactSend then called
setContactPath without a width, so encodePathLen packed mode bits 00 and a
2-byte route went out as twice as many 1-byte hops (path_len 0x06 for a
6-hop 2-byte route instead of 0x46). The radio routed on wrong 1-byte
prefixes, confirmed on Bandit's 2026-08-01 log and via CoreScope. Direct
and flood were immune because neither uses the path bytes.

PathSelection now carries hashWidth and a true hop count on every branch,
using the contact's pathHashWidth as the single width authority. Both
setContactPath call sites thread it. Also addresses the override timeout
inflation half of #299 (hopCount was a byte count feeding calculateTimeout).

Gemini review found two override/history width edge cases -> split to #494.

Refs #299

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2 Commits (43ec4d2fa3aaa36d8ea786d145268b8a2bf3f070)