3b00f9f893
Phase 6 of docs/subgroups.md. `DkgRitualViewModel.createAdminGroup` was 120 lines of room creation living in a view model, and a subgroup needs all of it with four different values. It moves to `managers/MarmotGroupCreation`, unchanged in behaviour, and the view model shrinks by 154 lines to the four values and a `when` over the result. The rules that were already right stay right for the subgroup for free, which is the whole reason to move rather than to write a second one: **Every key package before anything exists.** The id is derived, so there is exactly one room per key at a path; a half-created one occupies that address permanently and there is no second id to retry with. Better to create nothing and name who is missing. (Phase 7 will check this at the picker instead, so a subgroup does not discover it after three ceremonies -- this stays as the backstop.) **`adminPubkeys` baked into the epoch-0 group context** rather than added by a later commit, so a member welcomed afterwards gets a populated group instead of chasing a bootstrap commit that predates their membership. That is why `MarmotGroupData` is built by hand rather than through `MarmotGroupData.bootstrap`, which hardcodes a single admin. **`adopt` before the members are added.** Filing the key state is local and certain; adding members is a relay round trip that can partly fail. The room comes into existence already knowing what it signs with, whatever happens next. **Derived ids make every step reachable twice**, so `Existing` is a success rather than a refusal -- a second tap or another member getting there first should join what exists rather than mint a rival group on one address. Four outcomes instead of four scattered early returns: `Created` with the members who could not be added, `Existing`, `BlockedOn` with the missing key packages, and `Failed`. The view model keeps the one thing that was genuinely its own -- turning missing public keys into names, since "no key package for 3 people" is not actionable and "Bob needs to publish a key package" is. **It is reached through `ChatRepository.createMarmotGroup`, not called directly.** View models in this app talk to repositories and managers take the database; the first cut had the view model reaching for `dkgRepository.database`, which does not exist on the interface and should not. The repository method is three lines of delegation and keeps the boundary where the rest of the app has it. `parentChatRoomId` is the one genuinely new parameter, written onto the room after `getOrCreateChatRoom` returns rather than passed into it -- that call is shared with every other way a room appears and none of them has a parent to hand it. Nine imports the extraction made dead are dropped from the view model. 397 common tests, 701 jvm tests, `m3Audit` meets every budget. 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…