8d1e341131
One optional tag -- `["subgroupFor", "<kind>", "<id>"]` -- and it is the whole of the link between a subgroup and the dialect, artifact, translation or project it was made for. The certificate is the only artefact in the relationship that is signed, travels, and is already read on both sides, so the link goes there rather than in a local column nobody else can see or a room name that is not an identity. The signature already covers the tags, since an event id hashes over them, so nothing is added to the claim by putting it there -- only to what a parent admin can see before agreeing. That is the same bargain `SubgroupKeyTag` made. Both halves or neither. An id alone would have to be looked up in four tables to be understood, and a reader without the kind cannot tell "a project this device does not hold" from "not a project at all"; a kind alone names a category. The pair follows `PayloadKindTag`/`PayloadIdTag`, which carry the same two for the same reason. The tag sits after the named tags and before the run of `p` tags, and the position is load bearing rather than incidental: a reader that predates this takes the tags it knows off the front and ignores the rest, while one inserted into the admin run would split the founding roster for anybody reading positionally. `SubgroupLineage` fixes its order for the same kind of reason, and a test asserts the position rather than trusting the comment. `certifies` is untouched, and that is the point of the third test. The origin joins the name and the `p` tags as founding history: a certificate may name a row this device will never hold, because a subgroup's members need never have been in the parent, and a certificate with no origin at all is valid because every one signed before today has none. What the quorum signs is the intention that the room be for that entity; nothing vouches that the entity exists, and nothing can. Phase 4 of docs/subgroups-for-entities.md. 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…