defanorWere 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).
KevThe whole XML thing is really debatable.
KevIf 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.
KevI 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.
defanorI 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).
contrapunctusAs 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?
jonas’it is certainly more well-scoped
jonas’but it has some issues on the IRC side, I think
jonas’as IRC isn't federated
contrapunctusjonas’: Hm...how does that affect a bridge? 🤔️
jonas’contrapunctus, how are IRC users going to interact with a bridge?
flowcontrapunctus, 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
jonas’flow, bots are not bridges!
jonas’they are terrible and we should stop praising them ;)
flowmaybe, but it works
contrapunctusflow: are users on both sides visible to the other side?
flowalthough yes, the main problem is that you don't know who is on the other side
flowbut I am not sure if you can solve that
flowmaybe on the XMPP side, but on the IRC side that would mean creating accounts on demand
flowand IRC networks haven often strong countermeasure against multiple accounts from the same IP✎
flowand IRC networks haven often strong countermeasures against multiple accounts from the same IP ✏
jonas’^ unless you happen to be an IRC server
jonas’hence, the point about federation
flowyeah, but you don't become an IRC server easily, at least in IRCNet, Libera and OFTC
jonas’also the channel namespace
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
contrapunctusOr...asking the IRC admins to permit multiple accounts from your XMPP server?
jonas’contrapunctus, where is the difference to the biboumi model then?
flowcontrapunctus, I doublt that any IRC operator would aggree to this
jonas’flow, you're wrong about that
flowbecause then their countermeasures could be circumvented by any xmpp server
jonas’I have allowlisting for my biboumi instance with at least ircnet
defanorIs it what Matrix is doing on Libera? There's a lot of users with [m] suffixes in their names.
jonas’flow, I had allowlisting with freenode, though they require you to run identd for bans
MattJThe Libera staff have consistently denied s2s-level access to their network for bridging purposes
MattJIRC 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
flowcontrapunctus, 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
jonas’MattJ, but matrix has an allowlisting for number of connections, which is what the question was about?
flowdon't get me wrong, it's not that I wouldn't welcome a proper IRC↔XMPP bridge
jonas’contrapunctus, so, which downsides do you see with the biboumi approach which you'd like to fix, and how?
flowand researching what matrix does seems like a good starting point
MattJjonas’, okay, I guess I skimmed the backlog too quickly, I was triggered by "you can easily become an IRC server"
jonas’MattJ, oh you can, by running your own single-server network ;)
jonas’(which is what I meant)
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
flowjonas’, biboumi is an XMPP component on the users XMPP service, right?
jonas’with the downsides of restricting everyone of the lowest common denominator of IRC (think usernames, rich messages etc.)
MattJMatrix 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
jonas’flow, on *some users XMPP service, yes
flowjonas’, then one advantage over the biboumi approach would be that you don't need such a component at all (irregardless where it runs)
jonas’flow, well, you need a component which does the bridging
contrapunctusjonas’: 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.✎
flowyou simply join the firstname.lastname@example.org and be in a room with people from #superchat @ libera
contrapunctusjonas’: 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. ✏
jonas’contrapunctus, so you just need to extend biboumi to broadcast the XMPP magic to all connected users instead of using the IRC reflection?✎
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? ✏
jonas’(for which there is an issue I think but it simply hasn't been implemented)
flowand the number of the entitys in the room would be the same when the bridged room is viewed from both networks
jonas’flow, you can have that today -- join #email@example.com ;). It's a MUC, but you can also join it from IRC ;)
flowjonas’, and that's the technical setup behind this?
flowso if I join that MUC, then an IRC user is connected simultaneously?
flowand vica versa for IRC users joining the channel?
flowI always thought of biboumi if a personal gateway
flowbut I've to admint, I never used it. but that could change
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.
flowjonas’, dou you know if this required any interaction with OFTC operators to setup up?
jonas’not if you have only have one or two XMPP-side users on your instance
jonas’if you have more, you'll probably want to talk to them to agree on a model which scales for ident purposes
jonas’my personal instance doesn't have many connections to OFTC, so I didn't bother
jonas’(I did bother for IRCnet though)
jonas’(where I just talked to one of the admins and got a something-line which granted me a higher limit)
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.
flowI see, very interesting, thanks!
jonas’contrapunctus, what is the difference?
jonas’the practical difference
jonas’it is a MUC on the XMPP side and a channel on the IRC side
jonas’(except for the broadcast of XMPP magic, which could "easily" be implemented in biboumi)
contrapunctusand this MUC exists independently of the IRC channel? e.g. what happens if the IRC server goes down, or the IRC channel is destroyed?
pep.> jonas’> (for which there is an issue I think but it simply hasn't been implemented)
I remember some backlash against that
jonas’contrapunctus, ah, then it's gone :)
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
jonas’that would also solve the XMPP magic broadcast, but comes with other challenges (mapping usernames between protocols, reserving usernames across protocols etc.)
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)
jonas’that would need cooperation from the MUC service in the other model
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
jonas’much of which is only partially standardized and cannot be dealt with in a generic way in a bridge
ZashBot bridge but multiple puppets?
contrapunctusI guess I'll start by implementing an MUC service as a learning project...it seems to be a common factor...
jonas’contrapunctus, that sounds like a reasonable way to learn XMPP
ZashOr some sort of FMUC/DMUC with IRC as one peer?
jonas’mmmm let biboumi instances speak f-muc with each other
jonas’why not xor 0b101?
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 :)
Zash^ is power to me
ZashHm, why did I not read that as 'starts with 5' when coming from the sed master?
KevFWIW, 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.
contrapunctusKev: I see...by "much harder to deal with", do you mean for users, administrators, or the gateway authors?
KevAnd it needs the IRC server to be amenable to that many connections from the XMPP server.
contrapunctusIs a gateway/transport just a particular kind of component?
KevThey are often implemented as components, although don't need to be.
Kev(And are the most common form of component)
ZashMaybe you could say that gateway/transport is a role, component is a method of connecting to a server
ZashA bot, connected as any other client, can have that role.
pulkomandyI 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)
Zashpulkomandy, don't mention that horror plz
pulkomandyUntil this happens, biboumi will do
KevIt 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.
ZashDealing with the differences between IRC and MUC is ... painful. Beware!
ZashYou'd probably have to enforce all IRC restrictions on MUC for it to work.
KevI actually think XMPP Server acting as an IRC server is the easiest of the models to make work sensibly.
ZashHaving been part of an attempt at this, that was not my experience.
pulkomandyIt depends how good you want the experience to be for the irc users, I guess
ZashI think you just end up writing an IRC server that happens to talk a restricted subset of XMPP
pulkomandyIf 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
pulkomandyIf a discussion is made mostly of long messages it gets v
annoying very quickly
Holger.oO( https://github.com/processone/ejabberd-contrib/tree/master/ircd doesn't seem to be super-actively maintained these days ... )
KevZash: Interesting. I thought IRCv3 would cover quite a lot of things to make it not horrible.
ZashKev: Mmmm maybe IRCv3 makes it acceptable. Who knows?
nepheleMatrixes 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....