… and fix the existing message logging example.

In ruma/ruma-api#34, I once again discovered that the macro code could use some refactoring. I will try to work on this soon-ish, although if somebody else wants to look into this, I'd happily mentor that person as well.

Of course without allocating when going from owned to borrowed, and without additional checks no matter the conversion direction.

See 13.13.1.5.2 Predefined Rules in the spec. These should probably be exposed as constants from push_rules.

It seems as though (basing this on the encryption stuff in matrix-rust-sdk) m.room.encrypted should be part of AnyStateEventContent?

Opening this issue so I don't forget about doing this.

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.

https://matrix.org/docs/spec/client_server/unstable#server-side-key-backups

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.

Matrix doesn't use floats anywhere, and removing support will let us get rid of the dtoa dependency.

Specifically for when we build a dummy http type to then change it later on.

• endpoint::Request -> http::Request
• http::Request -> endpoint::IncomingRequest

Currently it is just a string, but it is defined very clearly what it should look like

/// A decimal integer optionally prefixed by one of `==`, `<`, `>`, `>=` or `<=`.
///
/// A prefix of `<` matches rooms where the member count is strictly less than the given
/// number and so forth. If no prefix is present, this parameter defaults to `==`.
is: String,

We could represent this instead as a struct or enum and even easily provide a helper method for checking whether this condition applies to a given count of room members.

MSC2174)

My idea from ruma/ruma-events#82 for this:

enum RedactionEvent {
    // assuming redaction events are valid in v1 rooms
    V1(RedactionV1Event),
    // assuming room version 7 includes the format change
    V7(RedactionV7Event),
    V1V7Compat(RedactionV1V7CompatEvent),
}

struct RedactionV1Event {
    // message event fields
    redacts: EventId,
    content: RedactionV1,
}

type RedactionV7Event = MessageEvent<RedactionV7>;

struct RedactionV1 { ... }
struct RedactionV7 { ... }

Currently, most endpoints in ruma-client-api share the same error type. Since every endpoint has a documented set of errors it can return, we could capture this information by generating an appropriate enum.

My gut tells me that serde_json::Value in #52 is going to be a performance bottleneck, in particular for large event payloads. I have an idea for a way to speed this up, but would like to measure how useful it actually is. @DevinR528 are you interested in adding a few deserialization benchmarks with differently-sized events and differently-ordered fields for that (in the same or a subsequent PR)?

Deserialization benchmarks for other parts of ruma would also be appreciated (enums with #[serde(flatten)] and lots of variants or lots of data contained in one or more variants would probably benefit from some optimization in particular).

Based on the changelog on matrix-doc

New Endpoints

• Add /rooms/{roomId}/aliases for retrieving local aliases for a room. (#2562)

Backwards Compatible Changes

• Add data structures for defining moderation policies in rooms per MSC2313. (#2434)
• Optionally invalidate other access tokens during password modification per MSC2457. (#2523)
• Add User-Interactive Authentication for SSO-backed homeserver per MSC2454. (#2532)
• Add soft-logout support per MSC1466. (#2546)
• Replaced legacy room alias handling with a more sustainable solution per MSC2432. (#2562)

Spec Clarifications

• List available enum values for the room versions capability. (#2245)
• Fix various spelling errors throughout the specification. (#2351, #2415, #2453, #2524, #2553, #2569)
• Minor clarifications to token-based User-Interactive Authentication. (#2369)
• Minor clarification for what the user directory searches. (#2381)
• Fix key export format example to match the specification. (#2430)
• Clarify the IV data type for encrypted files. (#2492)
• Fix the .m.rule.contains_user_name default push rule to set the highlight tweak. (#2519)
• Clarify that an event_id is returned when sending events. (#2525)
• Fix some numbers in the specification to match their explanation text. (#2554)
• Move redaction algorithm into the room version specifications. (#2563)
• Clarify signature object structures for encryption. (#2566)
• Clarify which events are created as part of /createRoom. (#2571)
• Remove claims that the homeserver is exclusively responsible for profile information in membership events. (#2574)

Blocked on https://github.com/ruma/ruma-client-api/issues/164

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.

This is the motivation for https://github.com/ruma/ruma-events/issues/47 and blocked on that. It's labeled as hard, but once the ruma-events issue is resolved, it will be very easy. The concrete endpoints to update are:

• send_message_event
• send_state_event_for_key
• send_state_event_for_empty_key
• send_event_to_device

Key verification events as per matrix-org/matrix-spec-proposals#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

Sometimes it's useful being able to serialize things, e.g. to cache into persistent storage in a certain format like JSON, so it'd be helpful to have a feature that automatically derives API responses.

This needs an adjustment in the API macro around here and should be behind a feature flag:

https://github.com/ruma/ruma-api/blob/78717b71bfd9d126c85749e7fde0e41ea15c55ff/ruma-api-macros/src/api.rs#L454

Deserialization(RequestDeserializationError { inner: Json(Error("EOF while parsing a value", line: 1, column: 0)), http_request: Request { method: GET, uri: /_matrix/client/r0/rooms/!RhCpxacCaP5pvSQhwo%3Amatrixtesting.koesters.xyz/members?not_membership=leave&at=103

body: []

It would be really useful to be able to compile ruma-client to WASM and run it inside a browser. I guess that would require feature'izing hyper and adding a fetch/xhr feature, maybe using reqwest.

It would be nice to have individual issues for new contributors to jump in on, as well as to keep track of what's left to do.

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

https://github.com/uhoreg/matrix-doc/blob/cross-signing2/proposals/1756-cross-signing.md

Not sure if this is out of scope, but the UIAA login fallback endpoint and the generic login fallback endpoint are missing. These both return HTML pages that the user can use to complete login.

https://github.com/ruma/ruma/blob/master/ruma-client-api/src/r0/message.rs

Is this just from getting everything to work with the new ruma-events?

https://github.com/ruma/ruma/blob/master/ruma-client-api/src/r0/sync/sync_events.rs#L260

Feel free to assign me to these I could just as easily open a PR but I want to make sure this is correct.

EDIT: This is no longer possible with the Ref types no longer existing in ruma-identifiers. The below might become possible again with custom DST based identifiers, but those are far away. See the comment below for why this issue is still useful. The idea in the description might still be implemented, but as _ref macros that would mostly be useful for tests (though is it worth it to write the extra code for that?).

It's already possible to obtain SomeIdRef<&'static str>s from string literals. However, that involves verifying the string literal at runtime. If we can create const fn constructors for the ID types (which I think should not be an issue, we just have to move the logic into a dedicated, non-type-generic method rather than a TryFrom impl), we can create macros that do the construction of SomeIdRef<&'static str> at compile time, something along the lines of:

macro_rules! user_id {
    ($s:literal) => {
        {
            const RES: $crate::UserIdRef<'static> = $crate::UserIdRef::from_str($s).unwrap();
            RES
        }
    }
}

although for the unwrap() to work, some additional compiler work is yet to be done, plus these macros would have to be Nightly-only for some time.

… one for the sending side, one for the receiving side.

This may help reduce the amount of copying around of bounds that people have to do when the Outgoing trait is reintroduced (which it is almost certainly going to be to allow usage of borrowed identifiers).

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.

… and possibly replace them with Box<serde_json::value::RawValue>.

serde_json::Value has mostly been replaced by Box<serde_json::value::RawValue>, but it doesn't seem to be working in BTreeMap<String, Value>. Needs further investigation.

https://matrix.org/docs/spec/client_server/unstable#get-matrix-client-r0-rooms-roomid-messages

I think there's no big reason not to, but I'm not sure.

Moved over from https://github.com/ruma/ruma-api-macros/issues/5.

There are several places in the expanded code where unwrap/expect are used. These should be converted to normal Result-based error handling.

Since it is not really tied to events in any way.

Long-term, we need to make basically all structs #[non_exhaustive] so we can extend them without breaking changes. We still need to have ways for users to create them though, apart from using Deserialize. My current feeling on this is that we should have manual constructors that have parameters for the required fields, with the rest being set either using mutation or (preferably) using struct update syntax:

// Already possible today because we introduced this constructor at some point. We
// should probably rename that constructor to just `new`, and add similar ones to all
// structs that are made non-exhaustive.
let text_message = MessageEventContent::Text(TextMessageEventContent {
    relates_to: Some(RelatesTo {
        in_reply_to: InReplyTo { event_id: my_event_id }
    },
    ..TextMessageEventContent::new_plain("this is the message body")
});

// For cases where some fields are mandatory and a constructor without named arguments
// would be unclear, add an exhaustive `Init` variant of the same struct with a
// `From<ThingInit> for Thing` implementation (if this comes up often enough, we can
// generate both of these things).
let third_party_protocol_instance = ProtocolInstance {
    icon: Some("mxc://path/to/icon.png".into()),
    ..ProtocolInstance::from(ProtocolInstanceInit {
        desc: "Freenode IRC network".into(),
        fields: BTreeMap::new(),
        network_id: "freenode".into(),
    })
};

There's now a crate intended to share a "body" type between HTTP client implementations, which we can use to prevent ruma-api from being bound to Hyper. I didn't check if Hyper actually supports it yet, but if/when it does, we should switch over.

Here's the crate: https://crates.io/crates/http_service
And here's more background on why we wanted this: rustasync/team#84

Especially in ruma_events::{collections::{all, only}, stripped}, we are missing any tests at all. We only know from real-world usage that our code seems to do roughly the right thing. Deserialization of custom types as part of the collection types is a bit more complex than deserialization of known event types, so it's one of the more important test cases to add.

In addition, deserializing a known event type as Custom(Room|State)Event might be something that we want to disallow (I'm not sure whether we currently allow it) and test.

In 0.21, we had custom events for all of our "collection" enums. In the api22 branch, we don't currently have them. This should be fixed before releasing 0.22, but doesn't block merging api22 into master.

… which should be optional. I'm not sure whether we support optional header parameters right now.

The search is performed case-insensitively on user IDs and display names preferably using a collation determined based upon the Accept-Language header provided in the request, if present.

https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-user-directory-search

This is not properly documented in the spec, but you can see /kick referring to a reason field here:
https://matrix.org/docs/spec/client_server/unstable#post-matrix-client-r0-rooms-roomid-kick
maybe we should ask in #matrix-spec first if this is correct

ruma_client_api::r0::membership::kick_user
ruma_events::room::member::MemberEventContent

The reason the user has been kicked. This will be supplied as the reason on the target's updated m.room.member event.

See https://matrix.org/docs/spec/client_server/r0.6.1#fallbacks-and-event-representation

Since one can initialize a tuple struct with TupleStruct { 0: expr, 1: expr }, it should be possible to merge the initialization code of newtype body fields and regular body fields as well as query map fields and regular query fields. There may places other than initialization too where things can be simplified by operating over both named and unnamed fields.

Needed for #15, #16.

With this + ruma/ruma-identifiers#24 we'll also be able to update the server_name variants to return references to this new type. There is probably no point in releasing the new type under a non-breaking version 0.16.1 because it will be a breaking change for the higher-level crates to switch to this new type anyway.

I'm thinking we should have colons after each of the keywords, to make the content look a bit more ordinary, and to make error: ErrorType look less out of place.