4 ms·

What this post doesn’t mention is the failure to tackle a fairly significant problem[0] leading to Matrix bridges being banned from at least one major irc netwo

What this post doesn’t mention is the failure to tackle a fairly significant problem[0] leading to Matrix bridges being banned from at least one major irc network (hackint) and a number of irc channels elsewhere. If you were thinking of using Matrix because you thought it might allow you to access all your old chat systems as well, think again. [0] The Matrix bridge model fundamentally doesn’t map to how IRC works in reality, and causes massive headaches for IRC network and channel operators.

floatboth 8y ago
Matrix works great with Freenode. What exactly is the problem? How does it not map? I authenticated with my freenode nick/password, and it's acting as a regular bouncer pretty much…
- vertex-four 8y ago
  There’s a number of larger channels which have banned Matrix users, and various smaller channels I’m in have been considering banning them due to the privacy concerns of Matrix.org (based in the U.K., iirc, and potentially subject to an easy court order requiring them to release their data) keeping a full, eternal log of all communications in any irc channel where a Matrix user has joined. Freenode is also not the entirety of IRC.
  - Arathorn 8y ago
    The main reason why some channels have banned Matrix in the past was instability in the bridge causing occasional netsplit style behaviour where all the Matrix users would bulk-part and bulk-join. Since stability was fixed earlier this year, it should no longer be a concern. In terms of privacy concerns: yes, Matrix.org is currently provided by a UK legal entity, just as many IRC servers are too. But if you want privacy from a malicious server admin or government or whoever then you should be using end-to-end encryption, and you shouldn't be using IRC. I'm not sure the legal jurisdiction makes much difference (unless the UK outlaws E2E, which then becomes a whole new can of worms). If you're worried about the fact that Matrix rooms contain scrollback, then it's (again) unfortunate that nobody has cared enough about this to file a bug on https://github.com/matrix-org/matrix-appservice-irc/issues https://github.com/matrix-org/matrix-appservice-irc/issues to request configurable retention per bridge. Meanwhile, https://github.com/matrix-org/matrix-doc/issues/447 https://github.com/matrix-org/matrix-doc/issues/447 i s the general spec issue if you'd like to upvote or comment on it. But in the end, Matrix is FOSS, and we kinda hope that folks will contribute stuff like this that we simply haven't got to yet.
    - vertex-four 8y ago
      It is, in general, not a concern of IRC users that Matrix is broken past what they need to do to protect themselves from it, and attempting to fob Matrix development off on them is really not on. While I agree that many communications should go over e2e chat, there are a number of low-real-risk channels on IRC that occasionally discuss drugs and similar, and adding the additional risk vector that ten years down the line some prosecutor decides to dig the logs up through Matrix.org when everyone else has long since lost them isn’t really cool. My understanding from last time I went through the codebase is that logs will not be deleted even if all Matrix users leave the room.
      - Arathorn 8y ago
        > attempting to fob Matrix development off on them is really not on. My point is that if you have requirements for a bridge (eg configurable scrollback retention), you should submit a feature req to let us know about it at the time rather than ragequitting and telling people that matrix is broken. Anyway, point taken that we need to make scrollback retention configurable (whether for bridging or in general); have bumped it up the todo list.
  - floatboth 8y ago
    Oh, right, the log "issue". I think it's extremely naive to try to keep an "unlogged" IRC channel, since any user could secretly "leak" the logs.
Arathorn 8y ago
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]

floatboth 8y ago

Matrix works great with Freenode. What exactly is the problem? How does it not map? I authenticated with my freenode nick/password, and it's acting as a regular bouncer pretty much…

vertex-four 8y ago
There’s a number of larger channels which have banned Matrix users, and various smaller channels I’m in have been considering banning them due to the privacy concerns of Matrix.org (based in the U.K., iirc, and potentially subject to an easy court order requiring them to release their data) keeping a full, eternal log of all communications in any irc channel where a Matrix user has joined. Freenode is also not the entirety of IRC.
- Arathorn 8y ago
  The main reason why some channels have banned Matrix in the past was instability in the bridge causing occasional netsplit style behaviour where all the Matrix users would bulk-part and bulk-join. Since stability was fixed earlier this year, it should no longer be a concern. In terms of privacy concerns: yes, Matrix.org is currently provided by a UK legal entity, just as many IRC servers are too. But if you want privacy from a malicious server admin or government or whoever then you should be using end-to-end encryption, and you shouldn't be using IRC. I'm not sure the legal jurisdiction makes much difference (unless the UK outlaws E2E, which then becomes a whole new can of worms). If you're worried about the fact that Matrix rooms contain scrollback, then it's (again) unfortunate that nobody has cared enough about this to file a bug on https://github.com/matrix-org/matrix-appservice-irc/issues https://github.com/matrix-org/matrix-appservice-irc/issues to request configurable retention per bridge. Meanwhile, https://github.com/matrix-org/matrix-doc/issues/447 https://github.com/matrix-org/matrix-doc/issues/447 i s the general spec issue if you'd like to upvote or comment on it. But in the end, Matrix is FOSS, and we kinda hope that folks will contribute stuff like this that we simply haven't got to yet.
  - vertex-four 8y ago
    It is, in general, not a concern of IRC users that Matrix is broken past what they need to do to protect themselves from it, and attempting to fob Matrix development off on them is really not on. While I agree that many communications should go over e2e chat, there are a number of low-real-risk channels on IRC that occasionally discuss drugs and similar, and adding the additional risk vector that ten years down the line some prosecutor decides to dig the logs up through Matrix.org when everyone else has long since lost them isn’t really cool. My understanding from last time I went through the codebase is that logs will not be deleted even if all Matrix users leave the room.
    - Arathorn 8y ago
      > attempting to fob Matrix development off on them is really not on. My point is that if you have requirements for a bridge (eg configurable scrollback retention), you should submit a feature req to let us know about it at the time rather than ragequitting and telling people that matrix is broken. Anyway, point taken that we need to make scrollback retention configurable (whether for bridging or in general); have bumped it up the todo list.
- floatboth 8y ago
  Oh, right, the log "issue". I think it's extremely naive to try to keep an "unlogged" IRC channel, since any user could secretly "leak" the logs.

Arathorn 8y ago

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]