The only change to the internal interface for this one is removing the
current_third_party_invite argument from state_res::auth_check. Ruma now
fetches the event using the fetch_state closure. This is convenient for
us, because we previously didn't bother to implement it.
The significant change is 26edd40a704040e7104161da81c9bae91b7ddcaa,
which removes the global compat feature, so that each compat feature
must now be enabled individually. We're using the slightly later
1387667d because it has a bugfix that ruma needs to compile.
There are a few ruma compat features that were not previously part of
the global compat feature:
- compat-arbitrary-length-ids
- compat-upload-signature
- compat-encrypted-stickers
I have not enabled these here, to avoid a behavior change.
There are two new default features:
'system-proxy' for reqwest, which we are not enabling because it only
does anything on windows and mac, which we don't support.
'prefer-post-quantum' for rustls, which we are not enabling because it
only does anything for aws-lc-rs, which we don't use.
The first part replaces a loop which is probably a performance
improvement, and the second part addresses a shellcheck complaint about
not declaring and assigning separately.
It's no longer necessary since it's equivalent to the default-features
one now. The `DIRENV_DEVSHELL` thing is left in place however in case
that becomes useful again in the future.
Servers are required to preserve unknown properties in event content,
since they may be added by a future version of the spec. Round-tripping
through RoomRedactionEventContent results in dropping all unknown
properties.
Previously we were mashing everything together as RoomAccountDataEvent,
even the global events. This technically worked, because of the hidden
custom fields on the ruma event types, but it's confusing and easy to
mess up. Separate methods with appropriate types are preferable.
In preparation for adding some additional methods at the service level.
Dropping the tracing spans for the data methods, because two duplicate
spans here seems kinda excessive.
Previously we were only using trust-dns for resolving SRV records in
server discovery, and then for resolving the hostname from the SRV
record target if one exists. With the previous behavior, admins need to
ensure that both their system resolver and trust-dns are working
correctly in order for outgoing traffic to work reliably. This can be
confusing to debug, because it's not obvious to the admin if or when
each resolver are being used. Now, everything goes through trust-dns and
outgoing federation DNS should fail/succeed more predictably.
I also expect some performance improvement from having an in-process DNS
cache, but haven't taken measurements yet.
This used to be supported, as we explicitly call std::fs::create_dir_all
when initializing these, but it was broken in
b01b70fc20, which attempts to canonicalize
the paths to check for overlap before creating them.
