b54ff61eb6
Phase 4 of docs/subgroups-multiple-parents.md, the operations. Two signings and no
ceremony, which is the whole of why this is cheap: the key exists, so there is no
ChillDKG, and the room exists, so there is nothing to create. Still unreachable -- no
screen offers any of it yet.
```
1. birth certificate, in the adopting group -> its quorum signs the child's id
2. key state, in the child itself -> the child's quorum re-announces,
carrying every certificate it accepts
```
**The order is forced and it decides who is deciding.** The key state carries the
certificate, so the certificate has to exist first -- which means the parent commits
first and the child answers second. Step 1 is an offer; step 2 is the acceptance, and
it is the only half that settles anything. Picking a parent is not choosing on the
child's behalf, and the wording of every message here says so.
**`proposeAdoption` is the founding certificate with the child already there.** Same
kind, same six checks on the other side, same room it has always been proposed in. What
differs is that the child's id and threshold key are read off its key state rather than
derived from a ceremony this device may not hold. The roster and the name are the
child's *current* ones -- on a founding certificate they are the founding roster
because there is nothing else they could be, and here the adopting group's admins are
being asked about a group that exists, so what they can weigh is who runs it now. Still
frozen the moment they are signed, and still never read as a live roster.
**`proposeAcceptance` carries the resulting set, not the addition.** The footgun is
real: a key state is replaceable and the newest wins *wholesale*, so a state naming
only the new parent would silently drop every existing one. The current lineage is read
off the row here rather than taken from the caller, and `SubgroupLineage.plus` is what
makes an addition an addition. It signs in the child's **own** room, which it can
because the room exists -- `propose`'s first branch holds and `signingPath` resolves off
the child's own key state, neither of which founding can do.
**`proposeDisavowal` is the same act with the set the other way**, and it revokes
nothing. A certificate is a signature and exists forever; what this removes is the
child's half of the link, which is the half that decides, since a lineage is what the
child's quorum most recently declared. The parent's own list does not follow --
`subgroupsOf` reads that group's certificates -- and the comment says so where somebody
will wonder.
**`refuseAdoption` is seven refusals and the picker is the same function.**
`adoptingCandidatesFor` filters the active profile's rooms through the guard itself
rather than through a copy of its rules, so screen and manager cannot drift. The list is
the profile's own rooms and cannot be anything else: a certificate is proposed inside
the adopting group, so a candidate has to be a room the key in the chair can act in, and
`getChatRoomListByUserPublicKey` is keyed by identity. An empty answer is a fact about
the member rather than a failure -- the remedy is a person, not a button.
Two refusals are new in kind. "This group has not agreed what it signs with" is the
overlap requirement surfacing: the certificate carries the child's threshold key, which
only the child's members hold, so a would-be parent with no sight of it cannot certify
anything. And a cycle check, because a lineage is a DAG now rather than a tree -- with
one parent nothing was ever tempted to recurse. `isAncestorOf` is depth-bounded and
visited-set guarded; it is advisory, since a device sees only the lineages it holds
states for, and the real protection is that an adoption needs the child's own quorum.
Fifteen tests. Every refusal once, including the cycle and the picker's filter, and then
the three operations by reading the proposed event back out of the signing session --
which is what catches the wholesale-replacement footgun: accepting a second parent has
to carry the first, and disavowing the only one has to leave a state that claims none
rather than one that claims nothing readable.
`parentWith` is now one case of a `marmotRoom` helper taking the id and the key, since
adoption needs two real group rooms at once rather than one; it keeps its own doc
comment and the warning it carries about `nostrGroupId` lengths, which is still the trap
it was. `certificate` gains a parent id so a sibling group can sign one.
454 common tests, 962 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…