Change m.power_levels for (also existing) portal rooms to allow PL50 to change history visibility and deny enabling encryption

[ara4n]

Salvaged from https://github.com/matrix-org/matrix-appservice-irc/issues/387:

Currently if you get ops on a portal room you still can't change room name, history visibility, or power levels in general. These all push users to creating plumbed rooms, and then suffering double bridging ugliness. We should just change the power levels of the existing rooms to be more generous (and fix up the existing ones).

[Mikaela]

What are more generous power levels? I think those actions need 100 and the issue with 100 is that it cannot be reversed (it requires PL100 user to demote themselves). I think the issue with being allowed to set PL with less rhan PL100 was that you can promote yourself or something, it was once discussed on #irc:matrix.org, but I am unsure as I am on mobile.

[Mikaela]

I repeated my question at Matrix some time ago:

https://github.com/matrix-org/matrix-appservice-irc/issues/408 was left open on does it want ops syncing to provide a higher power level or decrease m.power_levels or what how?

And Kegan replied:

something like that, either of them just to make it so they can do more than currently so people aren't tempted to try to provision we could lower the level needed for those actions (probably not power levels) or we could raise the amount that +o gives (but I think things like the name are 100 which obviously won't work since we can't demote them then) so probably lower the level which the bridge will have to do retrospectively

• https://matrix.to/#/!SudviOJlimDvrGdFCY:matrix.org/%2414950381881741813fdZnT:matrix.org

Looking at what I think to be current defaults...

{
  "events_default": 0,
  "invite": 0,
  "state_default": 50,
  "redact": 50,
  "ban": 50,
  "users_default": 0,
  "events": {
    "m.room.avatar": 50,
    "m.room.name": 50,
    "m.room.power_levels": 100,
    "m.room.canonical_alias": 50,
    "m.room.history_visibility": 100
  },

}

...I think the issue that drives people to try provisioning would be m.room.history_visibility which should be lowered from 100 to 50.

Possibly unrelated to this specific issue, I believe that the event m.encryption should need PL100 rather than 50 (comes from state_default?) also outside of the IRC bridge, but it's even more important with the IRC bridge as it stops working if encryption is enabled and that button button just is attractive especially to new users for some reason.

I also think I saw something about listing in room directory requiring PL 100, but as I cannot find it anywhere anymore or what the event name was, I think I am imagining it.

[locutis-of-borg-1999]

so if i get an op to give me 50 i could i could prolly make the room crypto

[locutis-of-borg-1999]

with services ops dont mind giving out ops as even if banned they can reclaim the chan and they see matrix users like any other client so if the whole matrix room gets disconnected because i set crypto it is no big deal to them

[Mikaela]

I changed the title so it's more clear browsing the issues what this issue is about and added label bug as I think it's not intented that encryption can be enabled in portal rooms making Matrix side messages not reach IRC at all.

[Mikaela]

I am labeling this as P1, because:

• I have understood that users are mostly never supposed to create plumbed rooms, but instead use ops syncing which they aren't doing thanks to this issue.

• I think @matrix-org has miscommunicated (or from my point of view not communicated at all) about plumbing rooms requiring there to be less than 100 users in the room in question.

  • I see people being unsure about this in several rooms and I would have imagined this change being mentioned at least to moderators/volunteers in #irc and #riot who would be there during the weekend to reply questions and calm worried users.

• 

[benrob0329]

(Continuing from dup issue) You can demote power level 100 if you are higher than 100, if the bridge was say, 1000 then it can demote admins.

Voiced users are given power level 1, and the ability to send messages raised to 1 currently.

[vinipsmaker]

I'm OP in an IRC channel where I have a mirrored room in Matrix room through #freenode_<irc_channel_name>:matrix.org.

The only thing I want to do is to change the Matrix room history visibility to public. That's my thoughts to this discussion. It might be one of the most commonly wanted things.

[TimePath]

I'm in the same scenario, have a portal room with To change the room's history visibility, you must be a Admin and would like to make it public

[eeeeeta]

Changing history visibility should also yell loudly on the IRC side, given that it effectively enables public logging (especially since, on Freenode, you're expected to notify people if that's going on in the channel topic). Otherwise, giving ops to someone and having them enable public logging as a result (with irc users not realising) sounds like an accident waiting to happen...

[Mikaela]

@eeeeeta #493

[ghost]

Is a mandatory topic fragment an idea?

In this scenario the visibility would be set by the bot, after being asked to do so via an interface. The bot would then give you an url for the public logs and tell you to add it to the topic, then confirm or re-request the visibility change.

Something should probably happen if the fragment is later removed from the topic.

[ghost]

An important consideration in this is that while the bot may not necessarily have permission to set the topic irc-side, it can at least look at it and (partially) refuse service is the mandatory part is not present.

[Mikaela]

Personally I often have issues keeping in TOPICLEN even without long Matrix-style URLs, so I don't think adjusting TOPIC to adjust visibility would be a good idea..

[ghost]

Nobody said anything about matrix-style urls. I was thinking matrix-static, possibly in combination with an url shortener.

[Half-Shot]

My 2c: I don't believe in trying to set topic on behalf of the person that made the change.

The person who made the change should be a OP who knows full well the consequences of not telling everyone what the history retention stance is. The bridge should not be trying to police channels.

[Mikaela]

Nobody said anything about matrix-style urls. I was thinking matrix-static, possibly in combination with an url shortener.

By Matrix style URLs I mean exactly Matrix Static, for example https://view.matrix.org/room/!SkDGrVdWeTZmsUcAbI:diasp.in/ while the maximum topic length is TOPICLEN=390 on this server (58/390) and as I said, I often have issuues staying within that even with URL shorteners and which URL shortener would be used? I don't think it could work and I have two other suggestions, but I am not confident that they would work either.

• A) ENTRYMSG, ChanServ or a bot sending a NOTICE with content [#bridgedchannel] This channel is bridged to Matrix with history visiblity X at LINK to everyone joining the channel where I think the issue is that ENTRYMSG length is limited and there may also be better usage for it. However with bots (opped bots?) this would be more universal solution. (Freenode/Atheme users, /msg chanserv help set guard, /msg chanserv help set entrymsg)

• B) Channel metadata. E.g. /msg ChanServ set #bridgedchannel property PublicLogs Allowed, /msg ChanServ taxonomy #bridgedchannel.

  • Now /msg chanserv taxonomy #bridgedchannel would return PublicLogs: Allowed.
  • I think the drawback here is that this again only works with Atheme IRC Services (and forks) that I am aware of and it's not the only IRC services package, so it wouldn't be very universal. However of the three suggestions, this is my favourite as it doesn't mess up with ways how I would run channels.

The person who made the change should be a OP who knows full well the consequences of not telling everyone what the history retention stance is. The bridge should not be trying to police channels.

I think this is the only working solution, but I think to turn it into a more complete solution, Matrix would need an audit log (Discord-style) which shows clearly who did what and when without digging around information too much, so if when there was a problem, all ops would be able to find out when it was caused and by whom.

[Half-Shot]

I think this is the only working solution, but I think to turn it into a more complete solution, Matrix would need an audit log (Discord-style) which shows clearly who did what and when without digging around information too much, so if when there was a problem, all ops would be able to find out when it was caused and by whom.

Totally agree, this is more of a Riot feature where we should be able to click to go to the event that did the change. Either way, I'm proposing to do this for now.

[Half-Shot]

619 imposes power levels on portal rooms. See https://github.com/Half-Shot/matrix-appservice-irc/blob/1bafe775f52bb3fdfd99eb36208117e6de0e8d71/lib/util/RoomUtils.js.

Please let me know if this seems sensible.

[Mikaela]

Are there any news on this or at least official instructions on how to explain to bridge administrator on how to grant PL100 to people requesting it?

We PirateIRC opers and Pirate Party activists have been having trouble communicating this to Diasp.in hosting the PirateIRC Matrix bridge and standing for transparency we would like to have our rooms publicly visible even without Matrix account, which this issue is currently blocking.

[emorrp1]

According to Kegsay on #387 it is an explicit non-goal to allow removal of a portal room in order to ensure it's possible to connect to any arbitrary IRC channel. The recommendation is to find a PL set that gets rid of the Mod's desire for plumbed rooms.

Therefore I'd like to add that as a channel OP, I want to enable Invite users for "Default" role and to make things easier, I don't see why (for practically public IRC rooms) this shouldn't be the bridge default. Another one I personally dislike but could see some people wanting is "Notify everyone", which I assume is be @room, some channels would expect that to be available to everyone. That covers the what I can see in Roles and Permissions not already mentioned above.