progval
Re-add support for rooms with no canonical alias
For a little while now (since f515c9724d47253cfa0752add6d09eb0c879ed5c?), M51 waits for a canonical_alias event before sending any message from a room. This means that rooms without one are never shown.
Instead it should probably remember somehow which rooms were not announced, and do it at the end of each poll.
However, fixing this bug will have the downside of showing rooms that are unlikely to be interesting on the IRC side:
- DM rooms (which are often encrypted)
- spaces
and if a DM room is not encrypted, then there is a workaround: manually add a canonical alias (which also avoids showing the random room id). So is this really desirable?
There are also room where admins (users who create them) don't set canonical aliases. In some matrixes e.g. companies that use it as their own internal chat the people that create channels might not care, don't know or are just lazy.
I wish that channels that don't have canonical names would get their name based on the display name.
For a real-world example of this being a problem, the official Nix/NixOS matrix channel has use-name #nix:nixos.org, but doesn't appear to have a canonical name; on connect it doesn't show up in the channel list and the message !KqkRjyTEzAGRiZFBYT:nixos.org: Invalid room renaming to #nix:nixos.org (sent by grahamc:nixos.org) appears in the server buffer.
~~Adding a local alias for it via Element (#nixos:ancilla.ca) doesn't appear to work either.~~ I ended up reconnecting weechat for unrelated reasons and now both #nix:nixos.org (which I added a local alias for) and #nix-on-arm:nixos.org (which I did not, and had the same problem) show up, so this may be unrelated. (DMs still aren't showing up, though, which is probably a showstopper for me in the long-term.)
This is telling you the alias is altogether invalid, not that it's non-canonical.
nixos.org is currently migrating to their own homeserver after being kicked out from EMS, so it's likely to be temporarily misconfigured.
nixos.org is currently migrating to their own homeserver after being kicked out from EMS, so it's likely to be temporarily misconfigured.
Not yet, so it's likely an old misconfiguration that nobody had noticed / complained to us about before. I fwded this to the Nix Matrix discussion channel and someone can maybe look at fixing it.
admin (Moderation Team) set the main address for this room to #nix:nixos.org.
I just dropped and readded the main alias, if that helps.
I think it mysteriously started working before you did that, but for whatever reason, it's working now.
As to the actual bug, it does seem to be properly-ish bridging channels without a canonical alias into IRC; the problem is that they show up as !abcdef:example.com with the display name prefixing the topic. It looks like this is intentional (compute_topic() in the poller) but it severely limits usability in cases where channels are automatically created (e.g. interprotocol bridges on the matrix side) or where the admin has simply failed to set a canonical alias.
Using the display name would cause problems when multiple servers have channels with the same DN, but I think using #display-name:server would suffice for the vast majority of use cases.
Ok, there's also the fact that if I disconnect and reconnect, only the channels with canonical aliases are reinstated, the rest are not. That's a bit more of a problem. Nor does JOIN suffice; I instead need to (re)join them from Element to get them to show up IRC-side. (I will still receive messages sent to those channels, if the buffers are still open, but I will never actually have joined them.)
After thinking this over and making some local changes, I wonder if a more general solution might be to decouple "channels joined in matrix" from "channels joined on IRC".
- A new IRC connection starts with no channels joined; M51 just builds its internal view of rooms
LISTshows all rooms on the matrix sideJOINon a room that M51 already knows about just sets the:joinedbit, sends the announce, maybe replays some backscroll if we want to get fancyJOINon a room it doesn't know about triggers the existing behaviour: tries to join it through Matrix and if that works, forwards the results to IRCPARTunsets the:joinedbit and drops the IRC-side channel membership
This might also simplify the machinery that tries to figure out when and if to announce rooms when processing the backlog, although it complicates backscroll message processing if we want to be able to sync up the IRC-side client post hoc.
This means that noncanonicalized rooms show up in LIST (and we can put additional metadata in the topic field there, like display name, parent space if any, etc) and can still be accessed on an opt-in basis, without immediately manifesting an IRC channel for every space, deprecated room, etc that the user is in on the matrix side.
I'm probably going to end up implementing this for my own purposes (and will publish), but it might be useful more generally, unlike a lot of the other changes I'm making.