Although in the spec push rules are only supposed to be handled by homeservers, clients generally need to support push rules to handle encrypted events.

Seeing as this is needed by both clients and servers, I wonder if it makes sense to implement this directly in Ruma.

This will require custom parsing, because the event type isn't changed when an event is redacted. Redacted events can be detected by checking for a redacted_because field.

ruma::api::client::r0::push::get_pushrule::Response takes a ruma::api::client::r0::push::PushRule, which is not compatible with any of the pushrule types defined in ruma::events::push_rules. IMO there should be an enum over all pushrule types and get_pushrule::Response returns that enum.

We have had accidentally-private fields a bunch of times now, also mod.rs files have appeared a number of times after we initially moved away from them. I'd also like to enforce some other things, like how serde_json::Value should always be import-renamed to JsonValue. There might be existing tooling for some of this, but maybe it's also feasible to create new tooling for a few things.

There are signatures that take UserId and DeviceKeyId and some that take ServerName and ServerKeyId Maybe we need to make the Signatures struct in ruma-signatures (forgot that existed) generic and provide Signatures<UserId, DeviceKeyId> and Signatures<ServerName, ServerKeyId>.

We should also update all the fields that hold signatures to use this type rather than a BTreeMap.

Dependent on matrix-org/matrix-spec-proposals#27.

You should probably use checked_add

Example which fails on my machine:

_matrix/key/v2/server

{"old_verify_keys":{"ed25519:a_YjQO":{"expired_ts":15159743990000,"key":"AYWls+cjEfl8R3u4mDSMX/MRhKXSgvjNgSruukDlHTU"}},"server_name":"half-shot.uk","signatures":{"half-shot.uk":{"ed25519:a_fBAF":"QJcEQVEK5E1pu4CW527z3+k6e/cY9Rmy5xj4RSeoL5P0cu+VICpa6P3vYmfLCNYuCQVFDlalVLCByfEKnv53CQ"}},"tls_fingerprints":[],"valid_until_ts":1617084632196,"verify_keys":{"ed25519:a_fBAF":{"key":"jIIoZEpAXY6GgNWybOc9GWHx11TBsNScGihLNx4KcaQ"}}}

Every room event might have been an encrypted event, e.g. a client will turn a m.room.encrypted event into a m.room.message event.

Clients need to present some info about this to users. For example an event wasn't encrypted but is posted in an encrypted room, clients might want to decorate such an event with a warning.

Clients will want to show:

• If an event was encrypted or not
• If an event is successfully verified or not
• Let clients record the sender key coming from the m.room.encrypted event, so if the trust state of the device holding the key changes, clients can change the presented verification state of the event.

I suggest we add an optional EncryptionInfo attribute to the events containing something like:

struct EncryptionInfo {
    verified: bool,
    sender_key: String,
    device_id: String,
    session_id: String
}

Most of those attributes will come from the encrypted version of the event, the m.room.encrypted event. The lack of the EncryptionInfo would indicate that the event was unencrypted.

Key verification events as per https://github.com/matrix-org/matrix-doc/pull/2241 will be sent out as normal room messages. This means they will contain a sender, event_id, origin_server_ts etc.

Key verification events need to be updated to include those attributes.

The affected event types are:

• m.key.verification.accept
• m.key.verification.cancel
• m.key.verification.key
• m.key.verification.mac
• m.key.verification.request
• m.key.verification.start

Adds an allow field to JoinRulesEventContent according to MSC3083. I wanted to make AllowRule an enum like

pub enum AllowRule {
    RoomMembership(RoomId)
}

But wasn't sure how to make that (de)serialize correctly.

It would be nice if criterion was not a regular dev-depenency that is built for tests since we only need it for benchmarks that we don't want to run on CI either way.

The one way to do this I can come up with so far is moving benchmarks to a separate, workspace-excluded crate.

Currently rings Ed25519 doesn't work for the WebAssembly target (https://github.com/briansmith/ring/issues/918), hence ruma-signature doesn't work on WASM either.

According to the latest rewrite of the MSCs.

The unstable prefixes are now used everywhere, as recommended in MSC1767.

A bunch of conversion methods between the legacy types and the new extensible events types have been removed to lighten the maintenance burden if/when this needs to be updated again, as they bring only little benefit.

The naming of the types has been streamlined by using the ContentBlock suffix consistently when a type is defined as such. That also means that some of those types are newtype structs purely for the semantic meaning as a reusable block.

It is recommended to review by file as it usually means reviewing by MSC. It might be easier than by commit, where some incomplete changes are done on event types when the content block types it depends on are changed too.

Preview: https://pr-1440--ruma-docs.surge.sh

The deserialization of PushRulesEventContent can fail because of the implementation of MSC3931 by Synapse that adds a new condition org.matrix.msc3931.room_version_supports.

We should add a hidden variant that allows to deserialize from unknown conditions. It should maybe keep all the data of the condition so clients can deserialize with a custom type if needed?

An unknown rule never applies.

After #1404, we still have one *Event type that implements Serialize: ToDeviceEvent. Currently this is being used by matrix-rust-sdk, but I'm pretty sure there will be an easy enough way around that. Once it no longer relies on this impl, we should remove it (if only for consistency).

Seeing

:WARN :matrix_sdk_base::client:crates/matrix-sdk-base/src/client.rs:529:Failed to deserialize a global account data event error=Error("unknown variant `org.matrix.msc3931.room_version_supports`, expected one of `event_match`, `contains_display_name`, `room_member_count`, `sender_notification_permission`", line: 1, column: 1018)

because the server sends 3931 field values we don't have support for yet. This PR adds support for it behind another unstable--flag. Not sure if we need/want to have another fallback support in case the flag is not activated.

Closes #1431.

Preview: https://pr-1405--ruma-docs.surge.sh

Here is the current unstable spec changelog to follow our progress, to be updated regularly until the next release.

To be sure we don't miss anything, ALL entries of the changelog (except the section about internal changes) should appear here in the same order and category. The ones that we have to implement should be linked to an issue and/or a PR or commit in this repository. If an extra step is necessary when the version is released (like moving it from an unstable feature flag), a subtask should be created. The ones that don't impact us should be struck.

1.1 Client-Server API

Backwards Compatible Changes

• [x] ~~Add information on standard error responses for unknown endpoints/methods. (#1347)~~
• [x] Add /rooms/<roomID>/timestamp_to_event endpoint, as per MSC3030. (#1366) #1427
  • [ ] Move out of unstable-msc3030

Spec Clarifications

• [x] ~~Clarify the power levels integer range. (#1169, #1355)~~
• [x] Clarify that /context always returns event even if limit is zero. (#1239) #1402
• [x] Clarify what fields are required when deleting a pusher (#1321) #1369
• [x] ~~Improve the presentation of push rule kinds and actions. (#1348)~~
• [x] ~~Add missing description to m.call.answer schema. (#1353)~~
• [x] ~~Fix various typos throughout the specification. (#1363)~~
• [x] ~~Move login API definitions to the right heading. (#1382)~~

1.2 Server-Server API

Breaking Changes

• [x] Remove keyId from the server /keys endpoints, as per MSC3938. (#1350) #1435

Backwards Compatible Changes

• [x] ~~Add information on standard error responses for unknown endpoints/methods. (#1347)~~
• [x] Add /timestamp_to_event/<roomID> endpoint, as per MSC3030. (#1366) #1427

Spec Clarifications

• [x] ~~Include examples inline instead of using a reference for invite endpoint definitions. (#1349)~~
• [x] ~~Fix POST _matrix/federation/v1/user/keys/claim response schema. (#1351)~~
• [x] ~~Correct the default invite level definition in the “Checks performed on receipt of a PDU” section. (#1371)~~
• [x] ~~Clarify that CNAMEs are permissible for server names. (#1376)~~
• [x] ~~Fix edu_type in EDU examples. (#1383)~~

1.3 Application Service API

Backwards Compatible Changes

• [x] ~~Add information on standard error responses for unknown endpoints/methods. (#1347)~~

1.4 Identity Service API

Backwards Compatible Changes

• [x] ~~Add information on standard error responses for unknown endpoints/methods. (#1347)~~

1.5 Push Gateway API

Backwards Compatible Changes

• [x] ~~Add information on standard error responses for unknown endpoints/methods. (#1347)~~

1.6 Room Versions

No significant changes.

1.7 Appendices

No significant changes.