Join failures in mixed-client environments due to ratchet tree consistency drift

[gzuuus]

In dogfooding with mixed Marmot implementations, invitees sometimes receive and decrypt welcome events but fail to join the group.

Observed error (surfaced by joinGroupFromWelcome()):

Failed to join group with any matching key package. Last error: non-blank intermediate node must list leaf node in its unmerged_leaves

This points to strict ratchet-tree validation failure in ts-mls (see validateRatchetTree(), specifically the unmerged_leaves invariant around arraysEqual(...)).

---

Context

• Environment had multiple users/admins and mixed implementations.
• Some clients were known to do aggressive self-update behavior.
• Symptoms are consistent with state fork/drift around invite/join windows rather than transport/inbox failure.

---

Why this matters

A single divergent implementation can destabilize onboarding for new members by producing/propagating welcomes tied to inconsistent tree state. This creates poor interoperability and difficult-to-debug failures.

---

Analysis branch + doc

• Analysis branch: docs/invite-join-drift-analysis
• Detailed write-up: documentation/invite-join-drift-analysis.md

---

Likely root causes (ranked)

1. Ratchet tree consistency drift in mixed implementations (most likely).
2. Stale/divergent commit producer state under concurrent admin activity.

Contributors include:

• aggressive self-updates near join/invite timing
• concurrent membership-changing commits
• delayed/out-of-order ingestion
• implementation differences in sequencing/proposal handling

---

Proposed actions (future iteration)

1. Add structured typed join errors (e.g. WELCOME_TREE_INCONSISTENT) in joinGroupFromWelcome().
2. Add targeted join diagnostics (candidate refs, per-attempt inner errors, welcome/tree metadata).
3. Add optional interop-safe commit mode in MarmotGroup.commit() to serialize risky transitions.
4. Add drift/fork preflight checks before creating new commits.
5. Add welcome quality gates before send path around createWelcomeRumor().
6. Add quarantine policy for repeatedly incompatible client fingerprints.
7. Expand race/interop tests near ingest-commit-race.test.ts and end-to-end-invite-join-message.test.ts.

---

Non-goal

Do not weaken MLS validation to accept inconsistent tree states. The fix direction is stronger diagnostics, safer sequencing, and better interop guardrails.

[gzuuus]

Follow-up: deterministic reproduction findings and current assessment. Open pr with tests #60

Since the initial report, we expanded and ran a deterministic reproduction matrix in invite-join-drift-repro.test.ts using controlled scheduling via ScriptedMockNetwork.

What we validated

• We can deterministically trigger the exact ts-mls validation invariant class in the causality probe:
  • minimal ts-mls unmerged_leaves invariant trigger
  • invariant enforced in validateRatchetTree()
• We can reproduce a natural join failure path consistent with field symptoms:
  • R5 real-world sequence: buggy forked inviter emits welcome that fails natural join
• We added additional confidence scenarios (R6–R8) to separate signal from overfitting:
  • buggy/non-buggy non-admin update behavior
  • sequential invitees from buggy inviter
  • healthy regression path remains joinable

Conclusions

1. The observed failure is not just transport/inbox noise; it is consistent with ratchet-tree state inconsistency surfaced at join validation.
2. Mixed implementations with aggressive self-update behavior can produce tree states that fail strict joins in other clients.
3. This presents real interop fragility in realistic multi-admin / concurrent activity conditions.

Scope / precision

• This is strong evidence of an interop failure class.
• This is not yet a claim that healthy/unmodified Marmot alone spontaneously creates the corruption without a divergent peer.

Current reliability assessment

Under real mixed-client conditions, invite/join remains vulnerable to timing + state-drift interactions, and can be flaky during onboarding windows even when welcome delivery/decryption succeeds.

[erskingardner]

Hey @gzuuus thanks for running all the extra tests and making sure that our suspicion that it was related to self-updates just after joining. I'd love your thoughts on what the best next steps here are. We have turned off self-updates for the moment in whitenoise and we're planning to bring those back soon but I think we need to leave a bit of a time gap when you first join a group. So it might not be right after you join, but it might be the next app launch after you've joined a group. This sounds like it'll pretty much solve the problem you've outlined here, but I wanted to get your take.