Add support for room v11 #987

Open
_ZN3val wants to merge 9 commits from room-v11 into next
_ZN3val commented 2023-12-01 17:18:30 +00:00 (Migrated from gitlab.com)

Resolves https://gitlab.com/famedly/conduit/-/issues/408

Spec: https://spec.matrix.org/v1.9/rooms/v11/


  • I agree to release my code and all other changes of this MR under the Apache-2.0 license
Resolves https://gitlab.com/famedly/conduit/-/issues/408 Spec: https://spec.matrix.org/v1.9/rooms/v11/ ----------------------------------------------------------------------------- - [x] I agree to release my code and all other changes of this MR under the Apache-2.0 license
_ZN3val commented 2023-12-01 17:18:48 +00:00 (Migrated from gitlab.com)

changed title from {-R-}oom v11 to {+Add support for r+}oom v11

changed title from **{-R-}oom v11** to **{+Add support for r+}oom v11**
_ZN3val commented 2023-12-01 17:18:48 +00:00 (Migrated from gitlab.com)

changed the description

changed the description
_ZN3val commented 2023-12-01 17:29:24 +00:00 (Migrated from gitlab.com)

added 4 commits

  • a3b8eea9 - Move "redacts" key to "content" in redaction events in v11 rooms
  • 18bfd79e - Remove "creator" key when upgrading rooms to v11
  • fac99503 - create_hash_and_sign_event: Use actual version of RoomCreate events, instead of the default
  • 9646439a - Enable support for room v11

Compare with previous version

added 4 commits <ul><li>a3b8eea9 - Move &quot;redacts&quot; key to &quot;content&quot; in redaction events in v11 rooms</li><li>18bfd79e - Remove &quot;creator&quot; key when upgrading rooms to v11</li><li>fac99503 - create_hash_and_sign_event: Use actual version of RoomCreate events, instead of the default</li><li>9646439a - Enable support for room v11</li></ul> [Compare with previous version](/famedly/conduit/-/merge_requests/562/diffs?diff_id=861015501&start_sha=abeb1a160fcc2d86e4bd2e00d1504e4f6bf7d814)
zecakeh commented 2023-12-01 17:45:31 +00:00 (Migrated from gitlab.com)

v11 actually allow all keys here, and there are other changes in the redaction rules. I am wondering why this doesn't use the methods from Ruma, like ruma::canonical_json::redact_content_in_place, is it a type issue?

v11 actually allow all keys here, and there are other changes in the redaction rules. I am wondering why this doesn't use the methods from Ruma, like `ruma::canonical_json::redact_content_in_place`, is it a type issue?
_ZN3val commented 2023-12-01 17:52:36 +00:00 (Migrated from gitlab.com)

Ah you're right, I misunderstood the spec.

Ah you're right, I misunderstood the spec.
_ZN3val commented 2023-12-01 18:08:29 +00:00 (Migrated from gitlab.com)

changed this line in version 3 of the diff

changed this line in [version 3 of the diff](/famedly/conduit/-/merge_requests/562/diffs?diff_id=861047521&start_sha=9646439a94f35a7ab46274c1465ee1192215724a#8738328442e0fca2cfb67ccff0d0c38d65989a4d_72_60)
_ZN3val commented 2023-12-01 18:08:29 +00:00 (Migrated from gitlab.com)

added 1 commit

  • ecc9dfb4 - Use Ruma's redact_content_in_place instead of custom implementation

Compare with previous version

added 1 commit <ul><li>ecc9dfb4 - Use Ruma&#39;s redact_content_in_place instead of custom implementation</li></ul> [Compare with previous version](/famedly/conduit/-/merge_requests/562/diffs?diff_id=861047521&start_sha=9646439a94f35a7ab46274c1465ee1192215724a)
_ZN3val commented 2023-12-01 18:08:42 +00:00 (Migrated from gitlab.com)

resolved all threads

resolved all threads
_ZN3val commented 2023-12-01 18:11:05 +00:00 (Migrated from gitlab.com)

I switched to redact_content_in_place, it seems to work (tested only on m.room.message). Thanks!

I switched to `redact_content_in_place`, it seems to work (tested only on `m.room.message`). Thanks!
_ZN3val commented 2023-12-01 18:11:58 +00:00 (Migrated from gitlab.com)

resolved all threads

resolved all threads
_ZN3val commented 2023-12-01 18:12:29 +00:00 (Migrated from gitlab.com)

added 1 commit

  • 520806d4 - Use Ruma's redact_content_in_place instead of custom implementation

Compare with previous version

added 1 commit <ul><li>520806d4 - Use Ruma&#39;s redact_content_in_place instead of custom implementation</li></ul> [Compare with previous version](/famedly/conduit/-/merge_requests/562/diffs?diff_id=861050680&start_sha=ecc9dfb4bf1a29dd70325f139b8d2a54bee434ff)
girlbossceo commented 2023-12-02 14:24:18 +00:00 (Migrated from gitlab.com)

Is this panic! intended? This seems highly unusual. panic! is only used in 1 other place in this entire codebase and it's very early on during Router init, and panic! was not used here before.

If it is, it needs to be documented why very clearly.

Is this `panic!` intended? This seems highly unusual. `panic!` is only used in 1 other place in this entire codebase and it's very early on during Router init, and `panic!` was not used here before. If it is, it needs to be documented why very clearly.
_ZN3val commented 2023-12-02 14:31:52 +00:00 (Migrated from gitlab.com)

A panic! isn't very different from the various .expect() in this function, but point taken. I'll return an error instead.

A `panic!` isn't very different from the various `.expect()` in this function, but point taken. I'll return an error instead.
girlbossceo commented 2023-12-02 14:48:11 +00:00 (Migrated from gitlab.com)

The expects should still probably be replaced to avoid another https://gitlab.com/famedly/conduit/-/issues/396 where possible

The expects should still probably be replaced to avoid another https://gitlab.com/famedly/conduit/-/issues/396 where possible
_ZN3val commented 2023-12-02 16:51:26 +00:00 (Migrated from gitlab.com)

changed this line in version 5 of the diff

changed this line in [version 5 of the diff](/famedly/conduit/-/merge_requests/562/diffs?diff_id=861412998&start_sha=520806d41385cddee20ec8d8a83bc1c491a61280#3f7d009329014f29e5cd9c98898ddcedcbe38d6b_701_699)
_ZN3val commented 2023-12-02 16:51:26 +00:00 (Migrated from gitlab.com)

added 1 commit

  • 5a7bb1e8 - Return error instead of panic when first event is not m.room.create

Compare with previous version

added 1 commit <ul><li>5a7bb1e8 - Return error instead of panic when first event is not m.room.create</li></ul> [Compare with previous version](/famedly/conduit/-/merge_requests/562/diffs?diff_id=861412998&start_sha=520806d41385cddee20ec8d8a83bc1c491a61280)
_ZN3val commented 2023-12-02 17:50:04 +00:00 (Migrated from gitlab.com)

resolved all threads

resolved all threads
girlbossceo commented 2023-12-03 02:34:45 +00:00 (Migrated from gitlab.com)

mentioned in commit girlbossceo/conduwuit@f62f641545

mentioned in commit girlbossceo/conduwuit@f62f6415450e1ef6326b3ac38406021fff12f0e1
tezlm commented 2023-12-03 03:24:39 +00:00 (Migrated from gitlab.com)

Possibly an unpopular opinion, but if it's presumably an unreachable state, you should add panic!() and assert!()s. Bugs and logic problems aren't handlable errors and should fail loudly rather than continuing in an unknown state or returning a "quiet" error.

Possibly an unpopular opinion, but if it's presumably an unreachable state, you should add `panic!()` and `assert!()`s. Bugs and logic problems aren't handlable errors and should fail loudly rather than continuing in an unknown state or returning a "quiet" error.
_ZN3val commented 2023-12-03 07:06:39 +00:00 (Migrated from gitlab.com)

If it's guaranteed unreachable, then yes. However, here, this can happen due to bugs in the function's caller, and who knows what it may be doing. And even if it's correct now, we don't know for sure future versions will be.

If it's guaranteed unreachable, then yes. However, here, this can happen due to bugs in the function's caller, and who knows what it may be doing. And even if it's correct now, we don't know for sure future versions will be.
okias commented 2023-12-22 10:53:10 +00:00 (Migrated from gitlab.com)

is the MR ready?

is the MR ready?
_ZN3val commented 2023-12-22 11:54:10 +00:00 (Migrated from gitlab.com)

I believe so, but it needs to be carefully reviewed by someone who understands Conduit better than I do

I believe so, but it needs to be carefully reviewed by someone who understands Conduit better than I do
timokoesters commented 2023-12-24 16:22:51 +00:00 (Migrated from gitlab.com)

Can you write RoomVersionId::V11 to be explicit here? I think it's useful to do a full match in these places so the code is reviewed again for future versions.

Can you write RoomVersionId::V11 to be explicit here? I think it's useful to do a full match in these places so the code is reviewed again for future versions.
timokoesters commented 2023-12-24 16:22:52 +00:00 (Migrated from gitlab.com)

We already have this function in src/service/rooms/state/mod.rs

We already have this function in src/service/rooms/state/mod.rs
timokoesters commented 2023-12-24 16:22:52 +00:00 (Migrated from gitlab.com)

Have you tested this in a real room already?

Have you tested this in a real room already?
timokoesters commented 2023-12-24 16:22:52 +00:00 (Migrated from gitlab.com)

Can we just use baddatabase for these? That makes sure they get picked up correctly by the error handling code later in this file.

Can we just use baddatabase for these? That makes sure they get picked up correctly by the error handling code later in this file.
timokoesters commented 2023-12-24 16:22:53 +00:00 (Migrated from gitlab.com)

Here's my initial review, I still need to compare this to the spec

Here's my initial review, I still need to compare this to the spec
_ZN3val commented 2023-12-24 18:04:57 +00:00 (Migrated from gitlab.com)

changed this line in version 6 of the diff

changed this line in [version 6 of the diff](/famedly/conduit/-/merge_requests/562/diffs?diff_id=880565959&start_sha=5a7bb1e8f104b66e65a16e447d930b478640383a#cd91a7743a53129a76df61ce74064141dae4eaa1_149_149)
_ZN3val commented 2023-12-24 18:04:58 +00:00 (Migrated from gitlab.com)

changed this line in version 6 of the diff

changed this line in [version 6 of the diff](/famedly/conduit/-/merge_requests/562/diffs?diff_id=880565959&start_sha=5a7bb1e8f104b66e65a16e447d930b478640383a#3f7d009329014f29e5cd9c98898ddcedcbe38d6b_132_131)
_ZN3val commented 2023-12-24 18:04:58 +00:00 (Migrated from gitlab.com)

added 2 commits

  • eb7ac91c - Reuse existing get_room_version
  • 8175bc12 - Explicitly match RoomVersionId::V11

Compare with previous version

added 2 commits <ul><li>eb7ac91c - Reuse existing get_room_version</li><li>8175bc12 - Explicitly match RoomVersionId::V11</li></ul> [Compare with previous version](/famedly/conduit/-/merge_requests/562/diffs?diff_id=880565959&start_sha=5a7bb1e8f104b66e65a16e447d930b478640383a)
_ZN3val commented 2023-12-24 18:07:10 +00:00 (Migrated from gitlab.com)

It would make the errors harder to debug as their only argument would be &'static str

It would make the errors harder to debug as their only argument would be `&'static str`
_ZN3val commented 2023-12-24 18:07:11 +00:00 (Migrated from gitlab.com)

It's slightly different because it returns an error instead of None when the version is not found; I hope my change is okay

It's slightly different because it returns an error instead of `None` when the version is not found; I hope my change is okay
_ZN3val commented 2023-12-24 18:07:11 +00:00 (Migrated from gitlab.com)

yes

yes
timokoesters commented 2024-01-24 17:16:47 +00:00 (Migrated from gitlab.com)

Some code still relies on the top level redacts field, for example in src/service/rooms/timeline/mod.rs, around line 385 there is TimelineEventType::RoomRedaction.

I also saw that the spec mentions this:

For backwards-compatibility with older clients, servers should add a redacts property to the top level of m.room.redaction events in when serving such events over the Client-Server API.

So I think when we parse m.room.encryption events to the PduEvent type in v11, we should add a top-level redacts key if it is missing. This will not mess with signatures, because the redacts key will be redacted away anyway.

The spec also says this, but I think we can ignore it for now:

For improved compatibility with newer clients, servers should add a redacts property to the content of m.room.redaction events in older room versions when serving such events over the Client-Server API.

Some code still relies on the top level redacts field, for example in src/service/rooms/timeline/mod.rs, around line 385 there is `TimelineEventType::RoomRedaction`. I also saw that the spec mentions this: > For backwards-compatibility with older clients, servers should add a redacts property to the top level of m.room.redaction events in when serving such events over the Client-Server API. So I think when we parse m.room.encryption events to the PduEvent type in v11, we should add a top-level redacts key if it is missing. This will not mess with signatures, because the redacts key will be redacted away anyway. The spec also says this, but I think we can ignore it for now: > For improved compatibility with newer clients, servers should add a redacts property to the content of m.room.redaction events in older room versions when serving such events over the Client-Server API.
This pull request is broken due to missing fork information.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin room-v11:room-v11
git checkout room-v11

Merge

Merge the changes and update on Forgejo.
git checkout next
git merge --no-ff room-v11
git checkout next
git merge --ff-only room-v11
git checkout room-v11
git rebase next
git checkout next
git merge --no-ff room-v11
git checkout next
git merge --squash room-v11
git checkout next
git merge --ff-only room-v11
git checkout next
git merge room-v11
git push origin next
Sign in to join this conversation.
No reviewers
No labels
Android
CS::needs customer feedback
CS::needs follow up
CS::needs on prem installation
CS::waiting
Chrome
Design:: Ready
Design:: in progress
Design::UX
E2EE
Edge
Firefox
GDPR
Iteration 13 IM
Linux
MacOS
Need::Discussion
Need::Steps to reproduce
Need::Upstream fix
Needs:: Planning
Needs::Dev-Team
Needs::More information
Needs::Priority
Needs::Product
Needs::Refinement
Needs::Severity
Priority::1-Critical
Priority::2-Max
Priority::3-Impending
Priority::4-High
Priority::5-Medium
Priority::6-Low
Priority::7-None
Progress::Backlog
Progress::Review
Progress::Started
Progress::Testing
Progress::Triage
Progress::Waiting
Reporter::Sentry
Safari
Target::Community
Target::Customer
Target::Internal
Target::PoC
Target::Security
Team:Customer-Success
Team:Design
Team:Infrastructure
Team:Instant-Messaging
Team:Product
Team:Workflows
Type::Bug
Type::Design
Type::Documentation
Type::Feature
Type::Improvement
Type::Support
Type::Tests
Windows
blocked
blocked-by-spec
cla-signed
conduit
contribution::advanced
contribution::easy
contribution::help needed
from::review
iOS
p::ti-tenant
performance
product::triage
proposal
refactor
release-blocker
s: dart_openapi_codegen
s::Famedly-Patient
s::Org-Directory
s::Passport-Generator
s::Requeuest
s:CRM
s:Famedly-App
s:Famedly-Web
s:Fhiroxide
s:Fhiroxide-cli
s:Fhiroxide-client
s:Fhirs
s:Hedwig
s:LISA
s:Matrix-Dart-SDK
s:Role-Manager
s:Synapse
s:User-Directory
s:WFS-Matrix
s:Workflow Engine
s:dtls
s:famedly-error
s:fcm-shared-isolate
s:matrix-api-lite
s:multiple-tab-detector
s:native-imaging
severity::1
severity::2
severity::3
severity::4
technical-debt
voip
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Matthias/conduit#987
No description provided.