Send message read notifications in a more sophisticated way

[tremby]

Through some rough testing I've found that the plugin is sending "message is read" notifications immediately on message receipt, even if the Pidgin tab in question isn't visible, the window isn't focused, I'm on a different virtual desktop, the window is minimized, etc. Only when I set my status to "away" does it not send them, it seems.

I wonder if this could be more sophisticated.

Pidgin gives the tab a particular colour when there is an unread message, meaning either the window was unfocused or the tab wasn't active. I think it'd be best if the notification was sent when this Pidgin notification is cleared. Same sort of thing for Finch.

Would this be possible -- can you get at this data from a plugin?

[majn]

I haven't found any protocol plugin that managed to do it like that.

According to the discussion going on the pidgin issue tracker (https://developer.pidgin.im/ticket/6940#comment:33) there may be a way to do it, but implementing it is likely going to be very experimental and time-consuming.

[tremby]

I'm not sure the comment you point to there is entirely relevant. The way I interpret it, it's simply pointing out that message receipts (tell the server that the client received the message, so presumably it doesn't keep trying to send it) and "eyeball acks" (user has looked at the message) are different things, and that eyeball acks aren't entirely reliable (window may be focused but the user is not looking at the screen). And the thread in general is about implementing the XMPP extension which allows one or both of those kind of acks; this part at least obviously isn't anything to do with Telegram.

We know all that, I've no arguments there at all. You're obviously already sending both types back to the Telegram server: the receipt ack on message receipt, and the eyeball ack as long as or as soon as the user's status is "available". Or is this something which is somehow happening automatically without specific code for it?

Maybe I should clarify.

I'm not imagining anything fancy, like avoiding sending the eyeball ack if the window is focused but obscured by another. I'm only imagining using the existing functionality in Pidgin/Finch which knows whether a given tab has unread messages -- on my setup, which I believe is default, that means the tab title is highlighted red (chat) or blue (IM or chat mention); or in Finch, meanwhile, the window's tile in the little taskbar at the bottom has a red title when there's a new message until it is focused.

I would have thought all you'd need is to tap into this information.

Come to think of it, the Markerline plugin must be using this information, or at least recreating it somehow, since it knows when a given tab has been given focus.

[majn]

Come to think of it, the "Markerline" plugin must be using this information, or at least recreating it somehow, since it knows when a given tab has been given focus.

There are two different types of plugins: Pidgin plugins and libpurple plugins. Pidgin plugins like markerline are allowed to use interface of the Pidgin GUI implementation, which allows them to do something like this. Libpurple plugins are supposed to work with any client that uses libpurple.

I'm not imagining anything fancy, like avoiding sending the eyeball ack if the window is focused but obscured by another. I'm only imagining using the existing functionality in Pidgin/Finch which knows whether a given tab has unread messages -- on my setup, which I believe is default, that means the tab title is highlighted red (chat) or blue (IM or chat mention); or in Finch, meanwhile, the window's tile in the little taskbar at the bottom has a red title when there's a new message until it is focused.

The highlighted tab on unread messages seems to be something that is handled entirely in the Pidgin UI on top of libpurple. The signal "conversation-displayed" that is used to determine the read-state of the message is a signal only emitted by GtkConv, it will most likely not be present in other GUIs.

There may be other ways to do this, but I haven't figured them out yet.

[tremby]

I understand.

I suppose, then, that it would need to be a libpurple change. The GUI would have to tell purple that a given conversation has (probably) been viewed, and then libpurple could offer that information to any plugins.

[majn]

Apparently there was a GSoC project in 2015 that rewrites the messaging backend to use SQLite3 and also offer an API for accessing messaging objects. It also seems to include all kind of things regarding the seen / unseen status of messages.

Open questions:

• when and if those changes are going to be available in Pidgin. Maybe only in Pidgin3? The fact that it will break the plugin API strongly indicates that this will most likely be the case.
• the API changes are sufficient to actually implement the feature

Disclaimer: the diff of changes introduced by the GSoC project is 8000 lines long https://www.google-melange.com/gsoc/project/code_sample/download/google/gsoc2015/igor_gajowiak/5757334940811264?id=5657382461898752

[majn]

If someone found the time to research those issues it would probably a great help to the whole pidgin project, not only to telegram purple. Telegram isn't the only protocol that implements those "Eyball acks", basically any modern messenger uses them in some way.

What would be necessary is some kind of function / callback / signal that informs the protocol when a message was rendered into a conversation for the first time. Alternatively, at least a callback/signal whenever a conversation is being focused.

[tremby]

All understood. Here's hoping the necessary features appear somewhere down the line.

What would be necessary is some kind of function / callback / signal that informs the protocol when a message was rendered into a conversation for the first time.

That doesn't seem suitable to me. It may have been rendered into the window on a different virtual desktop, or the window is obscured by another; there are various other scenarios. Even if it was rendered on the current desktop and the window is visible, I personally don't want the ack sent until the window gets focus.

[sethdmoore]

How about sending the ack on a "on-typing" style event or making it configurable?
Personally, I would love an option to send the "read all" ack on message reply, as I use telegram-purple through weechat / bitlbee.

[majn]

It already works like that if you turn automatic acks off.

[tremby]

It already works like that if you turn automatic acks off.

Oh? On typing, or on reply?

[majn]

Both should work.

[tremby]

Ah. It might be nice if that were a bit clearer in the configuration panel. I switched the acks on, thinking they wouldn't be sent at all if it wasn't checked.

[sethdmoore]

majn, I know the way I use telegram-purple is not supported, but I have 'send-read-notifications' set to 'False', and it does not send read notifications on reply. It does not send them at all. Keep in mind, I am using telegram-purple through bitlbee-libpurple and interfacing through weechat, so it might be missing whatever event sends the read ack.

I am using telegram-purple Mar 17(ee2a6fb) and bitlbee-libpurple Apr 6 (c9603a38774fb118d4aaa96e170674412ed7328a).

[burik666]

Google Hangouts (XMPP) mark message as read on reply.

[marsjaninzmarsa]

I haven't found any protocol plugin that managed to do it like that.

Some research for purple-facebook here dequis/purple-facebook#221.

[BenWiederhake]

If anyone feels like implementing this enhancement, it might be a better idea to direct your energy to tdlib-purple. For now, there seems to be nobody who implements any enhancements for telegram-purple, so I'm closing all "enhancement" issues.
Of course, Pull Requests are still very much welcome!