Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec event edits #1211

Merged
merged 6 commits into from
Sep 21, 2022
Merged

Spec event edits #1211

merged 6 commits into from
Sep 21, 2022

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented Aug 16, 2022

Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a first pass review of the PR, not taking into consideration what the MSC actually says (just relying on what I remember of the MSC).

Most of the comments here are about voice (effectively) as well as general clarity: where possible, I've suggested alternative wording alongside rationale for the change.

I believe this PR is factually accurate enough to ask that this batch of comments be dealt with before receiving a second pass of review, though if you'd prefer to have the second pass first then re-request review and I'll take a look.

content/client-server-api/modules/event_replacements.md Outdated Show resolved Hide resolved
content/client-server-api/_index.md Outdated Show resolved Hide resolved
content/client-server-api/modules/event_replacements.md Outdated Show resolved Hide resolved
content/client-server-api/modules/event_replacements.md Outdated Show resolved Hide resolved
content/client-server-api/modules/event_replacements.md Outdated Show resolved Hide resolved
content/client-server-api/modules/event_replacements.md Outdated Show resolved Hide resolved
content/client-server-api/modules/event_replacements.md Outdated Show resolved Hide resolved
@turt2live
Copy link
Member

also, deserving of its own comment: thank you for writing this up 😄 it's clear quite a lot of work went into this, and is well written :)

@richvdh richvdh requested a review from turt2live August 23, 2022 14:28
Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall this looks good to me. For blockers:

  • Splitting out the cleartext description in the relationships section (the wording can stay unchanged in the edits module)
  • Consistency on the feature name within the spec
  • Stylistic things mentioned as suggestions (could be argued otherwise, though)

content/client-server-api/modules/event_replacements.md Outdated Show resolved Hide resolved
Comment on lines +125 to +129
{{% boxes/note %}}
The payload of an encrypted replacement event must be encrypted as normal, including
ratcheting any [Megolm](#mmegolmv1aes-sha2) session as normal. The original Megolm
ratchet entry should **not** be re-used.
{{% /boxes/note %}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid this still doesn't make any sense to me as a reader - we have zero mention of a "ratchet entry" in the spec, and it's not a term I've heard come up in conversation before. I realize this is coming from the MSC, but it also doesn't make sense there having re-read it.

Is this the "ratchet index" (a defined term in the spec) or can we just say it's "encrypted like any other event" and avoid the problem entirely?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, it should be "ratchet value", from https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#the-megolm-ratchet-algorithm.

My general feeling is: if you're implementing edits of encrypted events, you'll know what this means, and if you're not, you don't need to worry about it.

can we just say it's "encrypted like any other event"

Well, at that point, it doesn't seem to give any information at all, so we might as well just omit it.

TBH it seems kindof obvious to me that we wouldn't reuse the old key, so I'd be happy to omit this block, but this text was added in response to @erikjohnston's question at matrix-org/matrix-spec-proposals#2676 (comment). Erik: do you have any thoughts on whether this text is necessary?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

due to lack of comment I'm inclined to believe it's just a safety net thing. It doesn't feel particularly safe to assume that the person implementing edits of encrypted events is also aware of the intricacies of encryption, however I'm happy to go with whatever at this point.

content/client-server-api/modules/event_replacements.md Outdated Show resolved Hide resolved
Co-authored-by: Travis Ralston <travisr@matrix.org>
@turt2live turt2live added the release-blocker Blocks the next release from happening label Sep 12, 2022
Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's just send it and make clarifications after the fact if needed.

@richvdh richvdh merged commit 58e6900 into main Sep 21, 2022
@richvdh richvdh deleted the rav/message_editing branch September 21, 2022 13:41
clokep pushed a commit to clokep/matrix-spec that referenced this pull request May 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-blocker Blocks the next release from happening
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants