jdev - 2021-12-17

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).

The whole XML thing is really debatable.

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.

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.

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).

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?

it is certainly more well-scoped

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

as IRC isn't federated

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

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

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

flow, bots are not bridges!

they are terrible and we should stop praising them ;)

maybe, but it works

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

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

but I am not sure if you can solve that

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

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

^ unless you happen to be an IRC server

hence, the point about federation

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

also the channel namespace

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

(mod_irc?!)

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

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

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

flow, you're wrong about that

because then their countermeasures could be circumvented by any xmpp server

I have allowlisting for my biboumi instance with at least ircnet

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

^

No

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

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

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

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

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

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

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

and researching what matrix does seems like a good starting point

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

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

(which is what I meant)

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

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

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

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

flow, on *some users XMPP service, yes

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

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

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

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. ✏

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

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

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

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 ;)

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

biboumi is

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

yes

ahh I wasn't aware that this wroks ✏

ahh I wasn't aware that this works ✏

that's just how biboumi works ;)

and vica versa for IRC users joining the channel?

yep

I always thought of biboumi if a personal gateway

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

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.

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

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

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

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

(I did bother for IRCnet though)

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

> 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.

I see, very interesting, thanks!

contrapunctus, what is the difference?

the practical difference

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

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

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?

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

contrapunctus, ah, then it's gone :)

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

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

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)

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

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

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

Bot bridge but multiple puppets?

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

contrapunctus, that sounds like a reasonable way to learn XMPP

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

mmmm let biboumi instances speak f-muc with each other

^5 Zash

**5

why not xor 0b101?

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 :)

^ is power to me

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

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.

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

Gateway authors.

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

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

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

(And are the most common form of component)

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

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

You can also do it with s2s connections

Or as an internal plugin in the server ✏

Makes sense, thanks.

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)

pulkomandy, don't mention that horror plz

Until this happens, biboumi will do

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.

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

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

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

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

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

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

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

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

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

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

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

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....