jdev - 2021-05-27

has anyone had a look at the component that matrix developed for bridging with IRC servers? Is that something that could be enhanced to serve MUCs in addition to whatever's matrix? If IRC Networks have already bitten the bullet and are running that on their servers, wouldn't that be the easiest and nicest way to bridge with IRC, while simultaneously having the typical MUC features between XMPPers? (MAM, receipts, avatars, …)

Link?

are we talking about this? https://github.com/matrix-org/matrix-appservice-irc

dunno, maybe? I'm assuming that whatever they do requires server-side support, and if it's the new normal for the freenodes/libera.chat and others to run that service, then why the hell not benefit from it if we can PR our way into it

rom1dep: oh the thing freenode runs to let matrix folk join? They could already run biboumi instead

rom1dep, what are you suggesting exactly?

Matrix "appservices" are equivalent to external components in the XMPP world, they have a privileged connection to the server.

moparisthebest: you think? Isn't their bridge letting users on matrix side see each others as matrix clients/the irc room as a native matrix room? I don't see how biboumi alone would emulate that

rom1dep, it is slightly different

their appservice is creating a matrix room and updating state both ways

you can also create any room and link it later to an irc channel

(which is not what happens on the networks)

A Matrix room can be connected to a IRC network in one of two ways: A portal room, which is a Matrix room created by the bridge on demand when a Matrix user attempts to join an alias that does not yet exist. E.g. #freenode_#myproject:matrix.org. The bridge will hold power over this room and grant moderator status (half-power) to any IRC operators or Matrix users with IRC ops in the room. A plumbed room (also known as provisioning). A Matrix user may create a room ahead of time for their community and later on decide to "plumb in" IRC users to that room. They can do this via an interative UI in Element, via the !plumb command or even via a HTTP endpoint. If done interatively, the bridge has a verification process to ensure the user on the Matrix side has the blessing of the IRC ops first. However, it's possible for the IRC bot to lack kick abilities in the room so kicks and bans may not be bridged both ways.

and afterwards it gives a link to the forbidden page on matrix.org which will make MattJ unhappy

rom1dep: what native XMPP muc features are you missing from biboumi

moparisthebest, seeing other XMPP users as XMPP users

and not through IRC

moparisthebest, the situation is that two people joined to a "MUC" that is really an IRC channel won't see typing notifications, avatars, etc. of other XMPP users

though that is not how the matrix irc appservice works (in "portal mode", that is)

so, we could hook onto this appservice, let it handle the IRC side of the sync, and translate the other side to a MUC, that way we don't have to reinvent a new biboumi nor to fore the hand of the IRC networks to add yet another gateway (they'd just update their existing matrix bridge)

lemme backlog

rom1dep, this appservice is not really helpful

Oh, well I imagine that could be fixed fairly easily in biboumi

I mean, I expect 95% of the code to be matrix-related

biboumi has 99% of everything you want except avatars I guess

moparisthebest, and possibly some heavy rewrites to not have split views of each rooms and handling of XMPP users in the same room

(but I have not looked at the code in ages)

mathieui: I think there is a ton that goes on though, like users joining from matrix being given a IRC nick and such. Not having to reinvent such things could be good

I don’t see how that’s different, they just take the display nick and add a [m] behind (that is configurable)

moparisthebest: I think I remember louiz' saying it wasn't a design goal of biboumi and would not be trivial to do

mathieui: they have the component create nicks for as many users are joined from the matrix side, take care of chatlog historisation, etc

biboumi can't deduplicate MAM for instance

Biboumi supports single server mode already though, so it's partially a design goal

Who really wants avatars anyway... :)

means A joins ; A leaves ; B joins ; B leaves → A doesn't sees B backlog, B doesn't see A backlog

and when A and B are joined together, biboumi happily logs twice the same stuff

My point is I think making that work for XMPP is doing 99999x more work than any changes you might want to make to biboumi

but why, though?

You could make biboumi not do that, for instance

19:02:45 rom1dep> and when A and B are joined together, biboumi happily logs twice the same stuff → well that’s easy to know why, it is because that way you don’t have to handle any kind of privileges or state tracking linked to history

much easier

however crappy and specific this component might be, at least 50% of it does the job

And biboumi does 97% of the job

it doesn't, it addresses a different problem

bbl

And the matrix bridge doesn't? :)

hey, again issue with 0050

The "sessionid" attribute helps to track a command execution across multiple stages. This attribute MUST be present for subsequent stages, and the responder SHOULD initialize (if not provided) or maintain this attribute. The value of this attribute MUST NOT be empty or null, but otherwise can be any string value. This value MUST be maintained by a requester while executing a command.

lots of MUST in there but when it counts its vague

This attribute MUST be present for subsequent stages

so does this mean if there is no stage, means i execute a command, and the server responds with "completed" there needs to be no sessionid?

Yeah. Single-step commands could probably get away with ignoring that attribute.

..

not sure if i can handle that easily

whole thing is iq based, why do we need a session anyway

Indeed.

Basically a session cookie, so useful for maintaining state serverside.

But you could also serialize the state into a hidden field

lovetox, being IQ based is not enough, cause one ad-hoc command session may span over multiple IQ request-response pairs

mathieui: from the 2 definitions that you posted ("plumbed" or "portal"), I'm still not sure to understand how they work, and whether the IRC networks that currently bridge with matrix have to run any component on their side to make that possible

my assumption was that they do, and if that's the case, then the opportunity to make large IRC networks "XMPP Native" is enormous. If not, then forget about it

I imagined IRC networks mostly have to disable some rate limits and such, so that bridges can create as many users as they need to, from some small set of IP addresses.

also webirc things

Zash: I thought that the bridge was running behind the ircd so that it would always be logging, deduplicating messages and so forth. ✏

Need network diagrams.

my understanding is that for this kind of bridge to work reliably (one pretending to be a matrix room for all matrix users), only one of the connected IRC accounts needs to serve as proxy on behalf of all others, otherwise, when IRCUSER1 sends a "helloworld" message, the bridge sees "helloworld" × number of bridged users reaching it at subtely different timestamps. when this user leaves, another one needs to be rotated in and take over (probably with rules such that enough of the other dummies should have seen the first user leaving so the whole thing is netsplit/timeout resilient) none of that is required if it's the server to send the bridge `"IRCUSER1 sent "helloworld" to #room`

If you're managing a horde of simulacra then it's easy enough to have one extra for the bot itself which handles incoming messages.

rom1dep, this breaks down once the users have different privileges

It seems easier to just host the room on xmpp and have something to allow irc user to connect to it directly (not going through an existing irc server). I don't see what you need the irc server for here and it makes everything more complicated?

jonas’: I'm sure of that

pulkomandy, for consistency, it’s easier if the source of truth is on the network with the "lower" capabilities

(in this case, IRC)

jonas’, areyousure?

pulkomandy: yep, many existing communities are already on <insert IRC net here>

pulkomandy, https://github.com/moparisthebest/xmpp-ircd might be doing that

but it'll get weird unless you enforce IRC limitations

Depends what your goals are. I'd be fine with "xmpp users get all the cool features, grumpy people who really want to stick to irc get a limited view on things"

which may or may not be desirable

Seems the way to go to convince people to migrate

my idea was that if matrix has it all figured-out, we can just hop on the bandwagon and use their bridge (or more precisely, enhance it to make it behave as an XMPP room on top of being a matrix room) ✏

(I'm saying that but I'm annoyed when Matrix bridging to irc says "user x posted a long message, follow this https link to view it")

Are there any other irc networks bridged to xmpp with public bridge except ircnet? ✏

pulkomandy, what do you do with XMPP nicknames which are not valid in IRC?

(I, too, prefer biboumi's splitting the message across several smaller ones)

homebeach: how does that work for ircnet?

I don't know, you punycode them?

pulkomandy, length limits, but also, how do IRC people highlight XMPP people then?

PULKOM~1

the XMPP clients won’t know they’re meant unless you decode at the bridge, which has the potential for errors

Are there any other irc networks bridged to xmpp with public bridge besides ircnet? ✏

sorry i meant "besides"

Ah yes, irc networks with a 9 letter limit where I can't use my nickname are a thing

bitlbee does something like that, by the way, and it’s terribly annoying to be on the XMPP side of that

... ircnet what?

there used to be that public transport that you can use to join ircnet channels

but is there such for quakenet for example

That being said, xmpp has a xep for mentions, and the irg bridge could use that when it detects the corresponding irc nickname being used

?

(it's 0372)

heh. I guess 🤷️

https://matrix-org.github.io/matrix-appservice-irc/latest/irc_operators.html seems to imply that their bridge has to go though all the hoops I described, in fact

> The IRC bridge provides each Matrix user with one IRC connection in order to bridge them "natively" into the IRC network, as so they can largely be treated as real users. Due to the 1:1 connection system, it is often useful that the IRCD network provides the bridge host with a more relaxed ILINE limit depending on the number of Matrix users they'd expect to use the bridge.

Eyup.

Most efficient would be something that speaks the internal IRC clustering protocol on one side and XMPP s2s or component on the other.

But AIUI that would be tied to specific ircd implementations

maybe, but maybe not too much of an issue

one could probably elaborate a clean API for that

that then IRCds could implement

Like a component connection for IRCd

could be along the lines of `connect_external_user(ext_native_nick, room)` ; `sent_message_callback(room, user, message)`