mirror of
https://github.com/meshtastic/Meshtastic-Android.git
synced 2026-09-13 05:37:28 -04:00
James RichandClaude Sonnet 5
7201241030
Isolated the exact trigger of the previously-blocking "IllegalStateException:
:core:common is not configured for JS usage" error empirically: it's
webApp's binaries.executable() specifically, not wasmJs { browser() } in
general. Once any module in a multi-project build declares an executable
Kotlin/Wasm binary, KGP's root npm resolver (kotlinWasmNpmInstall)
requires EVERY module reachable from that binary's dependency graph to
also declare browser()/nodejs() -- bare wasmJs() no longer satisfies it.
Retrofitted wasmJs { browser() } onto all 18 wasmJs-enabled modules
(every core:* and feature:* module that previously stayed at bare
wasmJs()). An earlier attempt at this exact retrofit was reverted after
finding it arms wasmJsBrowserTest repo-wide with no karma/headless-Chrome
runner configured -- this time paired with a central disable in
KotlinAndroid.kt's configureKotlinMultiplatform() instead of reverting
the fix that actually solves the resolver conflict.
Two further, adjacent bugs surfaced once wasmJsBrowserTest's runtime
classpath actually existed for the first time (bare wasmJs() never
created one, so neither bug had ever fired before):
- ProjectExtensions.kt's configureTestOptions() was unconditionally
injecting the JVM-only junit-platform-launcher into every
"*TestRuntimeClasspath" configuration, including wasmJs's -- excluded
wasmJs* configurations from that injection.
- Compose Multiplatform's plugin registers
checkComposeUiTestConfigurationForWasmJs unconditionally on every
Compose-enabled module with wasmJs { browser() }, regardless of
whether it has real Compose UI tests (none of ours do) -- disabled
centrally alongside wasmJsBrowserTest.
:webApp:wasmJsBrowserDistribution -- previously never even attempted in
the live build -- now succeeds and produces a real, loadable browser
bundle (webApp/build/dist/wasmJs/productionExecutable/). Getting there
also required relaxing settings.gradle.kts's repositoriesMode from
FAIL_ON_PROJECT_REPOS to PREFER_SETTINGS (a deliberate supply-chain
policy change, not incidental config) plus three settings-level,
content-filtered ivy repos for Kotlin/Wasm's NodeJs/Yarn/Binaryen setup
tasks (nodejs.org/dist, yarnpkg releases, WebAssembly/binaryen releases)
-- those setup tasks register their own project-level ivy repos, which
PREFER_SETTINGS ignores in favor of a settings-declared equivalent
rather than erroring outright the way FAIL_ON_PROJECT_REPOS does. The
content filters on each repo (includeModule) are what preserve
FAIL_ON_PROJECT_REPOS's original centralization intent: every repository
a build can pull from is still declared in exactly one place.
kotlin-js-store/wasm/yarn.lock is KGP's own generated lockfile for the
resolved npm/yarn dependency versions, committed per upstream convention
for reproducible builds.
Full repo baseline gate (spotlessCheck detekt assembleDebug test
allTests) passes clean with :webApp present in the build graph.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
:core:database
This module provides the local Room database persistence layer for the application using Room Kotlin Multiplatform (KMP).
Key Components
MeshtasticDatabase: The main Room database class, defined incommonMain.- DAOs (Data Access Objects):
NodeInfoDao: Manages storage and retrieval of node information (NodeEntity). Contains critical logic for handling Public Key Conflict (PKC) resolution and preventing identity wiping attacks.PacketDao: Handles storage of mesh packets, including text messages, waypoints, and reactions.
- Entities:
NodeEntity: Represents a node on the mesh.Packet: Represents a stored packet.ReactionEntity: Represents emoji reactions to packets.
Security Considerations
Public Key Conflict (PKC) Handling
The NodeInfoDao implements specific logic to protect against impersonation and "wipe" attacks:
- Wipe Protection: Receiving an
is_licensed=truepacket (which normally clears the public key for compliance) will not clear an existing valid public key if one is already known. This prevents attackers from sending fake licensed packets to wipe keys from the DB. - Conflict Detection: If a new key arrives for an existing node ID that conflicts with a known valid key, the key is set to
ERROR_BYTE_STRINGto flag the potential impersonation.
Dependency Graph
graph TB
:core:database[database]:::kmp-library
:core:database --> :core:common
:core:database --> :core:model
:core:database -.-> :core:di
:core:database -.-> :core:resources
:core:database -.-> :core:testing
classDef android-application fill:#CAFFBF,stroke:#000,stroke-width:2px,color:#000;
classDef android-application-compose fill:#CAFFBF,stroke:#000,stroke-width:2px,color:#000;
classDef compose-desktop-application fill:#CAFFBF,stroke:#000,stroke-width:2px,color:#000;
classDef android-feature fill:#FFD6A5,stroke:#000,stroke-width:2px,color:#000;
classDef android-library fill:#9BF6FF,stroke:#000,stroke-width:2px,color:#000;
classDef android-library-compose fill:#9BF6FF,stroke:#000,stroke-width:2px,color:#000;
classDef android-test fill:#A0C4FF,stroke:#000,stroke-width:2px,color:#000;
classDef jvm-library fill:#BDB2FF,stroke:#000,stroke-width:2px,color:#000;
classDef kmp-feature fill:#FFD6A5,stroke:#000,stroke-width:2px,color:#000;
classDef kmp-library-compose fill:#FFC1CC,stroke:#000,stroke-width:2px,color:#000;
classDef kmp-library fill:#FFC1CC,stroke:#000,stroke-width:2px,color:#000;
classDef unknown fill:#FFADAD,stroke:#000,stroke-width:2px,color:#000;