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).
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
flowhas joined
Martinhas left
Martinhas joined
alhas left
atomicwatchhas left
atomicwatchhas joined
antranigvhas left
antranigvhas joined
COM8has joined
COM8has left
COM8has joined
COM8has left
antranigvhas left
sonnyhas left
sonnyhas joined
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?
sonnyhas left
sonnyhas joined
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
rafasaurushas left
contrapunctus
jonas’: Hm...how does that affect a bridge? 🤔️
goffihas left
rafasaurushas joined
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)
inkyhas joined
goffihas joined
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
flowthinks
flow
so if I join that MUC, then an IRC user is connected simultaneously?
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)
marc0shas left
marc0shas joined
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.)
tozhas joined
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
inkyhas left
debaclehas joined
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...
antranigvhas joined
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?
moparisthebesthas joined
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?
antranigvhas left
antranigvhas joined
tozhas left
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.
debaclehas left
moparisthebesthas left
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.
sonnyhas left
sonnyhas joined
machas joined
moparisthebesthas joined
edhelashas left
edhelashas joined
nephelehas joined
inkyhas joined
sonnyhas left
sonnyhas joined
kikuchiyohas left
marc0shas left
marc0shas joined
machas left
machas joined
kikuchiyohas joined
antranigvhas left
antranigvhas joined
inkyhas left
antranigvhas left
jgarthas left
Zashhas left
Zashhas joined
antranigvhas joined
rafasaurushas left
antranigvhas left
rafasaurushas joined
jgarthas joined
machas left
machas joined
inkyhas joined
Ingolfhas left
Ingolfhas joined
me9has joined
contrapunctus
Is a gateway/transport just a particular kind of component?
antranigvhas joined
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.
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)
machas left
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?
kikuchiyohas left
kikuchiyohas joined
pulkomandyhas left
pulkomandyhas joined
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....