-
Notifications
You must be signed in to change notification settings - Fork 152
Permissioning in Portal vs Plumbed rooms
Both of these cases apply to Matrix rooms that are "bridged" to IRC channels.
Currently, there are rooms seen on Matrix, that often have only a single alias, local to the Homeserver where the IRC bridge resides, which is prepended by the name of the IRC network:
i.e. #freenode_#channel:matrix.org.
Many of these rooms appear in the Matrix directory automatically. A user may join any channel on a bridged IRC network, that their Matrix client is able to join, or create, via such an alias. These rooms are treated as what are called "Portal" rooms. They provide a portal for Matrix users to join IRC channels, as if they were a regular IRC user, on a traditional IRC client.
One way to look at a Portal room, is from a typical use case of a IRC-crossover user, who just uses them as they would use any other IRC client. Except that how Matrix & IRC bridging works, it includes the functionality of an IRC "Bouncer" (BNC/ZNC, et cetera), which is always connected. And, there is no need to keep logs, as Matrix keeps room content, server-side. Many might not be aware of the advanced features of Matrix, especially on the IRC side, through the Portal.
The Matrix users initially have no special status in a Matrix IRC Portal room or the bridged IRC channel, unless given by IRC channel Operators. And, there may be other factors limiting who may join, such as needing an IRC "key", or invitation. In these rooms, the balance of power very much resides on the IRC channel, and the Matrix side purposefully doesn't try to intrude too much into that.
Formerly, the only way to get operator privileges on the Matrix-side for this kind of room was to ask the bridge operator. For IRC networks bridged via matrix.org the place to ask would be: (e.g. #irc:matrix.org. However, for bridged IRC Networks where "Op's Sync'ing" is enabled, anyone who gets Chan'Op' status (+o) in the bridged IRC channel becomes a PL-50 Moderator in the Matrix room.
Rooms that are created by a native Matrix user, grant the admin power to that user's MXID. When this admin or another with sufficient power level subsequently gets permission to make the room bridged or "piped" into IRC, they are called "Plumbed" rooms. A channel operator on the IRC side must give permission for the room to be "Plumbed".
Other Matrix users can join, by alias, what appears to be just like any other contemporary Matrix room. But, it is also bridged to IRC.
In this model, the balance of power formerly very much resided on Matrix side (some think it has to, as different networks have different ideas of "permissions" and only Matrix can serve as the mediator between them). The moderators of the room once were only Matrix users, and they can control guest access, where to plumb the room into, etc.
Formerly, the only way to get elevated privileges on the Matrix-side for this kind of room was to ask the existing Matrix Admin's or Mod's in the room. Now, where "Op's Sync'ing" is enabled, anyone who is made an "Op' " (+o) in the bridged IRC channel automatically becomes a PL-50 Moderator in the Matrix room. This is not reciprocal, whereas Matrix Admin's and Mod's are supplicants for the ability to unilaterally moderate, if they do not already have full control on IRC.
This Op's Sync'ing should give Matrix Admin's & Mod's pause before bridging, a.k.a. "linking". If moderation does not occur in a bridged IRC room, such as when abuses intrude into Matrix, this does not bode well for a community. Also, a rogue channel Op' on IRC could just kick and ban Matrix users on a whim, even for having an irc "nick' " with [m]. And some IRCd implementations have a mass-kick or mass-ban function. One should consider carefully the potential consequences, when attempting to build a community on Matrix. It might be well advised to have control on the IRC side, before bridging an established community in a Matrix room, as a Plumbed Room.
There may be issue tracking that currently holds active discussion, regarding open issues, that is relevant to the content here. Op's Sync'ing for IRC Channel Operators has been heavily advocated. What is ultimately decided may have effect upon what is described in these pages. Currently, that seems to include:
Enable ops syncing on matrix.org networks #438
https://github.com/MilkManzJourDaddy/matrix-org/wiki/Before-Bridging-to-IRC
https://github.com/MilkManzJourDaddy/matrix-org/wiki/Glossary-of-Terms-in-Matrix#double-bridging