jdev - 2021-12-17

  1. defanor

    Were there attempts to write down a collective wish list for a reusable library's properties (except for compliance)? I'm working on one too, and trying to make it reusable, but I have a lingering suspicion that it may miss properties important to others. The main properties I've picked are an asynchronous C API and letting a program to work with XML directly (including hooks for sending/receiving, optionally telling the library to not send/process those).

  2. Kev

    The whole XML thing is really debatable.

  3. Kev

    If you have an abstraction in the library, users don't have to know how XMPP is represented on the wire, only the semantics - clearly good. OTOH, abstracting away the XML makes it that little bit harder to deal with the XML when you want to do something not yet supported by the library.

  4. Kev

    I don't think either is clearly better (although an abstraction without a way to add your own payloads is clearly a problem), they both have drawbacks.

  5. defanor

    I figured that XML (and flexibility in general) is important for reusability, while convenience functions abstracting it can be sprinkled on top later (though already doing that for some of the more cumbersome to compose bits).

  6. contrapunctus

    As it happens, I've never done any XMPP-related development before. Apart from the client library, the other project I was interested in was an XMPP-IRC bridge (which, unlike Biboumi, connects an MUC with an IRC room and lets users participate in the same conversation from either protocol)...would that be a suitable project to gain XMPP development experience?

  7. jonas’

    it is certainly more well-scoped

  8. jonas’

    but it has some issues on the IRC side, I think

  9. jonas’

    as IRC isn't federated

  10. contrapunctus

    jonas’: Hm...how does that affect a bridge? 🤔️

  11. jonas’

    contrapunctus, how are IRC users going to interact with a bridge?

  12. flow

    contrapunctus, such XMPP-IRC MUC↔IRC-Channel bridges already exist, we use one. It's basically a bot that joins both rooms and forwards the messages

  13. jonas’

    flow, bots are not bridges!

  14. jonas’

    they are terrible and we should stop praising them ;)

  15. flow

    maybe, but it works

  16. contrapunctus

    flow: are users on both sides visible to the other side?

  17. flow

    although yes, the main problem is that you don't know who is on the other side

  18. flow

    but I am not sure if you can solve that

  19. flow

    maybe on the XMPP side, but on the IRC side that would mean creating accounts on demand

  20. flow

    and IRC networks haven often strong countermeasure against multiple accounts from the same IP

  21. flow

    and IRC networks haven often strong countermeasures against multiple accounts from the same IP

  22. jonas’

    ^ unless you happen to be an IRC server

  23. jonas’

    hence, the point about federation

  24. flow

    yeah, but you don't become an IRC server easily, at least in IRCNet, Libera and OFTC

  25. jonas’

    also the channel namespace

  26. jonas’

    flow, you can easily become an IRC server -- by being one. but that then means that IRC users have to log into your single-server network

  27. jonas’


  28. contrapunctus

    Or...asking the IRC admins to permit multiple accounts from your XMPP server?

  29. jonas’

    contrapunctus, where is the difference to the biboumi model then?

  30. flow

    contrapunctus, I doublt that any IRC operator would aggree to this

  31. jonas’

    flow, you're wrong about that

  32. flow

    because then their countermeasures could be circumvented by any xmpp server

  33. jonas’

    I have allowlisting for my biboumi instance with at least ircnet

  34. defanor

    Is it what Matrix is doing on Libera? There's a lot of users with [m] suffixes in their names.

  35. contrapunctus


  36. MattJ


  37. jonas’

    flow, I had allowlisting with freenode, though they require you to run identd for bans

  38. MattJ

    The Libera staff have consistently denied s2s-level access to their network for bridging purposes

  39. MattJ

    IRC s2s is not like XMPP s2s, each server has significant power over the network, and they don't want third-party code with that power

  40. flow

    contrapunctus, in any case, you want to reach out to IRC operators and clarify what, if anything, and how they would allow multiple connections before starting to code

  41. jonas’

    MattJ, but matrix has an allowlisting for number of connections, which is what the question was about?

  42. flow

    don't get me wrong, it's not that I wouldn't welcome a proper IRC↔XMPP bridge

  43. jonas’

    contrapunctus, so, which downsides do you see with the biboumi approach which you'd like to fix, and how?

  44. flow

    and researching what matrix does seems like a good starting point

  45. MattJ

    jonas’, okay, I guess I skimmed the backlog too quickly, I was triggered by "you can easily become an IRC server"

  46. jonas’

    MattJ, oh you can, by running your own single-server network ;)

  47. jonas’

    (which is what I meant)

  48. jonas’

    so a thing which exposes an IRC c2s interface on the one side (mimicing a single-node network) and an XMPP component interface implementing MUC on the other side would work

  49. flow

    jonas’, biboumi is an XMPP component on the users XMPP service, right?

  50. jonas’

    with the downsides of restricting everyone of the lowest common denominator of IRC (think usernames, rich messages etc.)

  51. MattJ

    Matrix is just allowed to have many connections. They give each connected user a unique IPv6 address in an agreed block, and have an agreed ident string

  52. jonas’

    flow, on *some users XMPP service, yes

  53. flow

    jonas’, then one advantage over the biboumi approach would be that you don't need such a component at all (irregardless where it runs)

  54. jonas’

    flow, well, you need a component which does the bridging

  55. contrapunctus

    jonas’: In the Biboumi approach, communities are divided rather than connected. I want to bridge some MUCs to some IRC channels, have users on both sides see each other, and users on the XMPP side see each others' status, avatars, typing notifications, read markers etc.

  56. flow

    you simply join the superchat@chat.example.org and be in a room with people from #superchat @ libera

  57. contrapunctus

    jonas’: In the Biboumi approach, communities stay divided rather than being connected. I want to bridge some MUCs to some IRC channels, have users on both sides see each other, and users on the XMPP side see each others' status, avatars, typing notifications, read markers etc.

  58. jonas’

    contrapunctus, so you just need to extend biboumi to broadcast the XMPP magic to all connected users instead of using the IRC reflection?

  59. jonas’

    contrapunctus, so you just need to extend biboumi to broadcast the XMPP magic to all connected XMPP users instead of using the IRC reflection?

  60. jonas’

    (for which there is an issue I think but it simply hasn't been implemented)

  61. flow

    and the number of the entitys in the room would be the same when the bridged room is viewed from both networks

  62. jonas’

    flow, you can have that today -- join #yaook%irc.oftc.net@irc.jabberfr.org ;). It's a MUC, but you can also join it from IRC ;)

  63. flow

    jonas’, and that's the technical setup behind this?

  64. jonas’

    biboumi is

  65. flow thinks

  66. flow

    so if I join that MUC, then an IRC user is connected simultaneously?

  67. jonas’


  68. flow

    ahh I wasn't aware that this wroks

  69. flow

    ahh I wasn't aware that this wroks

  70. flow

    ahh I wasn't aware that this works

  71. jonas’

    that's just how biboumi works ;)

  72. flow

    and vica versa for IRC users joining the channel?

  73. jonas’


  74. flow

    I always thought of biboumi if a personal gateway

  75. flow

    but I've to admint, I never used it. but that could change

  76. jonas’

    the only difference between that and a normal MUC is that XMPP specific protocols are mostly discarded (avatars, typing notifications etc.) and that biboumi will split overlong messages.

  77. flow

    jonas’, dou you know if this required any interaction with OFTC operators to setup up?

  78. jonas’

    not if you have only have one or two XMPP-side users on your instance

  79. jonas’

    if you have more, you'll probably want to talk to them to agree on a model which scales for ident purposes

  80. jonas’

    my personal instance doesn't have many connections to OFTC, so I didn't bother

  81. jonas’

    (I did bother for IRCnet though)

  82. jonas’

    (where I just talked to one of the admins and got a something-line which granted me a higher limit)

  83. contrapunctus

    > contrapunctus, so you just need to extend biboumi to broadcast the XMPP magic to all connected XMPP users instead of using the IRC reflection? jonas’: wouldn't that mean all XMPP users are joining the IRC room, rather than my description of "bridging an MUC and an IRC room"? The benefit of the latter is, people can jump ship from IRC to XMPP without losing their community.

  84. flow

    I see, very interesting, thanks!

  85. jonas’

    contrapunctus, what is the difference?

  86. jonas’

    the practical difference

  87. jonas’

    it is a MUC on the XMPP side and a channel on the IRC side

  88. jonas’

    (except for the broadcast of XMPP magic, which could "easily" be implemented in biboumi)

  89. contrapunctus

    and this MUC exists independently of the IRC channel? e.g. what happens if the IRC server goes down, or the IRC channel is destroyed?

  90. pep.

    > jonas’> (for which there is an issue I think but it simply hasn't been implemented) I remember some backlash against that

  91. jonas’

    contrapunctus, ah, then it's gone :)

  92. jonas’

    contrapunctus, if you want to avoid that, then yeah, the model needs to change so that the bridge component uses an existing MUC service (which it could and maybe should implement/provide on its own, but doesn't have to) instead of implementing MUC

  93. jonas’

    that would also solve the XMPP magic broadcast, but comes with other challenges (mapping usernames between protocols, reserving usernames across protocols etc.)

  94. jonas’

    the advantage of the biboumi model in that regardis that the "primary" copy of the room lives on the protocol with the lower amount of features, i.e. biboumi can enforce, on the high-feature side, that clients don't make use of those features (spaces in nicknames)

  95. jonas’

    that would need cooperation from the MUC service in the other model

  96. jonas’

    the biboumi model also means that users can more directly interact with IRC, e.g. to place bans, run IRC-specific commands or to authenticate with NickServ

  97. jonas’

    much of which is only partially standardized and cannot be dealt with in a generic way in a bridge

  98. Zash

    Bot bridge but multiple puppets?

  99. contrapunctus

    I guess I'll start by implementing an MUC service as a learning project...it seems to be a common factor...

  100. jonas’

    contrapunctus, that sounds like a reasonable way to learn XMPP

  101. Zash

    Or some sort of FMUC/DMUC with IRC as one peer?

  102. jonas’

    mmmm let biboumi instances speak f-muc with each other

  103. jonas’

    ^5 Zash

  104. Zash


  105. jonas’

    why not xor 0b101?

  106. jonas’

    contrapunctus, another bit to think about: if the IRC server goes down, what to do with XMPP messages sent in the meantime? lost to IRC users? probably ok, they're used to netsplits :)

  107. Zash

    ^ is power to me

  108. Zash

    Hm, why did I not read that as 'starts with 5' when coming from the sed master?

  109. Kev

    FWIW, the M-Link IRC gateway works by bridging a MUC and an IRC channel, so anyone in either sees anyone in the other. It's much harder to deal with than a traditional 'join an IRC channel that looks like a MUC' gateway.

  110. contrapunctus

    Kev: I see...by "much harder to deal with", do you mean for users, administrators, or the gateway authors?

  111. Kev

    Gateway authors.

  112. Kev

    And it needs the IRC server to be amenable to that many connections from the XMPP server.

  113. contrapunctus

    Is a gateway/transport just a particular kind of component?

  114. Kev

    They are often implemented as components, although don't need to be.

  115. Kev

    (And are the most common form of component)

  116. Zash

    Maybe you could say that gateway/transport is a role, component is a method of connecting to a server

  117. Zash

    A bot, connected as any other client, can have that role.

  118. Zash

    You can also do it with s2s connections

  119. Zash

    Or as an internal plugin in the sersver

  120. Zash

    Or as an internal plugin in the server

  121. contrapunctus

    Makes sense, thanks.

  122. pulkomandy

    I think the mod_irc way makes sense (muc hosted on xmpp and happens to also be exported as a non-federated irc server). irc is already so fragmented that irc users won't mind joining yet another irc network (that just happens to in fact be the xmpp network)

  123. Zash

    pulkomandy, don't mention that horror plz

  124. pulkomandy

    Until this happens, biboumi will do

  125. Kev

    It depends heavily on the reason people want an IRC bridge. There are (non-theoretical) situations where that model would make sense. There are also situations where it doesn't work at all.

  126. Zash

    Dealing with the differences between IRC and MUC is ... painful. Beware!

  127. Zash

    You'd probably have to enforce all IRC restrictions on MUC for it to work.

  128. Kev

    I actually think XMPP Server acting as an IRC server is the easiest of the models to make work sensibly.

  129. Zash

    Having been part of an attempt at this, that was not my experience.

  130. pulkomandy

    It depends how good you want the experience to be for the irc users, I guess

  131. Zash

    I think you just end up writing an IRC server that happens to talk a restricted subset of XMPP

  132. pulkomandy

    If you look at how Matrix does it (even when they just bridge their users to an existing irc): long messages get transformed to a link to their http server, that irc users need to click

  133. pulkomandy

    If a discussion is made mostly of long messages it gets v annoying very quickly

  134. Holger

    .oO( https://github.com/processone/ejabberd-contrib/tree/master/ircd doesn't seem to be super-actively maintained these days ... )

  135. Kev

    Zash: Interesting. I thought IRCv3 would cover quite a lot of things to make it not horrible.

  136. Zash

    Kev: Mmmm maybe IRCv3 makes it acceptable. Who knows?

  137. nephele

    Matrixes bridge is nice for other reasons too, they transform messages with irc nicknames in them to the matrix equivalent nicknames... so if you were to pick a common noun on the irc side....