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

Mechanism for migrating portal rooms to plumbed rooms #387

Closed
ara4n opened this issue Mar 11, 2017 · 19 comments

Comments

Projects
None yet
5 participants
@ara4n
Copy link
Member

commented Mar 11, 2017

A typical flow for IRC bridging is that folks try it out via a portal, and then want to plumb it into an existing Matrix room. As there is no way to evict the previous portal, all hell breaks loose with doubly-bridged users everywhere.

We need some kind of mechanism to migrate the portal room into a plumbed room, either by supporting turning a portal room into a plumbed room (by giving users ops in the portal room), or by somehow providing a mechanism to evict portals.

@Mikaela

This comment has been minimized.

Copy link

commented Mar 11, 2017

Doesn't ops syncing fix this for most of the users?

@Kegsay

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2017

@Mikaela - I believe so. @ara4n ?

@ara4n

This comment has been minimized.

Copy link
Member Author

commented Mar 14, 2017

i'm not sure how getting ops in a portal room helps replace the portal with a plumb?

@Kegsay

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2017

We need some kind of mechanism to migrate the portal room into a plumbed room, either by supporting turning a portal room into a plumbed room (by giving users ops in the portal room)

Are we crossing wires here? It completely helps!

@ara4n

This comment has been minimized.

Copy link
Member Author

commented Mar 14, 2017

i'm failing to reason through the flow (even though i suggested it ;P). how does one de-portal a room if you have ops in it?

@Kegsay

This comment has been minimized.

Copy link
Contributor

commented Mar 15, 2017

Conceptually a portal room has the following properties:

  • no matrix admins
  • well known alias which indicates the channel it is bridged to (#freenode_...)

A plumbed room has the following properties:

  • At least 1 matrix admin
  • Bridged to 1 or more channels

ergo a portal room with a matrix admin is a subset of plumbed rooms.

@Kegsay

This comment has been minimized.

Copy link
Contributor

commented Mar 15, 2017

In other words, "how do you deportal a room if you have ops in it" is nonsensical.

@Kegsay

This comment has been minimized.

Copy link
Contributor

commented Mar 23, 2017

I don't believe there is any actionable item to do here.

@Kegsay Kegsay closed this Mar 23, 2017

@Matrixcoffee

This comment has been minimized.

Copy link

commented Mar 25, 2017

Not quite sure why this got closed. Let's not turn this into a definition war.

The actual problem is that when someone plumbs a room via "manage integrations", the old bridge-generated room is also left intact, so there are now two matrix rooms going to the same IRC room, with an ugly Matrix<->IRC<->Matrix bridge between them.

This is confusing to users. (Which room to join?)

@Kegsay

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2017

Not quite sure why this got closed

Because the issue is:

Mechanism for migrating portal rooms to plumbed rooms

to which the answer was:

Doesn't ops syncing fix this for most of the users?

You're asking a different question about how to handle multi-bridged rooms, which is not what this issue is about. Multi-bridging in and of itself is not a bug, but how it is currently being used (in order to get ops and set names/topics) is sub-optimal because of what you describe.

@ara4n

This comment has been minimized.

Copy link
Member Author

commented Mar 25, 2017

If you read my original comment this was entirely about multibridged rooms. My question continues to be: can we have a way to remove a portal (or route a portal alias to a plumbed room) if people want to migrate a room from portal to plumbed without getting lost in multibridge confusion?

@ara4n ara4n reopened this Mar 25, 2017

@ara4n

This comment has been minimized.

Copy link
Member Author

commented Mar 25, 2017

@Kegsay: perhaps we can discuss this IRL on monday to try to converge on the same page rather than diverge...

@Mikaela

This comment has been minimized.

Copy link

commented Mar 25, 2017

My question continues to be: can we have a way to remove a portal (or route a portal alias to a plumbed room) if people want to migrate a room from portal to plumbed without getting lost in multibridge confusion?

Do I understand correctly that the request turns into: when room is plumbed, have the appservice remove the #_network_#whatever:matrix.org and add (or let the user add) it to the newly plumbed room where the user has PL100? EDIT: It would also need to remove all other aliases and require PL51 or higher for inviting users to have new users going to the right place.

If so, it seems like a good idea to me removing the requirement of asking Kegan for PL100. Also the original comment and possibly issue title should be clarified.

The issue that would still be there is that the users of the portal room would have to move by themselves, but that doesn't seem like an issue as IRC channel renames do happen.

My alternative solution would possibly be forgetting plumped rooms entirely and instead inviting the user to portal room and sending a message to the IRC op asking if they would like to make the Matrix ID the room owner/founder (closest to PL100 at IRC). won't work unless the bridge starts supporting ambiguous IRC services and checking ChanServ info and whatever different networks invent.

@ara4n

This comment has been minimized.

Copy link
Member Author

commented Mar 29, 2017

Having IRL'd with @Kegsay we're now on the same page:

  • as @Mikaela says, being able to get ops on portal rooms solves much of this (once this is rolled out), except...
  • if folks have independently created separate plumbed and portal rooms whilst getting familiar with using Matrix for an existing community, and then want to somehow kill the portal room in favour of the plumbed one to avoid ugly doublebridging. this is essentially a request for being able to merge rooms though, and a separate bug: vector-im/riot-web#2299
  • Portal rooms where the user has gained ops are still unable to set room name, delegate power by editing power levels, or change history visibility(!) These are all reasons why folks might then go and create a plumbed room anyway, and suffer doublebridging ugliness. We can fix this however by changing the default power levels for portal rooms. I'll file this as a new bug.

@MilkManzJourDaddy: i get that you are trying to help, and that buried somewhere in your comments are some good ideas. however, your way of presenting and discussing them overall ends up being entirely counterproductive. This bug is now drowned in huge rambling comments which take ages to decrypt and overall waste our time and anyone else's who's reading it. In short, it seriously damages the usefulness of an otherwise useful resource (be it Github or a Matrix room etc). So, please either keep it concise, focused and free of subjective sidebars or we'll have to ban you across the board.

@ara4n

This comment has been minimized.

Copy link
Member Author

commented May 23, 2017

@Kegsay i'm seeing more and more people getting bitten by this - e.g. the confusion in https://twitter.com/matrixdotorg/status/866650347028303873 with #clojure on FN, and just now this came up:

cjd | Matthew: Is there any ETA on being able to get control of #freenode_# channels ?
Matthew | cjd: yes. i believe that as of today if you have ops on the freenode side you should also get ops on the Matrix side (although need to check)
cjd | cool
Matthew | alternatively you may need to bridge it explicitly (and then have ops propagate)
cjd| seems it did not work
so I've got #cryptpad:matrix.org and #freenode_#cryptpad:matrix.org and I guess there's really no way to unify them anyway, even if I get 50% power over #freenode_#cryptpad:matrix.org
Matthew | yeah, the double bridging problem is a mess that needs more thought :(
cjd| Maybe the thing to do is just allow people who have authorized bridges opt to shut down the #freenode_#xxx bridges on request ?
then that name becomes an alias to their authorized bridged channel
it solves the problem in the short term :)

The latter suggestion sounds quite interesting to me (and is back on the original track of this bug).

So: how come freenode portal rooms don't seem to bridge ops?
And, in the absence of being able to merge rooms, how about we let authorized plumbed rooms vape portal rooms, pointing the portal alias into the plumbed room, to try to avoid double-bridging?

@ara4n ara4n reopened this May 23, 2017

@Kegsay

This comment has been minimized.

Copy link
Contributor

commented May 24, 2017

how come freenode portal rooms don't seem to bridge ops

They do. I just tested it to be sure.

IRC:
* kegan gives channel operator status to kegan[m]

Matrix:
@appservice-irc:matrix.org changed the power level of @kegan:matrix.org from Default (0) to Moderator (50)

De-opping works as well.

@Kegsay

This comment has been minimized.

Copy link
Contributor

commented May 24, 2017

in the absence of being able to merge rooms, how about we let authorized plumbed rooms vape portal rooms, pointing the portal alias into the plumbed room, to try to avoid double-bridging?

We don't. The correct solution is to do #408. Vaping a portal room and replacing it with a plumbed room can create a schism between IRC and Matrix users, making it impossible for regular Matrix people to join particular IRC channels (because the room no longer exists and is at the whim of whoever controls the plumbed room). At this point we cease to be a bridge to all channels and people cannot treat the bridge as a bouncer, as there will be channels which just plain don't work.

Nearly if not all reasons given for plumbing are to add Matrix-specific information like the room name / avatar / alter history visibility. These things are things we should let authorised Matrix users do. They shouldn't be able to modify join_rules to make it impossible to join a channel. I have zero desire to have to step in and moderate 2 sides of a community when they end up with conflicting room rules which cannot be harmonised by the bridge.

@locutis-of-borg-1999

This comment has been minimized.

Copy link

commented May 26, 2017

then why bother with plumbs at all make peeps forever start by getting everyone registered on freenode and get authorization from irc authorities before bridging for a bounce logger irc people dont give a shift about ports or plumbs butt that guy u banned said to mute the ships port room and suggest also redirect to the plumb room like be in both butt only post in 1 sounded simple butt for all the posts he took to work it out

@ara4n

This comment has been minimized.

Copy link
Member Author

commented May 26, 2017

@Kegsay okay, fair enough.

@ara4n ara4n closed this May 26, 2017

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