-
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).
-
Kev
The whole XML thing is really debatable.
-
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.
-
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.
-
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).
-
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?
-
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
-
contrapunctus
jonas’: Hm...how does that affect a bridge? 🤔️
-
jonas’
contrapunctus, how are IRC users going to interact with a bridge?
-
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
-
jonas’
flow, bots are not bridges!
-
jonas’
they are terrible and we should stop praising them ;)
-
flow
maybe, but it works
-
contrapunctus
flow: are users on both sides visible to the other side?
-
flow
although yes, the main problem is that you don't know who is on the other side
-
flow
but I am not sure if you can solve that
-
flow
maybe on the XMPP side, but on the IRC side that would mean creating accounts on demand
-
flow
and IRC networks haven often strong countermeasure against multiple accounts from the same IP✎ -
flow
and 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
-
flow
yeah, 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
-
jonas’
(mod_irc?!)
-
contrapunctus
Or...asking the IRC admins to permit multiple accounts from your XMPP server?
-
jonas’
contrapunctus, where is the difference to the biboumi model then?
-
flow
contrapunctus, I doublt that any IRC operator would aggree to this
-
jonas’
flow, you're wrong about that
-
flow
because then their countermeasures could be circumvented by any xmpp server
-
jonas’
I have allowlisting for my biboumi instance with at least ircnet
-
defanor
Is it what Matrix is doing on Libera? There's a lot of users with [m] suffixes in their names.
-
contrapunctus
^
-
MattJ
No
-
jonas’
flow, I had allowlisting with freenode, though they require you to run identd for bans
-
MattJ
The Libera staff have consistently denied s2s-level access to their network for bridging purposes
-
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
-
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
-
jonas’
MattJ, but matrix has an allowlisting for number of connections, which is what the question was about?
-
flow
don'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?
-
flow
and researching what matrix does seems like a good starting point
-
MattJ
jonas’, 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
-
flow
jonas’, 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.)
-
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
-
jonas’
flow, on *some users XMPP service, yes
-
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)
-
jonas’
flow, well, you need a component which does the bridging
-
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.✎ -
flow
you simply join the superchat@chat.example.org and be in a room with people from #superchat @ libera
-
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. ✏
-
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)
-
flow
and 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 #yaook%irc.oftc.net@irc.jabberfr.org ;). It's a MUC, but you can also join it from IRC ;)
-
flow
jonas’, and that's the technical setup behind this?
-
jonas’
biboumi is
- flow thinks
-
flow
so if I join that MUC, then an IRC user is connected simultaneously?
-
jonas’
yes
-
flow
ahh I wasn't aware that this wroks✎ -
flow
ahh I wasn't aware that this wroks ✏
-
flow
ahh I wasn't aware that this works ✏
-
jonas’
that's just how biboumi works ;)
-
flow
and vica versa for IRC users joining the channel?
-
jonas’
yep
-
flow
I always thought of biboumi if a personal gateway
-
flow
but 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.
-
flow
jonas’, 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.
-
flow
I 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)
-
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?
-
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
-
Zash
Bot bridge but multiple puppets?
-
contrapunctus
I 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
-
Zash
Or some sort of FMUC/DMUC with IRC as one peer?
-
jonas’
mmmm let biboumi instances speak f-muc with each other
-
jonas’
^5 Zash
-
Zash
**5
-
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
-
Zash
Hm, why did I not read that as 'starts with 5' when coming from the sed master?
-
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.
-
contrapunctus
Kev: I see...by "much harder to deal with", do you mean for users, administrators, or the gateway authors?
-
Kev
Gateway authors.
-
Kev
And it needs the IRC server to be amenable to that many connections from the XMPP server.
-
contrapunctus
Is a gateway/transport just a particular kind of component?
-
Kev
They are often implemented as components, although don't need to be.
-
Kev
(And are the most common form of component)
-
Zash
Maybe you could say that gateway/transport is a role, component is a method of connecting to a server
-
Zash
A bot, connected as any other client, can have that role.
-
Zash
You can also do it with s2s connections
-
Zash
Or as an internal plugin in the sersver✎ -
Zash
Or as an internal plugin in the server ✏
-
contrapunctus
Makes sense, thanks.
-
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)
-
Zash
pulkomandy, don't mention that horror plz
-
pulkomandy
Until this happens, biboumi will do
-
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.
-
Zash
Dealing with the differences between IRC and MUC is ... painful. Beware!
-
Zash
You'd probably have to enforce all IRC restrictions on MUC for it to work.
-
Kev
I actually think XMPP Server acting as an IRC server is the easiest of the models to make work sensibly.
-
Zash
Having been part of an attempt at this, that was not my experience.
-
pulkomandy
It depends how good you want the experience to be for the irc users, I guess
-
Zash
I think you just end up writing an IRC server that happens to talk a restricted subset of XMPP
-
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
-
pulkomandy
If 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 ... )
-
Kev
Zash: Interesting. I thought IRCv3 would cover quite a lot of things to make it not horrible.
-
Zash
Kev: Mmmm maybe IRCv3 makes it acceptable. Who knows?
-
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....