Added shared_history flag to room key events

[Michael-Hollister]

Fixes #1104

Added shared_history flag for MSC 3061 implementation. See following PR for more details: matrix-org/matrix-rust-sdk#2650

Signed-off-by: Michael Hollister michael@futo.org

---

Preview Removed

[zecakeh]

Thanks!

We should also put this new field behind a cargo feature, like other non-merged MSCs. Please expose that feature in the main ruma crate and add it to the __ci cargo feature.

[Michael-Hollister]

Thanks!

We should also put this new field behind a cargo feature, like other non-merged MSCs. Please expose that feature in the main ruma crate and add it to the __ci cargo feature.

Before feature-gating the changes, I would like to confirm with you I should do this, since the MSC is merged into the spec per my understanding: matrix-org/matrix-spec-proposals#3061. Also, the reason why I renamed the shared_history fields is for interoperability with the JS SDK that uses the MSC namespacing: https://github.com/matrix-org/matrix-js-sdk/blob/develop/src/crypto/algorithms/megolm.ts#L127C24-L127C24. Otherwise I would have not renamed the fields.

So to confirm for this situation:

1. Do you recommend in this case to keep the field names renamed to the MSC prefix? Or at this point should the JS SDK change to remove the MSC prefix for these events?
2. Given that the MSC is merged, should I still feature-gate the changes?

[zecakeh]

My understanding is that a MSC is "merged" into the spec only when it has had a Spec PR that was actually merged into the matrix-spec repo. The current state of this MSC in the MSC process is that it has been "accepted", i.e. it has passed FCP and has been merged into the matrix-spec-proposals repo.

It doesn't seem to be on the SCT roadmap so I doubt the spec PR is going to be made soon. However if there is a reason why the spec PR is not to be created the MSC should have a "blocked" label, which it does not. It might be worth asking on the MSC or in the SCT office if there is a reason it is not on the roadmap. The reservations from the rust SDK crypto team might be why it is not planned to be merged in its current state.

Being unsure of the future of the MSC is reason enough for me to keep using the unstable prefix and put it behind a cargo feature.

[Michael-Hollister]

My understanding is that a MSC is "merged" into the spec only when it has had a Spec PR that was actually merged into the matrix-spec repo. The current state of this MSC in the MSC process is that it has been "accepted", i.e. it has passed FCP and has been merged into the matrix-spec-proposals repo.

It doesn't seem to be on the SCT roadmap so I doubt the spec PR is going to be made soon. However if there is a reason why the spec PR is not to be created the MSC should have a "blocked" label, which it does not. It might be worth asking on the MSC or in the SCT office if there is a reason it is not on the roadmap. The reservations from the rust SDK crypto team might be why it is not planned to be merged in its current state.

Being unsure of the future of the MSC is reason enough for me to keep using the unstable prefix and put it behind a cargo feature.

Thanks for the clarification! I'll go ahead and put this behind a cargo feature then.

[zecakeh]

So… it looks like the spec PR has been created: matrix-org/matrix-spec#1655.

So I believe we would accept either:

1. Using the stable prefix without a cargo feature. We would wait until the spec PR is merged to merge this one, just to be sure.
2. Using the unstable prefix behind a cargo feature. We could merge this as soon as it is ready. It can be updated later when the spec PR is merged and the JS SDK supports the stable prefix for example.

[Michael-Hollister]

Alright, I went ahead and added the changes behind the cargo feature. In the event that MSC3061 gets merged in the spec, it should be easy to revert the commit. And if not, then other projects depending on ruma can decide whether to include the feature.

[zecakeh]

The cargo feature is good now. I didn't notice before that you were making breaking changes to the API where we usually don't (also that makes the feature non-additive).