[FEATURE REQUEST] Don't send `RemoteNickFormat` if sender of the last message is the same as the sender of the new message.

[SwirlyStone5877]

Is your feature request related to a problem? Please describe.
The channel gets cluttered if I send multiple messages because RemoteNickFormat is sent with every single message through a gateway.
Currently it is:

[Swirly on matrix]
test
[Swirly on matrix]
this could get cluttered quickly
[Swirly on matrix]
like nearly twice the height
[Someone Else on discord]
true though
[Swirly on matrix]
right???

Describe the solution you'd like
If the sender of the previous message is the same as the sender of the new message, RemoteNickFormat shouldn't be prefixed on the message.
It should be:

[Swirly on matrix]
test
this could get cluttered quickly
like nearly twice the height
[Someone Else on discord]
true though
[Swirly on matrix]
right???

Describe alternatives you've considered

1. make RemoteNickFormat take up only one line - maybe, but still cluttered and odd to look at
2. enable webhooks on the Discord end - I would have to deal with two forms of messages for RemoteNickFormat then: normal webhook messages and replies. I would go into further detail but this is not the focus.
3. continuously edit the last message - good for me, but forcing everyone to do that wouldn't be easy

Additional context
None.

[selfhoster1312]

So there's a few different things here. By default the nick is displayed on the same line. What configuration/bridge are you using where that's not the case?

About replies in webhooks, we have a pending PR here that makes a workaround. It's not perfect but we're interesting in more feedback before merging: #135

Maybe that solution would make webhooks viable for you?

[SwirlyStone5877]

What configuration/bridge are you using where that's not the case?

I have

RemoteNickFormat="""[**{NICK}** on {PROTOCOL}]
"""

simply because it looks nicer.

Maybe that solution would make webhooks viable for you?

I suppose? There's more issues than just dealing with two forms of messages (ex. name length limit, shown below via someone else's config)...

(this is meant to be "Slightly Large Protogen")

[kousu]

That is very cluttered, but what would you want to happen with an conversation that interleaves messages from multiple sides at once? Trying to do this will risk a race condition:

bridge: <user1>
Hey how are we doing on the canoe trip?

user2: Goddamn I sure love these coco puffs eh?

bridge: <user1>
I haven't heard anything from Maud in a few days about it.

bridge: <user3>
We're waiting for joe to get back to us on the money sitch

user2: Seriously have you tried these?

user4: user2 we don't care about chocolate here. Gummy worms only.

bridge: <user1>
user2, I don't care.

bridge: <user1>
Okay thanks user3; anything we can do to speed that along?

user4: You've been warned about this before.

Depending on network lag the messages could end up ordered like this on the other side:

user1: Hey how are we doing on the canoe trip?

bridge: <user2>
Goddamn I sure love these coco puffs eh?

user1: I haven't heard anything from Maud in a few days about it.

bridge: <user2>
Seriously have you tried these?

bridge: <user4>
user2 we don't care about chocolate here. Gummy worms only.

user3: We're waiting for joe to get back to us on the money sitch

user1: user2, I don't care.

bridge: <user4>
You've been warned about this before.

user1: Okay thanks user3; anything we can do to speed that along?

If you remove the per-message nick then it gets even more confusing

user1: Hey how are we doing on the canoe trip?

bridge: <user2>
Goddamn I sure love these coco puffs eh?

user1: I haven't heard anything from Maud in a few days about it.

bridge: Seriously have you tried these?

bridge: <user4>
user2 we don't care about chocolate here. Gummy worms only.

user3: We're waiting for joe to get back to us on the money sitch

user1: user2, I don't care.

bridge: You've been warned about this before.

user1: Okay thanks user3; anything we can do to speed that along?

Matterbridge can guarantee the order of its messages, so it's not the end of the world because someone can scroll up and find the last bridged message to discover who said what, but it's messy.

It's a good idea but how would you handle this case?

[SwirlyStone5877]

Actually... I have no idea how I would do that. I would say "just use a queue" but it's not that simple (especially for bridges that deal with a lot of messages), and network lag is still a thing...

I guess making it a config value is an option? If users experience network lag they can always disable this. Not exactly sure.

[SwirlyStone5877]

Figured I'd go on and write a PR for this. I have the gist of what I need down:

1. get content of last message sent in this channel/room/whatever even its its not sent by the bot
2. see if formatted nick matches prefix of message content
3. if it is remove the nick, if not keep it

Only issue is I'm having trouble with the first thing, do any smart matterbridge maintainers know how i would do this?
P.S.: I know I could probably do this with Tengo but that's Boring™.

[selfhoster1312]

Hello, thanks for your idea! Personally i think it's a very very bad idea. Like @kousu said, you are at the very real and non-minor risk of mixing messages because of network latency, unless your protocol has FIFO guarantees (which is probably not the case).

In addition to this failure mode on the remote side, we're currently working on making matterbridge fully async, which would cause the same kind of problems internally. Especially since you need to keep previous message inside the bridge's state (which we'll do for message replies/edits anyway), and race conditions in mappings across goroutines is very real (hopefully they don't crash and corrupt data, simply introduce logic bugs).

Now if you want to do this:

• you need to keep track of who sent the last message in each bridge, so that means figuring out everywhere we send a message on your favorite bridge (discord?) and adding something like b.LastMessageNick = msg.Username there
• then edit those places so if the current username matches the previous one, we remove it from the message
• figure out how the different formatting steps of username / remotenickformat actually work so you effectively remove the nickname

Now if you don't want to do this: most chat clients already remove the repeated usernames. This is a client UX concern and in my personal opinion should not be implemented in matterbridge. 🤷

[SwirlyStone5877]

You know what, fair enough. Tengo it is.

[SwirlyStone5877]

So this is an issue, with tengo scripting I can't see which protocol the message is going to. This is fine for bridges with only two endpoints but I have rooms with XMPP, IRC, and Matrix all interconnected.

EDIT: I'm just realising how little sense this would make to implement...

[SwirlyStone5877]

Although for anyone else who wants this, you can use this tengo script, though beware it is somewhat jank especially since I can't see which protocol the message is delivered to and you should probably set the current directory to somewhere you don't mind flooding.

os := import("os")
fmt := import("fmt")

result = ""

mapping := {
        matrix: "[**%s** on %s]\n",
        discord: "[<strong>%s</strong> on %s] <br>"
}

template := "[%s on %s]\n"

if mapping[protocol] != undefined {
        template = mapping[protocol]
}

formattednick := fmt.sprintf(template, nick, protocol)

tmpfname := fmt.sprintf("lnick-%s.txt", gateway)
if type_name(os.stat(tmpfname)) == "error" {
        file := os.create(tmpfname)
        file.write_string("")
        file.close()
}
file_but_the_other_one := string(os.read_file(tmpfname))
if formattednick != file_but_the_other_one {
        result = formattednick
        file := os.create(tmpfname)
        file.write_string(formattednick)
        file.close()
}

[kousu]

Sorry it didn't work out @SwirlyStone5877 but sometimes it's nice to work something out to learn why. Thanks for sharing your final product :)