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.
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.
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.
For example, if the database path is `/foo` and the media path is
`/foo/bar`, but `/foo/bar` is a symlink or hardlink to `/baz`, the
previous check would pass. The whole point of this check is to ensure
that the database and media data can't step on each other, so this check
is needed to deny that kind of situation as well.
It would probably be good to add a test for this behavior.
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)]`.
The two attributes being accessed here don't exist when calling though
flake-compat, so we need to handle that case by making the environment
variable unset if neither attribute exists.
Turns out fenix.packages.aarch64-linux.targets.x86_64-*.minimal.rustc
is an x86_64 compiler. The only component that you actually need to pull
from 'targets' for cross compilation is rust-std.
Because x86_64-unknown-linux-gnu is first in the target list, we were
getting x86 rustc and cargo binaries, making it impossible to compile
grapevine on an aarch64 host.
We were also missing aarch64-unknown-linux-gnu in the targets list,
which is used by the default package on a aarch64 host.
I like to put a bunch of untracked stuff in a /scratch directory for
each project, and then puth /scratch in my global gitignore. There are
usually some markdown notes files in here that I don't care about style
for. The previous markdownlint invokation didn't respect the global
gitignore, making local 'engage' runs kinda useless due to false
positives from the scratch dir.
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.
