The spec doesn't spell out explicitly that the server should check this,
but it does list M_NOT_FOUND "room alias ... not found" as an example
error response.
When upgrading rooms, we reassign any local aliases from the old room to
the new room. This commit updates the m.room.canonical_alias events in
the old and new rooms to reflect which aliases were moved. The spec is
unclear on whether the server should do this[1], but it's consistent
with synapse's behavior.
I went with putting the canonical alias update logic inline, rather than
something like add_canonical_alias and remove_canonical_alias helper
functions to the alias service, because it's desirable to have the alias
updates be sent as a single event than a separate event for each change.
[1]: https://github.com/matrix-org/matrix-spec/issues/2142
Without explicitly removing the old alias when reassigning aliases, we
were listing the alias on both rooms in the GET client/v3/rooms/{roomId}/aliases
endpoint. Resolving the alias still always pointed to the correct room.
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.
Previously, read receipts would only be forwarded via federation
incidentally when some PDU was later sent to the destination server.
Trigger a send without any event to collect EDUs and get read receipts
out directly.
The primary motivation for this change is to support databases that
don't take a path, e.g. out of process databases.
This configuration structure leaves the door open for other media
storage mechanisms in the future, such as S3.
It's also structured to avoid `#[serde(flatten)]` so that we can use
`#[serde(deny_unknown_fields)]`.
Previously we required every alias in a canonical alias event sent by a
client to be valid, and would only validate local aliases. This
prevented clients from adding/removing canonical aliases if there were
existing remote or invalid aliases.
Previously, we would only attempt to validate the aliases in the event
content if we were able to parse the event, and would silently allow it
otherwise.
I think it's most important for people to read the "Chat with us", "Can
I use it?" and "Expectations management" sections, though I'm not sure
what the best ordering is. This is probably fine.
This is also a good spot to link to the pre-built binaries. And since I
did that, I can also remove the bit about not publishing binary builds
from the introduction section.
The previous logic would increment the backoff counter both when a
request actually fails and when we do not make a request because the
server was already in backoff. This lead to a positive feedback loop
where every request made while a server is in backoff increases the
backoff delay, making it impossible to recover from backoff unless the
entire backoff delay elapses with zero requests.
Failing to reset the backoff state resulted in a monotonically
increasing backoff delay. If a remote server was temporarily
unavailable, we would have a persistently increased rate of key query
failures until the backoff state was reset by a server restart. If
enough key queries were attempted while the remote was unavailable, it
can accumulate an arbitrarily long backoff delay and effectively block
all future key queries to this server.
* Capitalize Conduit and Grapevine
* Replace a "Not" with "Note"
* Change a "Conduit 0.7.0" to "Conduit <0.8.0"
* Expand "db" to "database" and "database schema" as appropriate
This was based on the similar section in the hedgedoc. I dropped the bit
about grapevine users getting banned from the conduwuit rooms cause we
haven't heard about that happening for a while and the original case was
pretty unclear.
If all join requests to resident servers fail or if the joining server
is the only resident server (i.e. the room is local-only), we would
previously send a 500 error, even if the more correct response would be
M_UNAUTHORIZED (e.g. if the user tries to join an invite-only room).
To fix this, we now return the error generated by attempting the join
locally, which correctly informs the client about why their request
failed.
The maintainers had a discussion internally and decided it's unlikely
that we'll have the capacity to try to do a rewrite, which was the
original reason for the suffix's presence. So, now can get rid of it.
For HTTP/1 requests, an inbound Request's URI contains only the path and
query parameters, since there's no way to synthesize the authority part.
This is exactly what we need for the X-Matrix "uri" field.
HTTP/2 requests however can contain the :authority pseudo-header, which
is used to populate the Request's URI. Using a URL that includes an
authority breaks the signature check.
Largely inspired by conduit MR !631
(https://gitlab.com/famedly/conduit/-/merge_requests/631).
Co-authored-by: strawberry <strawberry@puppygock.gay>
