Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ara4n opened this issue Mar 29, 2017 · 19 comments

Comments

@ara4n
Copy link
Member

commented Mar 29, 2017

Salvaged from #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

This comment has been minimized.

Copy link

commented Mar 29, 2017

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.

@Kegsay Kegsay added the feature-req label Apr 5, 2017

@Mikaela

This comment has been minimized.

Copy link

commented May 19, 2017

I repeated my question at Matrix some time ago:

#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

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

This comment has been minimized.

Copy link

commented May 26, 2017

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

@locutis-of-borg-1999

This comment has been minimized.

Copy link

commented May 26, 2017

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 Mikaela added the improvement label Aug 23, 2017

@Mikaela Mikaela changed the title Change default power levels for portal rooms Change m.power_levels for (also existing) portal rooms to allow PL50 to change history visibility and deny enabling encryption Aug 23, 2017

@Mikaela Mikaela added the bug label Aug 23, 2017

@Mikaela

This comment has been minimized.

Copy link

commented Aug 23, 2017

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

This comment has been minimized.

Copy link

commented Sep 2, 2017

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.
  • image going around Matrix

@benrob0329

This comment has been minimized.

Copy link

commented Dec 20, 2017

(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

This comment has been minimized.

Copy link

commented Feb 27, 2018

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

This comment has been minimized.

Copy link

commented Apr 10, 2018

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

This comment has been minimized.

Copy link

commented Jul 13, 2018

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

This comment has been minimized.

Copy link

commented Jul 13, 2018

@Matrixcoffee

This comment has been minimized.

Copy link

commented Jul 17, 2018

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.

@Matrixcoffee

This comment has been minimized.

Copy link

commented Jul 17, 2018

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

This comment has been minimized.

Copy link

commented Jul 17, 2018

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

@Matrixcoffee

This comment has been minimized.

Copy link

commented Jul 18, 2018

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

@Half-Shot

This comment has been minimized.

Copy link
Collaborator

commented Jul 18, 2018

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

This comment has been minimized.

Copy link

commented Jul 18, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 18, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 18, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.