So it's true that the blog post doesn't enumerate each and every bug in Matrix today. You're right that there's a fundamental difference between IRC and Matrix

So it's true that the blog post doesn't enumerate each and every bug in Matrix today. You're right that there's a fundamental difference between IRC and Matrix. In Matrix, the room history and state is represented by a single datastructure replicated across the participating servers. In IRC, each user effectively sees their own version of the room history - for instance the only rule for whether you can see messages in a room is whether the server considers your client joined to that room (given lack of scrollback in IRC). Similarly, poweruser IRC features such as the ability for chanops to send messages in a channel which are only visible to specific users are hard to map to Matrix's model. Matrix expects it to be consistent and well-defined as to who is in a room at a given time, and who can see what message. I think the actual bug you're talking about is https://github.com/matrix-org/matrix-appservice-irc/issues/212 https://github.com/matrix-org/matrix-appservice-irc/issues/2..., which boils down to the fact there is a race when the bridge starts up during which messages are synced between Matrix and IRC without yet knowing whether the Matrix participants in the room have yet joined the IRC side of the bridge. Now, in practice this hasn't been a major problem because: a) the bridge starts up fast, b) nowadays the bridges are stable and are rarely restarted, c) the chances of the membership changing on the IRC side whilst the bridge restarts and racing with the Matrix-side membership are fairly slim. Possible fixes include: * Making the bridge refuse to join traffic until it's fully started up. This ends up being a usability v. privacy tradeoff, but would be trivial to implement. * Implementing per-msg ACLs in Matrix, so that different users in a room get to see precisely the messages which correspond to the points where their IRC client was connected to the network. * Bridging each IRC channel into a separate Matrix room (horrid, because it means the Matrix users would only be able to interact with each other by wormholing via IRC). Now, as you can tell from the comment history on the bug, it's simply not got to the top of the todo list to address. It occasionally comes up in conversation with Freenode, but given that the bridge has been pretty much solid for the last 6 months, it's not been a big consideration. We had NO IDEA that this was a problem for Hackint, and were shocked at https://hackint.org/#20181028_Matrix_Bridging_Sunset https://hackint.org/#20181028_Matrix_Bridging_Sunset given nobody (as far as we know) had discussed the issue with us until after they'd already made a decision. I am also unconvinced that this creates 'massive headaches for IRC network and chanops', and I wonder if historical perf issues with Synapse or similar were more of a contributing factor here. The biggest issues we've actually seen on IRC bridging are a) handling the floods of spam coming in from IRC; and b) the risk of some twit using Matrix to bridge together disparate rooms on different networks. Both of these are effectively social/reputation problems that we're working on. TL;DR: if you're having problems with a particular bit of Matrix, please file a bug or upvote/comment an existing bug, and if necessary yell at us until it's fixed. We're unlikely to fix things which we don't realise are problems for people. [edited for typo & clarity]