0690932252
Phase 1 of docs/subgroups-multiple-parents.md, the wire. It ships dark: the event can now state a lineage of any size and nothing in this build produces one of more than one, because the row that would hold it does not exist until the next phase. A room's lineage was never really a field. `GroupKeyState` carried one parent and one certificate because a group was founded with a parent and never gained another; the moment it can be adopted, "the parent" is a set that had only ever held one thing. **`SubgroupLineage` is that set, and it holds the two invariants a caller cannot be trusted to remember.** No parent twice -- two entries naming one group is one parent asked twice, and `of` refuses rather than folding them, because each carries its own certificate and picking one would be this device deciding which of the parent's statements counts. And one canonical order, sorted by parent id, so two devices assembling the same lineage from the same certificates emit the same bytes. `plus` and `minus` are the two edits an adoption and a disavowal make; `minus` returning null is "nobody's child" rather than a failure, and revokes nothing -- a certificate is a signature and exists forever, and what it removes is the child's half of the link, which is the half that decides. **The pairs are adjacent, and that is for other people's builds.** A reader that predates this takes the first `parent_group` and the first `birth_certificate` off the tags and checks them against each other. Emitted as `id, certificate, id, certificate` it gets one real parent and that parent's own certificate, verifies them, and files a true but partial lineage -- one parent, correctly. Emitted as all the ids and then all the certificates it would pair the first id with a certificate that may belong to another parent, fail `certifies`, and drop the **whole state** -- losing the row that says which ceremony's share signs for that room, which is a worse outcome than not knowing about the second parent. The sort is what makes the pairing deterministic rather than incidental. **`parseLineage` counts each half twice, by tag name and by successful parse.** A half that is present and broken reads as absent through a parser, and only the broken kind would slide the pairing along by one and pair an id with somebody else's certificate. So an uneven number of halves, a half that does not parse, and a repeated parent are all refused, and `claimsParentage` -- unchanged, reading tag names alone -- is still what tells "claims nothing" from "claims something unreadable". **Two places refuse a second parent for now, and say so rather than truncating.** `propose` checks the lineage is one before it builds a row that can only hold one, and `parentageOf` drops a state claiming more. Taking the first of two would file a lineage the group did not sign and leave the device believing a group has one parent while its own members see two -- the same reasoning the existing all-or-nothing rule is built on. Nothing emits a second yet, so neither fires except on a state from a newer build, which is exactly the case that wants refusing rather than guessing. `SubgroupParentage` is untouched: still one pair, still unchecked, still the thing a lineage is made of. Nineteen tests. `SubgroupLineageTest` is new and pure, with no crypto at all -- the certificates in it are deliberately nonsense, because whether one is good is `certifies`' question and is asked on every read rather than at the door; it pins the two invariants, case-insensitivity on both, and that a certificate rides along with its own parent through the sort. Five go to `GroupKeyStateTest`, and the one worth keeping if any of this is rewritten asserts the *tag order* and then that the first id and the first certificate an older reader would take are a matched pair. 443 common tests, 933 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…