rom1dephas 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, …)
mathieuiare we talking about this? https://github.com/matrix-org/matrix-appservice-irc
rom1depdunno, 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
moparisthebestrom1dep: oh the thing freenode runs to let matrix folk join? They could already run biboumi instead
Zashrom1dep, what are you suggesting exactly?
ZashMatrix "appservices" are equivalent to external components in the XMPP world, they have a privileged connection to the server.
rom1depmoparisthebest: 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
mathieuirom1dep, it is slightly different
mathieuitheir appservice is creating a matrix room and updating state both ways
mathieuiyou can also create any room and link it later to an irc channel
mathieui(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.
mathieuiand afterwards it gives a link to the forbidden page on matrix.org which will make MattJ unhappy
moparisthebestrom1dep: what native XMPP muc features are you missing from biboumi
mathieuimoparisthebest, seeing other XMPP users as XMPP users
mathieuiand not through IRC
MattJmoparisthebest, 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
mathieuithough that is not how the matrix irc appservice works (in "portal mode", that is)
rom1depso, 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)
mathieuirom1dep, this appservice is not really helpful
moparisthebestOh, well I imagine that could be fixed fairly easily in biboumi
mathieuiI mean, I expect 95% of the code to be matrix-related
moparisthebestbiboumi has 99% of everything you want except avatars I guess
mathieuimoparisthebest, and possibly some heavy rewrites to not have split views of each rooms and handling of XMPP users in the same room
mathieui(but I have not looked at the code in ages)
rom1depmathieui: 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
mathieuiI don’t see how that’s different, they just take the display nick and add a [m] behind (that is configurable)
rom1depmoparisthebest: I think I remember louiz' saying it wasn't a design goal of biboumi and would not be trivial to do
rom1depmathieui: they have the component create nicks for as many users are joined from the matrix side, take care of chatlog historisation, etc
rom1depbiboumi can't deduplicate MAM for instance
moparisthebestBiboumi supports single server mode already though, so it's partially a design goal
rom1depmeans A joins ; A leaves ; B joins ; B leaves → A doesn't sees B backlog, B doesn't see A backlog
rom1depand when A and B are joined together, biboumi happily logs twice the same stuff
moparisthebestMy point is I think making that work for XMPP is doing 99999x more work than any changes you might want to make to biboumi
rom1depbut why, though?
moparisthebestYou could make biboumi not do that, for instance
mathieui19: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
rom1dephowever crappy and specific this component might be, at least 50% of it does the job
moparisthebestAnd biboumi does 97% of the job
rom1depit doesn't, it addresses a different problem
moparisthebestAnd the matrix bridge doesn't? :)
lovetoxhey, again issue with 0050
lovetoxThe "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.
lovetoxlots of MUST in there but when it counts its vague
lovetoxThis attribute MUST be present for subsequent stages
lovetoxso 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?
ZashYeah. Single-step commands could probably get away with ignoring that attribute.
lovetoxnot sure if i can handle that easily
lovetoxwhole thing is iq based, why do we need a session anyway
ZashBasically a session cookie, so useful for maintaining state serverside.
ZashBut you could also serialize the state into a hidden field
flowlovetox, being IQ based is not enough, cause one ad-hoc command session may span over multiple IQ request-response pairs
rom1depmathieui: 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
rom1depmy 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
ZashI 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.
moparisthebestalso webirc things
rom1depZash: I thought that the bridge was running behind the ircd so that it would always be logging, deduplicating messages and so forth. If those
rom1depZash: I thought that the bridge was running behind the ircd so that it would always be logging, deduplicating messages and so forth.
ZashNeed network diagrams.
rom1depmy 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`
ZashIf you're managing a horde of simulacra then it's easy enough to have one extra for the bot itself which handles incoming messages.
jonas’rom1dep, this breaks down once the users have different privileges
pulkomandyIt 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?
rom1depjonas’: I'm sure of that
jonas’pulkomandy, for consistency, it’s easier if the source of truth is on the network with the "lower" capabilities
jonas’(in this case, IRC)
rom1deppulkomandy: yep, many existing communities are already on <insert IRC net here>
Zashpulkomandy, https://github.com/moparisthebest/xmpp-ircd might be doing that
Zashbut it'll get weird unless you enforce IRC limitations
pulkomandyDepends 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"
Zashwhich may or may not be desirable
pulkomandySeems the way to go to convince people to migrate
rom1depmy idea was that if matrix has it all figured-out, we can just hop on the bandwagon and use their bridge (or enhance it to make it behave as an XMPP room on top of being a matrix room)
rom1depmy 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)
pulkomandy(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")
homebeachAre there any other networks bridged to xmpp with public bridge except ircnet?
homebeachAre there any other irc networks bridged to xmpp with public bridge except ircnet?
jonas’pulkomandy, what do you do with XMPP nicknames which are not valid in IRC?
rom1dep(I, too, prefer biboumi's splitting the message across several smaller ones)
rom1dephomebeach: how does that work for ircnet?
pulkomandyI don't know, you punycode them?
jonas’pulkomandy, length limits, but also, how do IRC people highlight XMPP people then?
jonas’the XMPP clients won’t know they’re meant unless you decode at the bridge, which has the potential for errors
homebeachAre there any other irc networks bridged to xmpp with public bridge besides ircnet?
homebeachsorry i meant "besides"
pulkomandyAh yes, irc networks with a 9 letter limit where I can't use my nickname are a thing
jonas’bitlbee does something like that, by the way, and it’s terribly annoying to be on the XMPP side of that
Zash... ircnet what?
homebeachthere used to be that public transport that you can use to join ircnet channels
homebeachbut is there such for quakenet for example
pulkomandyThat being said, xmpp has a xep for mentions, and the irg bridge could use that when it detects the corresponding irc nickname being used
Zashheh. I guess 🤷️
rom1dephttps://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
rom1dep> 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.
ZashMost efficient would be something that speaks the internal IRC clustering protocol on one side and XMPP s2s or component on the other.
ZashBut AIUI that would be tied to specific ircd implementations
rom1depmaybe, but maybe not too much of an issue
rom1depone could probably elaborate a clean API for that
rom1depthat then IRCds could implement
ZashLike a component connection for IRCd
rom1depcould be along the lines of `connect_external_user(ext_native_nick, room)` ; `sent_message_callback(room, user, message)`