Bridge topics

[kegsay]

We don't really do this currently because of the semantics between "should we use the matrix topic" or "should we use the IRC topic". I propose:

• Add a new config section:

  # Controls how topics should be set between Matrix/IRC
  topics:
  # Use the topics set in these rooms instead of any IRC one
  useRooms: ["!foo:bar", "!baz:quuz"]
  # Use the topics set in these channels instead of any IRC one
  useChannels: ["#chan", "#chan2"]
  # If neither room nor channel match the lists above, use the topic from irc|matrix
  default: "irc"

Edge cases:

• If a room matches both useChannels and useRooms then the topic will not be bridged at all (current behaviour).
• If syncing M->I topics and the virtual IRC client fails to set the topic (not ops), then [1]
• If syncing I->M topics and the virtual Matrix user fails to set the topic (no power), and the bridge bot cannot grant the user power, then [1]
• [1] = Do one of the following:
  • [PM] : Send a PM from the bridge bot to the originator of the topic to say ERROR: Failed to bridge topic.
  • [SRC] : Send a message into the source room as the bridge bot (who may not be joined) to say ERROR: Failed to bridge topic.
  • [DST] : Send a message into the destination room as the virtual user to say ERROR: I can't set the topic.
  • [NOP] : Silently fail.

My feeling is probably [PM] but this is horrible because often the topic is set by an individual who may not be in the room anymore or may not really contribute/follow the room much at all. In this case, PMs will be sent to them to say "waaah waaaah I can't bridge! SADPANDA!" which feels really horrible.

Rationale:

• Not part of explicit mappings because you may want a specific dynamically bridged channel to use a different topic.
• Whilst the bug is mainly to do with bridging IRC topics to Matrix, also including the inverse for symmetry.

[eternaleye]

One thing I'm unclear on: Why "should" we use one or the other statically? To expand:

• On Matrix, the bridge can see the history of changes retrospectively
• On IRC, as long as the bridge is connected, it can observe changes as they happen
• The bridge, being a single node, is essentially free to presume linear time

As a result, unless connectivity with IRC is lost, the bridge can indeed safely mirror in both directions.

For dynamic bridging, I suspect the only sensible option is that on room instantiation, immediately copy the IRC-side topic, and then begin mirroring.

Statically-bridged rooms are slightly trickier; I'd personally have the bridge emit a message (on the Matrix side) when bridging starts if neither of these conditions is true:

• The topics already match
• One is empty (which the bridge then replaces with the non-empty topic)

The message would request that someone bring the topics into alignment, at which point it begins mirroring.

The same could be done if the bridge loses connectivity to IRC, IRC changes, and then connectivity returns.

(If connectivity to Matrix is lost, it can essentially just check the times the HS received the state changes, and decide which way to mirror.)

[Ralith]

In most cases (e.g. most of freenode) the bridge operator does not have any special standing in a bridged channel, so strictly clobbering matrix topics with IRC topics is desirable.

I'm confused by the proposal to use IRC channels for one config setting and Matrix rooms for another. Why not just use matrix room IDs alone, along with a (per-server?) default setting for rooms that are not otherwise specified?

[sbts]

@Kegsay Your initial description of the issue is somewhat wrong. As things currently stand

for those (few) people that have power in a bridged room we can currently enable topic sync (IRC>Matrix) if we give the IRC user that will change the topic sufficient power (Moderator [50] by default)

The reverse is also true,

If the IRC side matrix (ghost) user has OP's in the IRC channel then that user can issue /topic foobar and change the IRC side topic (and the matrix side as well)

This would suggest the simplest solution would be to ensure that OP's is requested in the IRC channel if a user with enough power (matrix side) requests a topic change, before the change is made.

Conversely if an IRC side user requests a topic change that succeeds we should simply honor that on the matrix side.

If we wish to permit matrix and IRC topics to differ, then require that the topic has a "prefix char" that prevents the sync in both dir's. The prefix char could be as simple as a leading space, dot, or single quote These should be relatively non intrusive

[jansol]

I like the prefix char idea, assuming you'd rather not go into per-room bridge settings. Also,

I'd still like to see a message about topic changes on both sides maybe if the topic has the prefix, send a notice, else set the topic. something like (as the corresponding user) /notice topic on matrix changed to "foo"

[sbts]

One of the benefits (IMHO) to using a prefix char would be visual indication on both the matrix and IRC sides that the topic is not synced

[Ralith]

A prefix char is pretty unintuitive as far as visual indications go. I really think this should just be a simple per-matrix-room flag, having settings for "sync from IRC", "sync to IRC", and "sync both ways".

[sbts]

@Ralith A Matrix Side UI is nice, and in the long run I agree it's something that should be implemented IF we want to support different topics on either side of the bridge. However a MATRIX side UI hides behaviour from the IRC side of the bridge. That is why I suggested a prefix character. At least that way, there is some indication (albeit only to those in the know) that an IRC side topic may be replaced with a matrix side one.

Once we have a matrix side UI, we could even have the matrix side Enforce the presence of the prefix char

[kegsay]

I like a lot of these ideas. I would like some more ideas on a sane way to communicate failures to both parties when the topic fails to be set though (due to lack of ops on IRC or lack of power on Matrix). Bear in mind the two main scenarios of:

• Dynamically bridged "Portal" rooms like the entire #freenode_ namespace (whereby the owner of the room, that is to say the person who would yell at you if you were doing bad stuff, resides on IRC)
• Explicitly mapped "Plumbed" rooms (whereby the owner of the room resides on Matrix)

When we decide to set the topic of a room/channel of course can vary, be it:

• Dependent on the first character of the topic
• Whether they were previously exactly the same
• Explicitly stated in a config file

but handling of errors is still required in all these cases, and I don't have a satisfactory solution to this.

---

I like the idea @eternaleye has brought up:

have the bridge emit a message (on the Matrix side) when bridging starts if [the topics don't match or one topic is empty]. The message would request that someone bring the topics into alignment, at which point it begins mirroring.

This would allow rooms to not mirror topics (if you ignore the request and do nothing) and would also allow them to be mirrored (by bringing them in sync), and asks The Humans to sort it out. The prefix idea is nice and gives the same flexibility to users of the room but is much more subtle and not easily discoverable. I like both ideas over and above static mappings in the config because it allows the actual room members to sort it out if they want their topic to mirrored or not, rather than relying on the bridge operator.

[eternaleye]

@Kegsay: Your bracketed substitution is subtly off - I suggested that one-empty allow mirroring immediately, overriding the empty one with the one that has text in it. This is because dynamically bridged rooms to existing IRC rooms will always start in that state, and will almost always want to copy the IRC topic. The same is true of "plumbed" rooms where the IRC side was non-existent.

The only case where user intent is unclear, and thus user intervention is needed, is when both are pre-existing and had diverged.

[kegsay]

Ah, thanks for the clarification!

[Ralith]

Trying to guess the right course of action based on the current state of either room's topic seems prone to breaking down as soon as one side or the other has a netsplit. Meanwhile, the IRC bridge is often (perhaps almost always) used purely as a front-end for IRC channels, by people who don't have any special rights on those channels. I'd really like to see the simplest, most basic "set matrix topic whenever a TOPIC message is received on the bridged channel" behavior implemented to address what is currently a major missing feature for this use case.

For the (rare?) cases where people want other behavior, a per-matrix-room option to select it seems adequate. There should be no need to give virtual users matrix-side rights when a bridged room receives a TOPIC message, the IRC server has already checked that it's valid and authorized.

[leonerd]

Revisiting this now, it looks to me as if there's a simple solution that would solve a majority of cases:

For portal rooms (i.e. #freenode_.*), wherein on the Matrix side the bridging bot has power=100 and all the normal users don't, we should just pull the IRC topic into Matrix, so that Matrix users simply using the portal to "look at" IRC (which is why I invented that name in particular) can see the correct topic. This answers 99% of the awkward cases because the bridging bot will have that power already, and is expected to be in control of the Matrix-side of the room.

Plumbed rooms are already awkward, so I suggest until we have a clear idea of what to do there, we should continue totally ignoring the topic in them, as we do now.

This hopefully should get us at least part way to a full solution.

[kegsay]

@lukebarnard1 - @ara4n wants portal-based rooms to have topics, and that is a lot easier than completely solving the topic problem. We know the origin of mappings now: one of:

• config
• provision
• alias
• join

Basically, for any mapping which is not provision or config, we should try to set the topic as it comes down as the bridge bot user. provision is exclusively from plumbed rooms, config are things like #matrix, and both of those we don't want to set topics in. If one doesn't exist (from before we stored the origin), or is alias or join, it should be safe to set the topic on Matrix as the IRC topic.

You may want to cache this like we do elsewhere, because if you have 10 users in the same channel, there will be 10 topic events from IRC.

[sbts]

I have to agree, I was intending to write up something similar in
  the morning.

I'd go as far as to say that any room that is "created" as a
  bridged room (by any means) should automatically follow the IRC
  topic.
On the other hand, and room that is bridged after it's creation
  would either need special treatment via config to decide, or use a
  dumb decision making tool along the lines of
- if the topic was blank when bridging enabled, mirror the topic
  - or the topic was equal when bridging enabled, mirror the topic
  - Otherwise don't bridge the topic
If the above conditions were summarized as "topic will/won't be
  bridged" in the UI where bridging can be added the opportunity to
  alter the behavior is given to the user. 

David G (dcg_mx)

[Mikaela]

@sbts I think your email got a lot more information than it should have had and especially that one thing looks sensitive.

[ara4n]

i've edited to remove the sensitive inexplicable JSON from @sbts's post. would love to know where on earth it came from!

[sbts]

@ara4n weird, I really don't know what was included there (I haven't seen the content) it was a simple reply from thunderbird to the subscription email

[Valodim]

Just wanted to note that this came as a surprise to me, using a configured channel and not getting topic updates after an update. I digged through the code to see what had changed that prevented topic changes from happening (before finding this issue), and ended up hacking it back in.