Handle IRC style mentions

[lieuwex]

This replaces irc mentions like 'john: ' and 'john, ' to '@john '.
Closes #2

[raine]

Since no one seems to be noticing it, I just wanted to say good job @lieuwex. This is a welcomed addition.

[malditogeek]

Hey @lieuwex ! Thanks for the PR!

I'm having trouble running it locally, the regexp is crashing for me... sometimes when it doesn't match I get a null instead of undefined, etc. Do you have any ideas on how to make it more robust? I think we could use string.match() instead and check for a falsey value.

I'm also concerned about fetching the room.users() on each message, mainly because we have very big rooms of around 5k users and that would be very expensive. Do you think a more naive version that just replaces any user: at the start of a line with a mention could work?

[raine]

I'm not sure that's a good solution.

user: hi and user, hi are both valid and common (although colon more so) autocompletions on IRC.

It would end up looking weird on gitter end if someone starts their message with 'thing:' that isn't a user.

[raine]

This should probably be !== null. .exec that produces no match returns a null.

[lieuwex]

Damn you're right, I had trouble running the server locally, I even checked the result of .exec when it doesn't find a match, woops 😅

[lieuwex]

I'm also concerned about fetching the room.users() on each message, mainly because we have very big rooms of around 5k users and that would be very expensive. Do you think a more naive version that just replaces any user: at the start of a line with a mention could work?

Didn't thought about that, that's a pretty serious issue. Just like @raine said, I don't think a naive version would be a good solution

[malditogeek]

any other ideas?

I'm thinking about keeping a cache of the users in the room and keep them in sync as they join/leave; and use this cache for the lookup.

[Arnavion]

This is the wrong thing to do. You shouldn't be replacing what the user types - everyone should see the same text. Worst case, you replace something that wasn't meant to be replaced and now you have a situation where the IRC user doesn't know their text has been replaced and everyone becomes confused.

Either gitter itself should be changed to allow mentions without the leading @, or IRC users should remember to manually prefix with @ when intending to highlight someone.

[mkaito]

Ideally, my IRC client would allow me to configure a completion prefix. ALAS, it doesn't. And weechat is one of the more advanced clients out there.

[Arnavion]

Yes, I've been working on a bunch of gitter-related features for HexChat (so far, just a workaround for the broken pongs) and a custom completion prefix is how I plan to fix it too.

[mkaito]

Well I haven't found anything for weechat that would allow me to configure a per-network completion prefix and suffix. If you come across anything, please let me know 😄

[floam]

This is the wrong thing to do. You shouldn't be replacing what the user types - everyone should see the same text.

If a client supports the IRC v3.1 echo-message capability, the client receives a copy of what they have sent, after being interpreted by the irc server, after (specifically) the final changes have been made. It's acceptable to do this for any capable client.

[Arnavion]

@floam I would argue it's still unexpected to change text just because there is no precedent for it.

More importantly, AFAICT irc-bridge's current design makes it difficult for it to support caps. Since it uses faye, every user connected to the same channel receives the same content. They could make separate channels for clients with and without a cap and send different things to each, but that would then combinatorially explode with each new cap (as I mentioned in #42).

[floam]

I dunno. It may be unexpected the first time I suppose. It is a new feature to hit IRC after all.

They won't be shocked or confused though.

They're familiar basically the conventions on Gitter - at least the @'s.

They understand and decided to they're connect to an IRC network that translates things such that they can use their IRC client to access Gitter.

Imagine our unsuspecting user with his bleeding edge IRCv3 client... They understand exactly what it's doing the first time it does it - an IRC v3 feature - working in this unique context of a Gitter gateway.

What's the harm in the feature, really? (if it's possible to implement?)

[floam]

I should acknowledge - some are of course trying to use a an IRC gateway because they found that these lowest common denominator, one-channel-one-huge-window-with-one-visbile-tab, walled garden, overdesgined, group messaging tools NO GOOD IRC COPYCATS like Gitter or Slack would be better if they just used an IRC client. Maybe the guy seethes with anger, hates seeing that damned @ - but that guy isn't opting into any IRC v3 features, doesn't have to - it's purely voluntary.

Sorry to ramble there - my point is only, the spirit of these capabilities is if you don't advertise for it, the IRC servers are to behave as if there is no such capability in the world. Otherwise, that's the new shiny stuff happening right where you'd expect it.