jdev - 2021-05-27

  1. rom1dep

    has anyone had a look at the component that matrix developed for bridging with IRC servers? Is that something that could be enhanced to serve MUCs in addition to whatever's matrix? If IRC Networks have already bitten the bullet and are running that on their servers, wouldn't that be the easiest and nicest way to bridge with IRC, while simultaneously having the typical MUC features between XMPPers? (MAM, receipts, avatars, …)

  2. moparisthebest


  3. mathieui

    are we talking about this? https://github.com/matrix-org/matrix-appservice-irc

  4. rom1dep

    dunno, maybe? I'm assuming that whatever they do requires server-side support, and if it's the new normal for the freenodes/libera.chat and others to run that service, then why the hell not benefit from it if we can PR our way into it

  5. moparisthebest

    rom1dep: oh the thing freenode runs to let matrix folk join? They could already run biboumi instead

  6. Zash

    rom1dep, what are you suggesting exactly?

  7. Zash

    Matrix "appservices" are equivalent to external components in the XMPP world, they have a privileged connection to the server.

  8. rom1dep

    moparisthebest: you think? Isn't their bridge letting users on matrix side see each others as matrix clients/the irc room as a native matrix room? I don't see how biboumi alone would emulate that

  9. mathieui

    rom1dep, it is slightly different

  10. mathieui

    their appservice is creating a matrix room and updating state both ways

  11. mathieui

    you can also create any room and link it later to an irc channel

  12. mathieui

    (which is not what happens on the networks)

  13. mathieui

    A Matrix room can be connected to a IRC network in one of two ways: A portal room, which is a Matrix room created by the bridge on demand when a Matrix user attempts to join an alias that does not yet exist. E.g. #freenode_#myproject:matrix.org. The bridge will hold power over this room and grant moderator status (half-power) to any IRC operators or Matrix users with IRC ops in the room. A plumbed room (also known as provisioning). A Matrix user may create a room ahead of time for their community and later on decide to "plumb in" IRC users to that room. They can do this via an interative UI in Element, via the !plumb command or even via a HTTP endpoint. If done interatively, the bridge has a verification process to ensure the user on the Matrix side has the blessing of the IRC ops first. However, it's possible for the IRC bot to lack kick abilities in the room so kicks and bans may not be bridged both ways.

  14. mathieui

    and afterwards it gives a link to the forbidden page on matrix.org which will make MattJ unhappy

  15. moparisthebest

    rom1dep: what native XMPP muc features are you missing from biboumi

  16. mathieui

    moparisthebest, seeing other XMPP users as XMPP users

  17. mathieui

    and not through IRC

  18. MattJ

    moparisthebest, the situation is that two people joined to a "MUC" that is really an IRC channel won't see typing notifications, avatars, etc. of other XMPP users

  19. mathieui

    though that is not how the matrix irc appservice works (in "portal mode", that is)

  20. rom1dep

    so, we could hook onto this appservice, let it handle the IRC side of the sync, and translate the other side to a MUC, that way we don't have to reinvent a new biboumi nor to fore the hand of the IRC networks to add yet another gateway (they'd just update their existing matrix bridge)

  21. rom1dep

    lemme backlog

  22. mathieui

    rom1dep, this appservice is not really helpful

  23. moparisthebest

    Oh, well I imagine that could be fixed fairly easily in biboumi

  24. mathieui

    I mean, I expect 95% of the code to be matrix-related

  25. moparisthebest

    biboumi has 99% of everything you want except avatars I guess

  26. mathieui

    moparisthebest, and possibly some heavy rewrites to not have split views of each rooms and handling of XMPP users in the same room

  27. mathieui

    (but I have not looked at the code in ages)

  28. rom1dep

    mathieui: I think there is a ton that goes on though, like users joining from matrix being given a IRC nick and such. Not having to reinvent such things could be good

  29. mathieui

    I don’t see how that’s different, they just take the display nick and add a [m] behind (that is configurable)

  30. rom1dep

    moparisthebest: I think I remember louiz' saying it wasn't a design goal of biboumi and would not be trivial to do

  31. rom1dep

    mathieui: they have the component create nicks for as many users are joined from the matrix side, take care of chatlog historisation, etc

  32. rom1dep

    biboumi can't deduplicate MAM for instance

  33. moparisthebest

    Biboumi supports single server mode already though, so it's partially a design goal

  34. moparisthebest

    Who really wants avatars anyway... :)

  35. rom1dep

    means A joins ; A leaves ; B joins ; B leaves → A doesn't sees B backlog, B doesn't see A backlog

  36. rom1dep

    and when A and B are joined together, biboumi happily logs twice the same stuff

  37. moparisthebest

    My point is I think making that work for XMPP is doing 99999x more work than any changes you might want to make to biboumi

  38. rom1dep

    but why, though?

  39. moparisthebest

    You could make biboumi not do that, for instance

  40. mathieui

    19:02:45 rom1dep> and when A and B are joined together, biboumi happily logs twice the same stuff → well that’s easy to know why, it is because that way you don’t have to handle any kind of privileges or state tracking linked to history

  41. mathieui

    much easier

  42. rom1dep

    however crappy and specific this component might be, at least 50% of it does the job

  43. moparisthebest

    And biboumi does 97% of the job

  44. rom1dep

    it doesn't, it addresses a different problem

  45. rom1dep


  46. moparisthebest

    And the matrix bridge doesn't? :)

  47. lovetox

    hey, again issue with 0050

  48. lovetox

    The "sessionid" attribute helps to track a command execution across multiple stages. This attribute MUST be present for subsequent stages, and the responder SHOULD initialize (if not provided) or maintain this attribute. The value of this attribute MUST NOT be empty or null, but otherwise can be any string value. This value MUST be maintained by a requester while executing a command.

  49. lovetox

    lots of MUST in there but when it counts its vague

  50. lovetox

    This attribute MUST be present for subsequent stages

  51. lovetox

    so does this mean if there is no stage, means i execute a command, and the server responds with "completed" there needs to be no sessionid?

  52. Zash

    Yeah. Single-step commands could probably get away with ignoring that attribute.

  53. lovetox


  54. lovetox

    not sure if i can handle that easily

  55. lovetox

    whole thing is iq based, why do we need a session anyway

  56. Zash


  57. Zash

    Basically a session cookie, so useful for maintaining state serverside.

  58. Zash

    But you could also serialize the state into a hidden field

  59. flow

    lovetox, being IQ based is not enough, cause one ad-hoc command session may span over multiple IQ request-response pairs

  60. rom1dep

    mathieui: from the 2 definitions that you posted ("plumbed" or "portal"), I'm still not sure to understand how they work, and whether the IRC networks that currently bridge with matrix have to run any component on their side to make that possible

  61. rom1dep

    my assumption was that they do, and if that's the case, then the opportunity to make large IRC networks "XMPP Native" is enormous. If not, then forget about it

  62. Zash

    I imagined IRC networks mostly have to disable some rate limits and such, so that bridges can create as many users as they need to, from some small set of IP addresses.

  63. moparisthebest

    also webirc things

  64. rom1dep

    Zash: I thought that the bridge was running behind the ircd so that it would always be logging, deduplicating messages and so forth. If those

  65. rom1dep

    Zash: I thought that the bridge was running behind the ircd so that it would always be logging, deduplicating messages and so forth.

  66. Zash

    Need network diagrams.

  67. rom1dep

    my understanding is that for this kind of bridge to work reliably (one pretending to be a matrix room for all matrix users), only one of the connected IRC accounts needs to serve as proxy on behalf of all others, otherwise, when IRCUSER1 sends a "helloworld" message, the bridge sees "helloworld" × number of bridged users reaching it at subtely different timestamps. when this user leaves, another one needs to be rotated in and take over (probably with rules such that enough of the other dummies should have seen the first user leaving so the whole thing is netsplit/timeout resilient) none of that is required if it's the server to send the bridge `"IRCUSER1 sent "helloworld" to #room`

  68. Zash

    If you're managing a horde of simulacra then it's easy enough to have one extra for the bot itself which handles incoming messages.

  69. jonas’

    rom1dep, this breaks down once the users have different privileges

  70. pulkomandy

    It seems easier to just host the room on xmpp and have something to allow irc user to connect to it directly (not going through an existing irc server). I don't see what you need the irc server for here and it makes everything more complicated?

  71. rom1dep

    jonas’: I'm sure of that

  72. jonas’

    pulkomandy, for consistency, it’s easier if the source of truth is on the network with the "lower" capabilities

  73. jonas’

    (in this case, IRC)

  74. Zash

    jonas’, areyousure?

  75. rom1dep

    pulkomandy: yep, many existing communities are already on <insert IRC net here>

  76. Zash

    pulkomandy, https://github.com/moparisthebest/xmpp-ircd might be doing that

  77. Zash

    but it'll get weird unless you enforce IRC limitations

  78. pulkomandy

    Depends what your goals are. I'd be fine with "xmpp users get all the cool features, grumpy people who really want to stick to irc get a limited view on things"

  79. Zash

    which may or may not be desirable

  80. pulkomandy

    Seems the way to go to convince people to migrate

  81. rom1dep

    my idea was that if matrix has it all figured-out, we can just hop on the bandwagon and use their bridge (or enhance it to make it behave as an XMPP room on top of being a matrix room)

  82. rom1dep

    my idea was that if matrix has it all figured-out, we can just hop on the bandwagon and use their bridge (or more precisely, enhance it to make it behave as an XMPP room on top of being a matrix room)

  83. pulkomandy

    (I'm saying that but I'm annoyed when Matrix bridging to irc says "user x posted a long message, follow this https link to view it")

  84. homebeach

    Are there any other networks bridged to xmpp with public bridge except ircnet?

  85. homebeach

    Are there any other irc networks bridged to xmpp with public bridge except ircnet?

  86. jonas’

    pulkomandy, what do you do with XMPP nicknames which are not valid in IRC?

  87. rom1dep

    (I, too, prefer biboumi's splitting the message across several smaller ones)

  88. rom1dep

    homebeach: how does that work for ircnet?

  89. pulkomandy

    I don't know, you punycode them?

  90. jonas’

    pulkomandy, length limits, but also, how do IRC people highlight XMPP people then?

  91. Zash


  92. jonas’

    the XMPP clients won’t know they’re meant unless you decode at the bridge, which has the potential for errors

  93. homebeach

    Are there any other irc networks bridged to xmpp with public bridge besides ircnet?

  94. homebeach

    sorry i meant "besides"

  95. pulkomandy

    Ah yes, irc networks with a 9 letter limit where I can't use my nickname are a thing

  96. jonas’

    bitlbee does something like that, by the way, and it’s terribly annoying to be on the XMPP side of that

  97. Zash

    ... ircnet what?

  98. homebeach

    there used to be that public transport that you can use to join ircnet channels

  99. homebeach

    but is there such for quakenet for example

  100. pulkomandy

    That being said, xmpp has a xep for mentions, and the irg bridge could use that when it detects the corresponding irc nickname being used

  101. homebeach


  102. pulkomandy

    (it's 0372)

  103. Zash

    heh. I guess 🤷️

  104. rom1dep

    https://matrix-org.github.io/matrix-appservice-irc/latest/irc_operators.html seems to imply that their bridge has to go though all the hoops I described, in fact

  105. rom1dep

    > The IRC bridge provides each Matrix user with one IRC connection in order to bridge them "natively" into the IRC network, as so they can largely be treated as real users. Due to the 1:1 connection system, it is often useful that the IRCD network provides the bridge host with a more relaxed ILINE limit depending on the number of Matrix users they'd expect to use the bridge.

  106. Zash


  107. Zash

    Most efficient would be something that speaks the internal IRC clustering protocol on one side and XMPP s2s or component on the other.

  108. Zash

    But AIUI that would be tied to specific ircd implementations

  109. rom1dep

    maybe, but maybe not too much of an issue

  110. rom1dep

    one could probably elaborate a clean API for that

  111. rom1dep

    that then IRCds could implement

  112. Zash

    Like a component connection for IRCd

  113. rom1dep

    could be along the lines of `connect_external_user(ext_native_nick, room)` ; `sent_message_callback(room, user, message)`