Fork Scenarios in Marmot

[erskingardner]

ℹ Pasting this here (from @gzuuus originally in Signal) so we can discuss more

The Hidden Problem in Decentralized Group State

Marmot's current approach handles commit conflicts with a deterministic tiebreaker: earliest timestamp wins, with event ID as final tiebreaker. This works perfectly—until it doesn't. The real danger isn't conflicting commits; it's silent divergence.

Imagine three relays with intermittent connectivity. Admin sends Commit A to Relay A and Commit B to Relay C, both for epoch 5. Clients on Relay A apply Commit A. Clients on Relay C apply Commit B. Both groups think they're at epoch 5, but they have different states. No one knows they've diverged until messages fail to decrypt and users think something is broken.

Why Parent References Matter (And Why They're Not About Ordering)

If two commits reference the same parent, the DAG doesn't tell you which one to choose. You still need a tiebreaker. Parent references don't solve the ordering problem.

But they can solve something crucial: fork detection.

When Commit A and Commit B both reference the same parent, clients can recognize: "This is a fork." Instead of silently choosing one and discarding the other, they can enter a "recovery mode", track both branches temporarily, and make an informed decision based on subsequent activity or protocol conventions.

The 'e' Tag Approach: Lightweight Fork Detection

We can add fork detection with minimal protocol changes by using an e tag in Group Events to reference the previous commit:

{
  "kind": 445,
  "tags": [
    ["h", "group_id"],
    ["e", "previous_commit_event_id"]
  ]
}

This is backward compatible—old clients ignore it, new clients use it to build a commit graph. The cost is one 64-byte tag per commit.

How Fork Recovery Works in Practice

When a client detects two commits for the same epoch with the same parent reference, it enters a recovery window. During this window:

1. Track both branches instead of discarding one
2. Monitor subsequent activity on each branch
3. Choose the branch with more consensus—more subsequent commits, more participants, protocol conventions
4. Re-apply valid proposals from the abandoned branch

This turns silent divergence into a temporary, self-healing condition. Other protocol conventions can be applied to determine how to resolve the fork condition, like an admin publishing which branch is current, or any other convention.

Real-World Scenarios

The Three Relay Problem: In a fragmented relay network, different relays may deliver commits in different orders. Without fork detection, clients silently diverge. With parent references, they detect the fork and converge based on actual activity or protocol conventions.

Rapid-Fire Commits: When multiple admins send commits in quick succession, parent references help clients understand the intended order, even if relays deliver them out of sequence.

Benefits of This Approach

For Users: More reliable group messaging, better handling of network issues.

For Developers: Clear protocol for handling edge cases, deterministic behavior, easier debugging of sync issues.

For the Protocol: Moves from best-effort consistency to more robust eventual consistency.

The Key Insight

Timestamps work for ordering, but they don't help you know when you need to order. Parent references give clients the context to recognize forks and the information to recover from them intelligently.

This isn't about replacing the current tiebreaker—it's about detecting when the tiebreaker has created divergence and recovering gracefully.

The cost is minimal (one tag). The benefit is a protocol that handles real-world network conditions rather than assuming perfect relay behavior.

[erskingardner]

I'm still very unconvinced that this is a real issue that isn't handled already by the spec:

What the Current Spec Already Does

The current Marmot spec (MIP-03) addresses commit conflicts with:

1. Deterministic tiebreaker: Earliest timestamp wins, with event ID as final tiebreaker (MIP-03:117-121)
2. Commit/Welcome ordering: Commits MUST be confirmed before Welcomes are sent (MIP-02, MIP-03:101-111)
3. State retention recommendation: "Clients SHOULD retain previous group states temporarily to enable recovery from forked states" (MIP-03:122)

When the proposal says:

"Admin sends Commit A to Relay A and Commit B to Relay C, both for epoch 5."

This is not a realistic scenario under the current protocol. Here's why:

1. MLS epoch semantics: An admin cannot create two different commits for the same epoch. Once you create a commit that advances epoch 4→5, you've consumed that epoch transition. To create another commit, you'd need to either:
   • Apply the first commit (now at epoch 5), then create a commit for epoch 5→6
   • Discard the first commit entirely and create a new one
2. The real risk: The actual race condition is when two different admins each create a commit from the same epoch (both see epoch 4, both create epoch 4→5 commits). This is handled by the timestamp/ID tiebreaker.
3. Relay fragmentation: If clients are on different relays and only see one commit, they'll apply the same deterministic rules to whatever commits they eventually see. The issue isn't fork detection - it's eventual delivery. This is why groups have an explicit set of relays the group operates on. Clients know where to look for commits.

I think that you have correctly identified that clients might not know they've diverged. If Client A only sees Commit X and Client B only sees Commit Y, they each think they're correct. But parent references don't fundamentally solve this - they just let you know "there was a fork" if you see both commits. But if you see both commits - you ALREADY know this. The current tiebreaker already handles this - you apply the winner and discard the other. In the case where you only see one commit: A parent reference doesn't help because you don't know there's another commit to compare against.

[gzuuus]

Hey, thanks for the detailed feedback. After revisiting this, I think your main point is correct, parent references don’t solve the fundamental conflict problem. When two admins create competing commits from the same epoch, we still need the deterministic tie‑breaker.

The narrower benefit I still see is operational: if commits reference their immediate parent commit ID, then when a client does eventually observe both commits, it becomes explicit that they are siblings from the same parent. That doesn’t change what the client applies (the current rules still pick the winner), but it does make it easier to explain what happened in logs/UX, and also make the “retain previous states temporarily” less arbitrary, clients can keep the small set of states that are actually parents of recently seen commits (plus a buffer), rather than guessing a fixed number of epochs/time.

So this is more of a cheap interoperability/debugging hint. If you think the additional complexity isn’t worth it, I agree the current spec is already coherent, and the higher‑impact improvement would be to tighten the retention/recovery mechanisms