de4f15794a
The platform's server schema has had `project` and its two join models since before this app existed. Bringing them here is not a port: the server answers "whose project is this" out of a table of accounts, and this app is a group with no accounts, no server and no authority but a quorum of its own members. So every foreign key on `project` is re-answered. The creator becomes a `creator` tag and the owners a set of `p` tags with an owner role -- written into the template before it is proposed, so they are inside the id the quorum signs rather than one device's note about who inserted a row. The owner of record is still structurally the room, and `chatRoomId` carries that; the tags are what let a project be the group's work and somebody else's property. Campaign is out of scope entirely. Two things the plan is mostly about, because neither is recoverable from the code. The nip30303 kind band is not merely full -- 30310, 30311 and 30312 are double-booked with the ceremony family, survivable only because none of the three nip30303 kinds has a producer -- so projects take 30330-30332 and the collision gets written down. And `ContributorTag.parse` drops a role that is not in `KNOWN_ROLES`: the tag parses, the role comes back null, the string stays inside the signed event id, the event still verifies, and the project lands with no owners. Nothing is logged. `ROLE_OWNER` reaching that set is Phase 1's first line, and three tests point at it. Ten phases, 0-7 to build and 8-9 deferred. The one decision to make before Phase 1 is the scope fork: a project's contents are same-room, with real foreign keys, because the FK is what makes a bad proposal fail loudly. Cross-room is Phase 9 and follows `parentChatRoomId`'s precedent -- a plain column, never a foreign key, because a dangling value is the normal state. 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…