docs: research branch for decentralized consistency analysis#59
docs: research branch for decentralized consistency analysis#59gzuuus wants to merge 4 commits intomarmot-protocol:masterfrom
Conversation
WalkthroughAdds staged activation, bounded catch-up, and uncertainty/quarantine semantics for joins and commits; distinguishes Welcome transport wrapper from inner rumor and exposes optional epoch/diagnostic hints; reframes Commit handling as a convergence problem; adds a decentralized consistency analysis doc and expands the threat model with join/tree failure modes. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
erskingardner
left a comment
erskingardner
left a comment
There was a problem hiding this comment.
Overall I agree that we could more strongly word the point about commit hygiene when joining a group or coming online after a period of inactivity but I HATE the idea of creating a protocol defined state machine for this. It's way way too prescriptive and YAGNI.
The issue that caused this in the first place was that MDK was not paying close enough attention to the fact that when you joined a group in Epoch N, there might be more commits waiting for you already that you would need to process BEFORE you created your self-update commit. That was poor design and caused all clients using MDK to do dumb things.
We can solve this by simply being more clear about that - and making sure that MDK and marmot-ts are doing it the right way.
- Simplify welcome processing by removing mandatory parent commit binding - Replace PendingJoin/StateUncertain states with simpler "bounded best-effort sync" guidance - Add epoch_authenticator as optional confirmation signal for Welcome-epoch consistency - Update threat model to reflect new sync-before-send discipline - Clarify that parent commit hints in Welcome rumors are diagnostic only
|
Hey! Yes, I agree that the state machine approach was too prescriptive to be a protocol level requirement. I added it as a way to have a clearer mental model for dealing with drift or divergence, but you are right, that's not the best approach. Instead, we can have a clearer post welcome guidance or checks. I've updated the research document and materialization in the MIPS attaching your comments. Beyond that, I don't think we should overlook this. It is true that this research was motivated by the bug in MDK that was aggressively self updating, but it also highlighted that, in real world scenarios, these kinds of divergences can occur, especially since Nostr relays function as an unordered dissemination layer, and we expect Marmot to be interoperable across different clients and implementations. I think there's value in finding the right balance in the spec so we do not overstate the challenges of making MLS workable over Nostr, which presents huge challenges, especially for mobile clients, multiple implementations, and large groups. That said, I've updated the research document and removed weaker details and prescriptions. I also discovered the I would love to keep discussing this, and get your feedback. But remember, this is ongoing research and not something I am proposing as an addition to the protocol yet, at least until we find the right balance. Once we reach that point, we can finalize its addition to the spec |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
03.md (1)
166-169:⚠️ Potential issue | 🟠 MajorClarify normative precedence for the initial-commit relay exception.
Line 166 introduces a new exception that can conflict with existing “Commit events must be published” wording in MIP-01. Please explicitly state that this section supersedes that rule for initial single-member group creation, or add an explicit cross-reference note in both specs to avoid implementer divergence.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@03.md` around lines 166 - 169, State explicitly that the "Exception - Initial Group Creation" section supersedes the MIP-01 rule "Commit events must be published" for the specific case of initial single-member group creation: add a sentence like "For initial single-member group creation, this exception supersedes the MIP-01 requirement that commit events must be published." Also add reciprocal cross-reference notes: in MIP-01 add a parenthetical pointer to the "Exception - Initial Group Creation" explaining the narrow exception, and in the current section reference MIP-01 by name to avoid implementer divergence (mention the section title "Exception - Initial Group Creation" and the rule "Commit events must be published" to locate the text).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@02.md`:
- Around line 60-62: Example uses non-normative tags "commit" and "epoch" while
the spec only defines "ea"; update the canonical example to either remove
"commit" and "epoch" or add normative definitions: if removing, delete
["commit", ...] and ["epoch", ...] from the example entries; if defining, add
normative semantics for "commit" and "epoch" similar to "ea" (specify their
expected token formats, whether they are single-valued or repeatable, how to
parse/validate them, and how clients should treat unknown/unsupported values)
and update parsing instructions to include handling in the same section that
defines "ea". Ensure you update all occurrences (lines around the examples at
the three noted ranges) and reference the tags "commit", "epoch", and existing
"ea" when making the change.
---
Outside diff comments:
In `@03.md`:
- Around line 166-169: State explicitly that the "Exception - Initial Group
Creation" section supersedes the MIP-01 rule "Commit events must be published"
for the specific case of initial single-member group creation: add a sentence
like "For initial single-member group creation, this exception supersedes the
MIP-01 requirement that commit events must be published." Also add reciprocal
cross-reference notes: in MIP-01 add a parenthetical pointer to the "Exception -
Initial Group Creation" explaining the narrow exception, and in the current
section reference MIP-01 by name to avoid implementer divergence (mention the
section title "Exception - Initial Group Creation" and the rule "Commit events
must be published" to locate the text).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0c697d1f-fa38-4b02-a843-72b4f33a2335
📒 Files selected for processing (4)
02.md03.mddecentralized_consistency_analysis.mdthreat_model.md
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
02.md (1)
222-223:⚠️ Potential issue | 🟠 MajorAvoid reintroducing undefined
epochmetadata in the summary.Line 222 mentions optional metadata “such as epoch,” but this file only normatively defines
ea. This reopens ambiguity aroundepochhandling semantics. Either removeepochhere or add explicit parsing/validation semantics in the optional-fields section.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@02.md` around lines 222 - 223, The mention of "epoch" in the optional private hints line reintroduces an undefined metadata field; either delete "epoch" from that sentence or add a normative definition and validation rules for it in the optional-fields section so it matches the existing `ea` (epoch_authenticator) semantics; if you choose to define it, specify its exact name (`epoch`), type, allowed range/format, parsing rules, and how it interacts with `epoch_authenticator` (`ea`) and update any references to use the same terminology to avoid ambiguity.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@02.md`:
- Around line 45-48: Add a formatted security note to 02.md that follows the
repo's `{00..04}.md` style: include an explicit "Security note" section with ✅
(protections) and ⚠️ (limitations) markers, reference threat_model.md for
metadata-observability context, and clearly state observable metadata and
privacy limitations for Welcome delivery (mention outer kind: 1059 gift-wrap is
only a transport wrapper and the actual payload is in the inner unsigned rumor
event); also call out that clients SHOULD NOT place parent Commit references or
branch-linking metadata on the outer kind: 1059 event and summarize what minimal
routing metadata (e.g., recipient p tag) is exposed.
- Around line 145-146: The current wording in the "After successfully processing
a Welcome message..." paragraph is stricter than MIP-03; change the sentence to
match MIP-03's normative strength by making the self-update a SHOULD for
catch-up (i.e., clients SHOULD attempt a self-update/MLS Update proposal for
their own LeafNode after welcome processing) but allow the fallback behavior
under timeout/partial visibility described in MIP-03 (so implementers may
proceed if the bounded best-effort sync does not complete in time); apply the
same harmonization to the corresponding text in the later paragraph referenced
(lines 161-166) so both places use the same SHOULD-level guidance and explicit
fallback language.
---
Duplicate comments:
In `@02.md`:
- Around line 222-223: The mention of "epoch" in the optional private hints line
reintroduces an undefined metadata field; either delete "epoch" from that
sentence or add a normative definition and validation rules for it in the
optional-fields section so it matches the existing `ea` (epoch_authenticator)
semantics; if you choose to define it, specify its exact name (`epoch`), type,
allowed range/format, parsing rules, and how it interacts with
`epoch_authenticator` (`ea`) and update any references to use the same
terminology to avoid ambiguity.
| Welcome delivery uses [NIP-59](https://github.com/nostr-protocol/nips/blob/master/59.md) gift-wrapping for privacy and unlinkability. In Marmot, the outer `kind: 1059` gift-wrap is only a transport wrapper. The actual application-defined Welcome payload is carried in the inner unsigned rumor event. | ||
|
|
||
| The outer gift-wrap SHOULD reveal only the minimum metadata required for routing, typically the recipient `p` tag. Clients SHOULD NOT place parent Commit references or other branch-linking metadata on the outer `kind: 1059` event. | ||
|
|
There was a problem hiding this comment.
Complete security-note formatting/context required by repo guidelines.
This new privacy/security guidance should include explicit ✅/threat_model.md for metadata-observability context, to match the spec style required for {00..04}.md.
As per coding guidelines "{00,01,02,03,04}.md: Reference threat_model.md for security context and document observable metadata and privacy limitations" and "Include ✅ (protections) and
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@02.md` around lines 45 - 48, Add a formatted security note to 02.md that
follows the repo's `{00..04}.md` style: include an explicit "Security note"
section with ✅ (protections) and ⚠️ (limitations) markers, reference
threat_model.md for metadata-observability context, and clearly state observable
metadata and privacy limitations for Welcome delivery (mention outer kind: 1059
gift-wrap is only a transport wrapper and the actual payload is in the inner
unsigned rumor event); also call out that clients SHOULD NOT place parent Commit
references or branch-linking metadata on the outer kind: 1059 event and
summarize what minimal routing metadata (e.g., recipient p tag) is exposed.
| After successfully processing a Welcome message, clients SHOULD perform a self-update (MLS Update proposal for their own LeafNode) as soon as possible. However, that self-update SHOULD be sent only after the bounded best-effort sync described above completes so the self-update is based on the freshest visible group state. Sending a self-update from stale state increases the risk of local state divergence (effectively "forking yourself" out of the group). | ||
|
|
There was a problem hiding this comment.
Harmonize self-update sequencing semantics with MIP-03.
Line 145 currently reads stricter than 03.md (which says self-update catch-up is a SHOULD). This creates inter-spec ambiguity for implementers. Please align wording so both MIPs express the same normative strength and fallback behavior under timeout/partial visibility.
Proposed spec-alignment diff
-After successfully processing a Welcome message, clients SHOULD perform a self-update (MLS Update proposal for their own LeafNode) as soon as possible. However, that self-update SHOULD be sent only after the bounded best-effort sync described above completes so the self-update is based on the freshest visible group state. Sending a self-update from stale state increases the risk of local state divergence (effectively "forking yourself" out of the group).
+After successfully processing a Welcome message, clients SHOULD perform a self-update (MLS Update proposal for their own LeafNode) as soon as possible. Clients SHOULD first perform the bounded best-effort sync described above so the self-update is based on the freshest visible group state. If sync is incomplete due to timeout or relay unavailability, clients MAY proceed conservatively while continuing catch-up attempts. Sending a self-update from stale state increases the risk of local state divergence (effectively "forking yourself" out of the group).Also applies to: 161-166
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@02.md` around lines 145 - 146, The current wording in the "After successfully
processing a Welcome message..." paragraph is stricter than MIP-03; change the
sentence to match MIP-03's normative strength by making the self-update a SHOULD
for catch-up (i.e., clients SHOULD attempt a self-update/MLS Update proposal for
their own LeafNode after welcome processing) but allow the fallback behavior
under timeout/partial visibility described in MIP-03 (so implementers may
proceed if the bounded best-effort sync does not complete in time); apply the
same harmonization to the corresponding text in the later paragraph referenced
(lines 161-166) so both places use the same SHOULD-level guidance and explicit
fallback language.
|
Hey! I wanted to share some updates on this research. I added a focused set of tests in marmot-ts research branch to try to harden the claims of this ongoing research, and I think they helped clarify where What I found most useful is that these cases make the role of That is the main reason this now feels more solid to me as research. The value is that it gives us a cheap and RFC-aligned way to distinguish a normal successful join from a successful join carrying a false or misbound claim, and from cases where no valid joined state exists in the first place. For a system like Marmot, where relay delivery is weakly ordered and mixed-client behavior is realistic, that seems like a meaningful improvement in how we reason about drift and branch uncertainty. More over mls implementations like ts-mls use these as an internal correctness and conformance invariant. And what I'm proposing here is using the same property, but elevating it into a decentralized diagnostic signal for Welcome-path branch consistency. I am still treating this as ongoing research rather than a concrete protocol proposal, but I think these tests made the argument both narrower and stronger, and they gave me more confidence that this is worth keeping in the discussion. |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
decentralized_consistency_analysis.md (2)
1-387: Strong research document; add systematic MIP cross-references throughout.This document provides valuable analysis and clear reasoning for protocol design decisions. The structure is logical, the mental models are well-articulated, and the normative language (MUST/SHOULD/MAY) is used appropriately.
However, the document would benefit significantly from systematic cross-references to relevant MIPs:
- MIP-02 for Welcome handling, epoch_authenticator, and join semantics
- MIP-03 for Commit discipline and timing requirements
- threat_model.md for security implications (as per retrieved learnings)
These cross-references would help readers understand:
- Which recommendations are already implemented
- Which are proposed additions
- How this research connects to normative protocol text
Based on learnings: Protocol specifications benefit from documenting edge cases, race conditions, and failure modes, and should update threat_model.md when there are security implications.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@decentralized_consistency_analysis.md` around lines 1 - 387, Add systematic cross-references to MIPs and the threat model throughout the document: link MIP-02 wherever Welcome handling, epoch_authenticator, join semantics, or "Welcome Handling" are discussed; link MIP-03 for all Commit discipline, pre-Commit catch-up, timing and same-epoch conflict sections; reference threat_model.md where security implications, drift, fork containment, or recovery semantics are described. For each referenced recommendation (e.g., "Post-Join Send Hygiene", "Require Freshness Checks Before Structural Commits", "Drift As A First-Class Operational Condition", "Welcome Handling", "Commit Discipline", "Recovery"), annotate whether it is already implemented, proposed, or open (implemented/proposed/open) and add a short pointer to the specific MIP or threat_model.md entry that captures normative language or required updates.
160-171: Reference MIP-03 for Commit discipline.This section discusses Commit creation requirements that relate directly to MIP-03. Adding a cross-reference would help readers connect this research to the protocol specification.
🔗 Suggested addition
-### 2. Require Freshness Checks Before Structural Commits +### 2. Require Freshness Checks Before Structural Commits (see [MIP-03](03.md)) The same discipline that applies after joining or resuming from stale state should also apply to commit creation.As per coding guidelines, reference other MIPs using
[MIP-XX](XX.md)format.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@decentralized_consistency_analysis.md` around lines 160 - 171, Add a cross-reference to MIP-03 in the "Require Freshness Checks Before Structural Commits" section by referencing the protocol specification using the required format; update the heading paragraph to mention and link MIP-03 like "[MIP-03](MIP-03.md)" where you discuss Commit discipline and explicitly tie the requirements (bounded catch-up, avoiding sends on uncertain local state, deferring on known branch conflict) to MIP-03 so readers can follow the protocol specification for Commit creation rules (mentioning Commit, member add/remove Commits, bounded catch-up, and branch conflict to aid discoverability).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@decentralized_consistency_analysis.md`:
- Around line 25-29: Update the architectural paragraph to include explicit
cross-references to MIP-02 and MIP-03 using the required format; replace or
append references to "Welcome handling" and "Commit discipline" with
`[MIP-02](02.md)` and `[MIP-03](03.md)` respectively in the text that currently
reads "This architectural description directly relates to concepts specified in
MIP-02 (Welcome handling) and MIP-03 (Commit discipline)"; ensure both
references use the exact `[MIP-XX](XX.md)` syntax and maintain the original
sentence flow in decentralized_consistency_analysis.md.
- Around line 216-231: Update the "Normative Direction" paragraph to reference
the existing MIP-02 feature and change the future-tense phrasing to
present-tense: replace "Marmot SHOULD add encrypted `epoch_authenticator`
confirmation" with a statement that Marmot adopts the optional `ea` tag and the
compare/quarantine behavior as specified in MIP-02 (use the cross-reference
format [MIP-02](02.md)); explicitly mention `epoch_authenticator`, Welcome
processing, and the MUST quarantine / SHOULD compare rules from MIP-02 so
readers know this is already implemented rather than planned.
---
Nitpick comments:
In `@decentralized_consistency_analysis.md`:
- Around line 1-387: Add systematic cross-references to MIPs and the threat
model throughout the document: link MIP-02 wherever Welcome handling,
epoch_authenticator, join semantics, or "Welcome Handling" are discussed; link
MIP-03 for all Commit discipline, pre-Commit catch-up, timing and same-epoch
conflict sections; reference threat_model.md where security implications, drift,
fork containment, or recovery semantics are described. For each referenced
recommendation (e.g., "Post-Join Send Hygiene", "Require Freshness Checks Before
Structural Commits", "Drift As A First-Class Operational Condition", "Welcome
Handling", "Commit Discipline", "Recovery"), annotate whether it is already
implemented, proposed, or open (implemented/proposed/open) and add a short
pointer to the specific MIP or threat_model.md entry that captures normative
language or required updates.
- Around line 160-171: Add a cross-reference to MIP-03 in the "Require Freshness
Checks Before Structural Commits" section by referencing the protocol
specification using the required format; update the heading paragraph to mention
and link MIP-03 like "[MIP-03](MIP-03.md)" where you discuss Commit discipline
and explicitly tie the requirements (bounded catch-up, avoiding sends on
uncertain local state, deferring on known branch conflict) to MIP-03 so readers
can follow the protocol specification for Commit creation rules (mentioning
Commit, member add/remove Commits, bounded catch-up, and branch conflict to aid
discoverability).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 639b793b-6f9f-4939-940b-9205204e3935
📒 Files selected for processing (1)
decentralized_consistency_analysis.md
| The right way to think about Marmot is: | ||
|
|
||
| - MLS provides the cryptographic state machine. | ||
| - Nostr provides a decentralized dissemination layer. | ||
| - Marmot must define the convergence rules needed to safely operate MLS over that transport. |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Add cross-references to relevant MIPs.
This architectural description directly relates to concepts specified in MIP-02 (Welcome handling) and MIP-03 (Commit discipline). As per coding guidelines, reference other MIPs using the [MIP-XX](XX.md) format.
📚 Suggested addition
The right way to think about Marmot is:
- MLS provides the cryptographic state machine.
- Nostr provides a decentralized dissemination layer.
-- Marmot must define the convergence rules needed to safely operate MLS over that transport.
+- Marmot must define the convergence rules needed to safely operate MLS over that transport (see [MIP-02](02.md) and [MIP-03](03.md)).As per coding guidelines, MIP cross-references should use [MIP-XX](XX.md) format.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| The right way to think about Marmot is: | |
| - MLS provides the cryptographic state machine. | |
| - Nostr provides a decentralized dissemination layer. | |
| - Marmot must define the convergence rules needed to safely operate MLS over that transport. | |
| The right way to think about Marmot is: | |
| - MLS provides the cryptographic state machine. | |
| - Nostr provides a decentralized dissemination layer. | |
| - Marmot must define the convergence rules needed to safely operate MLS over that transport (see [MIP-02](02.md) and [MIP-03](03.md)). |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@decentralized_consistency_analysis.md` around lines 25 - 29, Update the
architectural paragraph to include explicit cross-references to MIP-02 and
MIP-03 using the required format; replace or append references to "Welcome
handling" and "Commit discipline" with `[MIP-02](02.md)` and `[MIP-03](03.md)`
respectively in the text that currently reads "This architectural description
directly relates to concepts specified in MIP-02 (Welcome handling) and MIP-03
(Commit discipline)"; ensure both references use the exact `[MIP-XX](XX.md)`
syntax and maintain the original sentence flow in
decentralized_consistency_analysis.md.
| #### Normative Direction | ||
|
|
||
| For Marmot, these checks should not remain soft diagnostics in mixed-client ecosystems. | ||
|
|
||
| The honest-path result is important but limited: when the Welcome is valid and the inviter is honest, `epoch_authenticator` is mostly confirmatory. Its real value appears in the non-ideal cases that decentralized delivery makes plausible, especially raced branches, mixed implementations, buggy state production, or adversarially wrong metadata. | ||
|
|
||
| The intended direction is: | ||
|
|
||
| - MLS tree validation remains mandatory through normal Welcome processing, | ||
| - clients MUST fail closed on ratchet-tree or related MLS validation failures, | ||
| - Marmot SHOULD add encrypted `epoch_authenticator` confirmation for the Welcome epoch, | ||
| - clients that support this confirmation SHOULD compare it before first outbound traffic, | ||
| - clients MUST quarantine state on mismatch and MUST NOT send application traffic or structural Commits from that state. | ||
|
|
||
| Failure to enforce these checks materially increases the risk of silent drift and persistent forks in mixed-client environments. | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Add MIP-02 cross-reference and clarify implementation status.
The normative direction described here is already partially implemented in MIP-02:
- Line 77 of 02.md specifies the optional
eatag - Lines 100-121 of 02.md specify SHOULD compare and MUST quarantine on mismatch
However, line 226 phrases this as "Marmot SHOULD add" (future tense), which may confuse readers since this feature already exists in the current spec.
🔗 Suggested clarification
The intended direction is:
- MLS tree validation remains mandatory through normal Welcome processing,
- clients MUST fail closed on ratchet-tree or related MLS validation failures,
-- Marmot SHOULD add encrypted `epoch_authenticator` confirmation for the Welcome epoch,
+- Marmot SHOULD strengthen encrypted `epoch_authenticator` confirmation for the Welcome epoch (see [MIP-02](02.md)),
- clients that support this confirmation SHOULD compare it before first outbound traffic,
- clients MUST quarantine state on mismatch and MUST NOT send application traffic or structural Commits from that state.As per coding guidelines, reference other MIPs using [MIP-XX](XX.md) format.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| #### Normative Direction | |
| For Marmot, these checks should not remain soft diagnostics in mixed-client ecosystems. | |
| The honest-path result is important but limited: when the Welcome is valid and the inviter is honest, `epoch_authenticator` is mostly confirmatory. Its real value appears in the non-ideal cases that decentralized delivery makes plausible, especially raced branches, mixed implementations, buggy state production, or adversarially wrong metadata. | |
| The intended direction is: | |
| - MLS tree validation remains mandatory through normal Welcome processing, | |
| - clients MUST fail closed on ratchet-tree or related MLS validation failures, | |
| - Marmot SHOULD add encrypted `epoch_authenticator` confirmation for the Welcome epoch, | |
| - clients that support this confirmation SHOULD compare it before first outbound traffic, | |
| - clients MUST quarantine state on mismatch and MUST NOT send application traffic or structural Commits from that state. | |
| Failure to enforce these checks materially increases the risk of silent drift and persistent forks in mixed-client environments. | |
| #### Normative Direction | |
| For Marmot, these checks should not remain soft diagnostics in mixed-client ecosystems. | |
| The honest-path result is important but limited: when the Welcome is valid and the inviter is honest, `epoch_authenticator` is mostly confirmatory. Its real value appears in the non-ideal cases that decentralized delivery makes plausible, especially raced branches, mixed implementations, buggy state production, or adversarially wrong metadata. | |
| The intended direction is: | |
| - MLS tree validation remains mandatory through normal Welcome processing, | |
| - clients MUST fail closed on ratchet-tree or related MLS validation failures, | |
| - Marmot SHOULD strengthen encrypted `epoch_authenticator` confirmation for the Welcome epoch (see [MIP-02](02.md)), | |
| - clients that support this confirmation SHOULD compare it before first outbound traffic, | |
| - clients MUST quarantine state on mismatch and MUST NOT send application traffic or structural Commits from that state. | |
| Failure to enforce these checks materially increases the risk of silent drift and persistent forks in mixed-client environments. | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@decentralized_consistency_analysis.md` around lines 216 - 231, Update the
"Normative Direction" paragraph to reference the existing MIP-02 feature and
change the future-tense phrasing to present-tense: replace "Marmot SHOULD add
encrypted `epoch_authenticator` confirmation" with a statement that Marmot
adopts the optional `ea` tag and the compare/quarantine behavior as specified in
MIP-02 (use the cross-reference format [MIP-02](02.md)); explicitly mention
`epoch_authenticator`, Welcome processing, and the MUST quarantine / SHOULD
compare rules from MIP-02 so readers know this is already implemented rather
than planned.
|
Thanks @gzuuus I looked through the new stuff and ran the tests. My overall take hasn't changed much:
Because of that, the strongest parts of this PR for me are the hygiene/recovery rules:
Those seem worth specifying more clearly in the smallest possible spec changes. I do not think that we need to add any extra metadata to welcomes or any other commit messages. I could probably be swayed to include the optional In adddition - this PR adds A LOT of new normative text that I think is not necessary and should be removed. We should absolutely add some new hygiene/recovery recommendations (strong recommendations even), but I don't think that we need to make these changes Obviously, before merge we'll need to remove the tests and other research docs as well. |
2 participants
Summary by CodeRabbit
New Features
Documentation