39fb64b6c0
The app has carried its own `LocalKeyManager.nostrPublicKey()` in WalletManagerExtension.kt since before the library's returned anything usable: the library's gave back `publicKey().toHex()`, the 33-byte compressed encoding, so the app went through quartz -- `KeyPair(privKey).pubKey.toHexKey()` -- to get the x-only key that relays, events and npubs actually carry. As of lightning-kmp-app 84cc44c the library's returns the x-only key too, and the app's copy is a second implementation of the one value that is every profile's identity. This deletes it and switches its three callers -- RelaysSocketManager, NavigationViewModel, CreateProfileViewModel -- to `fr.acinq.phoenix.managers.nostrPublicKey`. **The two were proved equal before anything was deleted, not read to be.** They go through different stacks (quartz's `KeyPair` against bitcoin-kmp's `xOnly()`), and a difference between them would not fail a build or a test: it would publish every existing profile under a new key on the next launch, with nothing on screen to say so. So the first form of the test in this commit built one `LocalKeyManager` from NIP-06's mnemonic exactly as CreateProfileViewModel does -- `NodeParamsManager.chain`, `NodeParamsManager.remoteSwapInXpub` -- and called both functions on it, the library's imported under an alias because the names collide. Equal on mainnet, which is what the app ships on, and equal on Testnet3, where the library derives from account 1' instead of 0'. Only then did the app's go. **What remains is a pin from the consuming side, anchored to NIP-06 rather than to a captured output.** A value copied out of a passing run pins the code to itself; NIP-06 publishes two test vectors -- a twelve-word and a twenty-four-word mnemonic, empty passphrase, path m/44'/1237'/0'/0/0 -- and that path is the library's mainnet path exactly, so on the chain the app ships on the answer is not ours to choose. Both vectors are asserted, and the test also asserts that `NodeParamsManager.chain` is Mainnet, so a chain change surfaces here as the moment the published answers stop applying rather than as two mysteriously failing assertions. **Quartz stays in the test, as an oracle rather than as an implementation.** The app signs events with quartz from `nostrPrivateKey()`, and the key it publishes has to be the one quartz derives for the secret it signs with; that agreement was the property the deleted copy embodied by construction. It is now stated once, on mainnet and on Testnet3 -- alongside the shape check, sixty-four lowercase hex characters, which is the line a revert to the compressed form (sixty-six) would trip. Off mainnet there is no published vector for account 1', so shape and quartz-agreement are all that is asserted there. **The test lives in `managers`, not `extensions`.** Its first form sat beside the function it was checking, in `press.mantra.compose.extensions`. With that function gone, a test in that package would be about an extension the app no longer has; `press.mantra.compose.managers` mirrors `fr.acinq.phoenix.managers`, the library package it pins, and is where the app's other key-material tests sit. The import in each caller is placed inside the file's sorted `fr.acinq.phoenix` block rather than where the old `press.mantra` line stood. :composeApp:compileDebugKotlinAndroid is clean; :composeApp:jvmTest is 736 tests, 0 failures -- the 733 before this change plus the three here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This is a Kotlin Multiplatform project targeting Android, iOS, Desktop (JVM).
-
/composeApp is for code that will be shared across your Compose Multiplatform applications. It contains several subfolders:
- commonMain is for code that’s common for all targets.
- Other folders are for Kotlin code that will be compiled for only the platform indicated in the folder name. For example, if you want to use Apple’s CoreCrypto for the iOS part of your Kotlin app, the iosMain folder would be the right place for such calls. Similarly, if you want to edit the Desktop (JVM) specific part, the jvmMain folder is the appropriate location.
-
/iosApp contains iOS applications. Even if you’re sharing your UI with Compose Multiplatform, you need this entry point for your iOS app. This is also where you should add SwiftUI code for your project.
Build and Run Android Application
To build and run the development version of the Android app, use the run configuration from the run widget in your IDE’s toolbar or build it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:assembleDebug - on Windows
.\gradlew.bat :composeApp:assembleDebug
Build and Run Desktop (JVM) Application
To build and run the development version of the desktop app, use the run configuration from the run widget in your IDE’s toolbar or run it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:run - on Windows
.\gradlew.bat :composeApp:run
Build and Run iOS Application
To build and run the development version of the iOS app, use the run configuration from the run widget in your IDE’s toolbar or open the /iosApp directory in Xcode and run it from there.
Learn more about Kotlin Multiplatform…