52 Commits

Include renames

Author	SHA1	Message	Date
Kgothatso NgakoandClaude Opus 5	8fc1c9e650	fix: stop deferring the first invitee's welcome behind a commit nobody needs ... `inviteMember` now works out for itself whether the group it is adding to has anybody to inform: val isOneMemberInitialGroupCreation = mlsGroup.members().size == 1 read before `addMember` advances the tree. The parameter is gone from the signature and no caller passes it any more. Callers were the wrong place for this decision and both of them got it wrong. `inviteMemberToChatRoom` hardcoded `false`, and `ChatRepository.inviteMember` did not expose it at all, so every invite made through a group -- room creation in SelectChatRoomTypeViewModel, and the #admins room -- took the deferred-welcome path. That includes the first invite, when the group is still only its creator, at which point: - the commit has no audience. No other member exists, and nobody outside the group can decrypt it, so it is noise on the relay. - the welcome is then withheld until a relay acknowledges that noise. If the ack never lands, the first invitee receives nothing at all. Only createMlsDirectMessageChatRoom passed `true`, and only because a DM has exactly one invite. A group of n has one such invite too -- the first -- and it was not getting it. The condition is right at any size, not just for DMs: "the group has nobody to inform" is true exactly once. Invite two sees one member who must advance, invite three sees two, and so on. Their commits are encrypted with `commitResult.preCommitExporterSecret`, the epoch the earlier invitees received in their own welcome, so they can decrypt and advance. `members()` skips empty leaves, so this also stays correct for a group that has had members removed. ## What this does and does not fix It removes a pointless commit and, with DefaultDMRelayList now a single relay, a single point of failure sitting in front of every group's first member. It also narrows a silent race rather than closing it. MarmotInboundManager refuses future-epoch messages outright on both wire formats -- no queue, no replay -- so a commit arriving before its recipient's welcome is dropped and that member never advances, while the coordinator sees a successful invite. Previously both commits went out before either welcome; now welcome 1 is sent before commit 2 exists, so the first invitee is already at the right epoch. For n >= 3 the window between welcome 1 and commit 2 remains. Closing it needs the adds batched into one commit, which is the outstanding work described in docs/marmot-membership.md. That doc is updated here to describe the derived flag as current behaviour rather than a proposal, and to keep batching as the remaining item. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-05 14:44:28 +02:00
Kgothatso NgakoandClaude Opus 5	b99cb8fcd5	docs: write down the shared-key subsystem and how Marmot membership fails ... First docs in the repo -- README.md is still the stock KMP template. Three documents plus an index, covering the parts whose behaviour is not recoverable by reading the code: where the reasoning lives in a protocol, where a failure mode is silent, or where a decision looked arbitrary and was not. marmot-membership.md is the one that earns its place. Everything about adding a member compiles, the invite reports success, and a member simply never appears -- and the reason is never in the invite code. It records that inviteMemberToChatRoom hardcodes isOneMemberInitialGroupCreation = false and that ChatRepository does not expose it, so every group invite takes the deferred-welcome path including the first, when the group is still just its creator and the commit has no audience at all. Then why that is silent rather than noisy: MarmotInboundManager refuses future-epoch messages outright, on both wire formats, with no queue and no replay, so a commit arriving before its recipient's welcome is dropped and that member never advances. EPOCH_RETENTION_WINDOW retains past epochs and does nothing for messages from ahead. Three options are set out with the per-invite correctness table, including the honest limit that the recommended one narrows the race without closing it. shared-key-derivation.md argues why the paths are not BIP32 -- no chain code exists, hardened derivation is impossible rather than unimplemented, and a FROST tweak takes the scalar as input so the chain code leaves the problem entirely. It records the x-only serialisation trap avoided by choosing the scalar directly, and states the rule that must not be broken: never reconstruct a derived key in the clear, because k = k' - t hands over the group key rather than one derived key. shared-key-ceremony.md covers the seven kinds, the three approval gates and why the coordinator's aggregations are deliberately not among them, faults as values rather than exceptions, and the transcript's idempotency-by-construction. It also writes down the invariant that produces no error when broken: pendingApproval must mirror the gates in advance, or the screen offers an approval that does nothing -- or none while the ritual sits still. Every factual claim was checked against the source rather than recalled, which turned up one correction worth having: there are two future-epoch refusals, for PrivateMessage and for Commit, so the drop covers both wire formats and not just one. Each document leads with the failure mode rather than the architecture, on the grounds that a failure is what sends somebody to docs in the first place, and each lists its known gaps -- including that none of this has run on a physical device. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-05 14:39:19 +02:00