Add Telegram-side highlighting for IRC messages prefixed with username

[jwflory]

Users on IRC will use another user's nick to highlight their attention. This notification behavior is not translated over to Telegram, which receives them as plain text. For users on IRC-side, it can be confusing if they have notified someone or not.

Add a pre-processing hook for IRC-to-Telegram messages that scan the beginning of the message string for a single "word" prefixed by a :. If this is found, assume the text is a username and prefix the message string with an @.

This improves the user experience for participants in IRC and makes it easier to engage and continue conversations across the bridge.

[Chris-Bitler]

I'm not sure prefixing (or suffixing might be what you mean here, since prefixing it would result in something like :jwf [text] as opposed to jwf: [text].) explicitly using a : is the best idea. Most IRC clients allow configuration of what the character after a tab-name-selection will be, or in some cases there is none by default (as is the case with the IRC client I use). Is there potentially a more general way to approach this?

[jwflory]

@Chris-Bitler For clarity, I meant prefixing like the following example:

An IRC user types this message:

jflory: Hey there!

In Telegram, the message becomes:

@jflory: Hey there!

It is possible that an IRC user doesn't use a colon, but I think it's the best default to assume. I see this used most often. I'm not sure of a better way to approach it though. What do you think?

[bexelbie]

I think relying on a particular prefix character or line placement is going to miss some (a lot) of names. Could the bot know the names of the people in the channel from the membership list and just do a replacement for all of those names in the string? So if it see that @jflory is in the room, it turns:

"Hey jflory are you going to make the meeting tonight" into "Hey @jflory are you going to make the meeting tonight"

This could also be extended by allowing people to register their irc nicks with the bot so it knew better what to highlight.

[jwflory]

Discussed in 2019-02-02 RITlug developers' meeting. This issue is targeted for the v1.3 milestone, estimated to release on March 2nd, 2019.

---

We agreed with @bexelbie's suggestion of how to handle this. The approach we discussed was on start-up, the bot can collect a list of usernames from the Telegram group. If someone joins or leaves the group while the bot is running, this list would be updated. Each IRC message processed by the bridge checks if the message string contains a username of someone in the group. If so, Teleirc prefixes the @ symbol to the detected username in the string.

@nic-hartley volunteered to look at this. We'll check back in at the next developers meeting on Saturday, Feb. 9th.

[nic-hartley]

Started work on this. Hopefully will be done in a day or two, but I'm still researching it.

[ct-martin]

It'd be nice to have a user-level setting to toggle this for people on both sides of the bridge

[jwflory]

Discussed in 2019-02-09 RITlug developers' meeting.

---

No progress yet, mostly docs reading and testing. @nic-hartley aims to submit a PR for this by next developers' meeting on Saturday, Feb. 16th.

In terms of user preferences, we agreed this is a bigger task than can fit into this sprint. But some of work for this issue (e.g. keeping track of Telegram group membership) are useful for implementing user preferences later.

@ct-martin, could you please file a new RFE issue for user-configurable preferences and give some examples of other things that might be helpful for you as a user to configure?

[jwflory]

Discussed in 2019-03-02 developer meeting.

---

This feature is pushed to the v1.4 release.

• Reviewed our options for the best approach to implement this
• Turns out, getting list of current users in a Telegram group is really really hard
• Better option to parse X number of previous messages and scrape usernames from those messages, because that's easy to do?
  • Default of 100 messages to scrape? And allow user to set larger reverse history if desired (or smaller)
• @nic-hartley to research implementation and post back here with proposed implementation
• Reviewed over-arching project goal to be as lightweight and lean as possible

[nic-hartley]

Quick update: I've been really busy over Spring Break, then over the week after, but I've got a sorta-working demo of this running on my machine. It badly needs a bit of a refactor, but so far:

• It scans back 100 messages (hardcoded for now) and gets the usernames from those messages
• As more people talk, join, and leave, it updates its list of who's in the room
• Whenever a Telegram username is mentioned IRC-side, it prepends an @ to make it a ping
• Whenever an IRC nick is mentioned Telegram-side, it adds bolding (with STX/ASCII 0x02 either side). This feels brittle, but it does seem to be supported by the handful of IRC clients I spot-checked. I can't find it mentioned in any IRC RFC, though that might just be my inability to find IRC RFCs in general.
  • There's no weird message-lookback hacks for IRC -- I just need to listen to the names message.

What I need to fix before I'm comfortable pushing this:

• Remove a couple of other, unrelated, unfinished experiments. (I just used my test branch, and by the time I realized, I'd already done a bunch of work.)
• Clean the code up. For example, I currently hook into the names event very differently from how every other event is hooked into, because it was a test to see how it worked that evolved into real code. That's not the only thing, though.
• Fix a couple of outstanding bugs. For example, overlapping nicknames in a message (e.g. hello @alongname, with alongname and name in the channel) will both get pinged (hello @along@name). None of the bugs are difficult to fix, but I need to get around to it.

All of that is probably gonna be done with a partial rewrite. Total time is maybe 2-3 hours at most, since writing it in the first place didn't take long and redoing it will take less time, but I don't know when I'll have 2-3 hours of free time in the next few days.

[jwflory]

Discussed in 2019-03-30 Teleirc developer meeting.

---

@nic-hartley is working through a major refactor in order to complete this ticket. We set a goal for a draft pull request to get wider maintainer review by the next developer meeting on Saturday, April 6th. This won't be a final implementation, but the goal is to get more feedback on the changes made so far to make sure everything will go smoothly later when we get to merging it for real.

[jwflory]

Discussed during 2019-04-06 developer meeting.

---

We have decided to close this issue as out of scope for Teleirc because of the significant engineering effort required for a low-value feature add.

Since the volunteer maintainers do not have enough time and bandwidth to spend on this implementation, we decided to rule this issue out. We are closing it because there is no maintainer interest to work on it and we have no feedback from the user community if this feature is actually useful.

For these reasons, we ruled it out. If someone disagrees and thinks this feature is tremendously useful, please share your feedback and use case, and we will re-evaluate again if needed.

Special shout-out to @nic-hartley for spending research time on this issue and testing implementations. :100: