exquo
commented
1 year ago This would be great! This feature has long been needed. Now that signal-cli has the dbus support for it (had it for while by now, actually) this really needs to be implemented in scli.
The biggest challenge is, as you say, detecting the user's "focus" (similar to #109), so that we only send read receipts for the likely-to-have-actually-been-seen messages. I think Signal-desktop has a leg-up with this: Electron probably makes available such information as whether its window is currently in focus, etc.
For the purposes of sending read receipts in scli though, I think we can just send them after any keyboard activity from the user, while the newly received messages are in view. Does that sound reasonable?
This will require writing some code for urwid's keyevents. I should be able to help with that, or point to the relevant documentation.
Another relevant issue (but a less important one) is that scli currently focuses the view on every newly received message. When there are many messages received in a chat, this results in some of the earlier ones scrolling out of the top of the view (since the latest message will always be made visible). So the last received message might be seen by the user before the first (unread) message. And so the RR will be sent for all the new messages in chat, even when the first one hasn't been seen yet.
The official clients handle this properly, by not allowing any of the unread messages to scroll out of view.
Fixing this would again require dealing with urwid's specifics (how items are focused in the corresponding ListBox object). This might be tricky, and probably not strictly necessary for implementing a good-enough read-receipt functionality.
I seem to remember that when Signal Desktop is open (but not focused, or focused but on a different contact), notifications on the phone arrive with a delay, seemingly giving the user a few seconds to check them out on desktop, before "spamming" their phone
This might be just the phone being slower to receive the messages. Perhaps because of power saving, when it polls / gets pushes less frequently. I don't think Signal clients exchange such info as which clients are concurrently opened. They just each receive new messages from the server.
Finally, some general notes on the sending-read-receipts functionality:
- This should be optional, so that users can opt out (scli's current behavior). Other choices can also be made available (if we think of them :), like under what conditions and how to send RRs.
- We'll need to check the produced implementation for not sending too many / redundant / repeated RRs. There are probably many ways to make this mistake, and initial attempts are likely make it.
Let me know if I can help with anything else related! I haven't had much time to devote to this lately, but will try to be of assistance.
maximbaz
I'd like to implement sending read receipts, and I want to run it by you first, to discuss some architectural decisions :smile:
The primary goal: I don't want to receive signal notifications on phone/smartwatch, if I'm actively chatting in
scli.The main challenges, as I currently see them, are:
signal-clito actually send read receipt.scliis currently focused.The first item seems possible, although I haven't worked with
signal-clibefore, I can see sendReadReceipt in the docs. Do you see any challenges here, missing APIs or some other problems? I haven't used Signal Desktop for a while, but I seem to remember that when Signal Desktop is open (but not focused, or focused but on a different contact), notifications on the phone arrive with a delay, seemingly giving the user a few seconds to check them out on desktop, before "spamming" their phone. I don't know if that's just "magically" works via their backend, or there's a special API to use, to activate such "delayed" mode. Do you know, perhaps?Detecting whether a user is currently looking at
scliis both difficult to implement for everyone, but at the same time is easy to do when you know the particulars of user's setup. Just to give you a concrete example, I am running Hyprland, which comes with both a CLI tool that can detect the currently focused window, and a Unix socket where you can subscribe for events of changing the active window. Identifyingscliprocess specifically within a terminal window is also possible, e.g. by running a dedicated terminal instance with a custom app_id / class (e.g.kitty --class=scli scli).So it sounds like it should be left to the user, to tell
scliif it's currently focused, andsclishould send read receipts if it has such information.Here are the two different ways I thought such integration could potentially be implemented:
sclia command, which it periodically runs, say every second or two, to detect ifscliis currently focused or not (say it outputs a boolean). Maybe also runs it additionally after every received message.sclia couple of Unix signals (saySIGUSR1andSIGUSR2), which would tellscithat it got focused and unfocused respectively. We leave it up to users to send those signals (either precisely when these events occur, if they can e.g. subscribe to a socket like me, or just sending these signals in an infinite loop).The latter seems a lot more robust and battery-friendly, but also requires users to implement more glue.
What are your thoughts on it?