Mark as unread / Send (push) notification to phone

[atticus-sullivan]

Hi,
I want to use signal-cli to send notifications to my smartphone. The problem I've got is that I registered the signal-cli instance on my RaspberryPi as additional device for my normal phone number. Therefore I do not get any notifications when sending messages since they are already marked as read.
Do you have any workaround for this (apart from using another phone number for the RaspberryPi instance).

I already thought if it is possible to at least mark the conversation as unread (wouldn't send a push notification but at least it is visible that there was a new message when opening signal manually), but I see no way this is possible up to now. Am I missing this option and if not, any plans implementing it?

[AsamK]

That should already work, which signal-cli version are you using?
Previous issue: #373 (comment)

[atticus-sullivan]

I'm using signal-cli-0.11.4 (patched the libsignal_client for use with raspberryPi as described here https://github.com/exquo/signal-libs-build).
Checked it again right now with message sent from the commandline (not using the dbus setup) and the message also was already read (checked with an empty group I'm using and the note to self feature).
Gonna have a look at the issue you linked.

[atticus-sullivan]

Alright, just checked it works for the note to self feature to get the notification. The reason why I stumbled over this is because I try to separate things and use empty groups (easily created with signal) for similar purposes.

Any chance to get this send notification feature for other chats than the note to self one?

[AsamK]

That would indeed work, I made a small test branch here: master...notify-self-group

But I'm not sure what the interface should look like. The default behavior of signal-cli send -g GROUP_ID should remain as it is currently.

For the new notification behavior it would either need a new group flag with self notification (like --group-notify-self GROUP_ID) or an additional flag that changes the behavior of the -g/--group parameter (like --notify-self). Though that wouldn't fit well with the existing distinction between sending to self with +SELF_NUMBER and the --note-to-self parameter.

[atticus-sullivan]

Well in my opinion the cleanest way would indeed be to introduce a --notify-self flag which results in the user himself getting notified.
But of course you have a point of this solution not being compatible with the current implementation of note to self. But wouldn't this be a solution, mapping the notifying behavior of note-to-self to a normal send with the notify-self flag being enabled?

[matthiasdg]

Got a similar use case; I use https://github.com/bbernhard/signal-cli-rest-api (built on top of signal-cli) to send messages from my own number to a signal group composed of the housemates (including myself) when somebody presses the doorbell button, since there are some "deaf spots" throughout the house.

Had first tested with messages to myself, which worked fine (=resulted in a notification). Was surprised to find out notifications did no longer work with a group. Created a build which included the changes mentioned above, but that resulted in the message sent through signal-cli being displayed twice; once on the sender and once on the receiver side, where it was already read and still no notification was sent 😞 .

Then looked at #373 (comment) and also built libsignal-service-java so sync messages are also not sent in this case (actually they're never sent now; since this is my only use case I didn't bother to check when they are useful - docker image: matthiasdg/signal-cli-rest:0.11.4-bis). This results in notifications + the message only appears on the sender side on my phone 🎉 A more general approach will require some more thought...

[atticus-sullivan]

I don't want to put any pressure on this (it's our all free time after all), but is this feature planned or is this stale?

Just from a users POV, it would be nice to have a general flag --notify-self=true|false with which one can control whether a notification to own devices is being sent or not. The default has to be true if using sendNoteToSelfMessage and false in all other cases to make this change backwards compatible.
For me personally more important would be having this feature available for the dbus interface (just an additional bool parameter at the end while having the same defaults like with the flag).

Any objections with this way of including this feature to the commandline- and dbus-interfaces?

[AsamK]

It's still planned, just haven't decided on an API yet...

For dbus it will be a bit more difficult, as adding a parameter to the send method is a breaking change.
The dbus send interface is also missing other functionality, that would need additional parameters ... eventually I want the send method to have an additional dictionary parameter for new features, that can be extended without breaking changes. But I don't have a concept for that yet.

[atticus-sullivan]

Alright, nice to hear this is still planned 👍

I'm not too experienced with the dbus, but looking at e.g. sendMessageReaction isn't it possible to have polymorphicish like functions (in this case the same function with different types, in our case the same function with an additional parameter)?

Oh and I see where you're already going with the V2 dbus-signals and this additional map. Looks like a nice idea factoring out optional/new feature parameters to a map 👍

But I don't have a concept for that yet.

What exactly are you referring to? No concept for adding a map parameter to the function call?

[atticus-sullivan]

Sorry for being that late after your commit, but does that commit really fix this issue?

For me the only thing that changed is that now I never get notifications when sending via dbus. So do I get it correctly that currently there is no way to send a message which triggers a notification for oneself via the dbus interface?

Am I doing something wrong here?

[pi@rpi ~]0$ dbus-send --system --type=method_call --print-reply --dest="org.asamk.Signal" /org/asamk/Signal org.asamk.Signal.sendNoteToSelfMessage string:MessageText array:string:
method return time=1710984040.246621 sender=:1.3959 -> destination=:1.4056 serial=480 reply_serial=2
   int64 1710984039937
[pi@rpi ~]0$ dbus-send --system --type=method_call --print-reply --dest="org.asamk.Signal" /org/asamk/Signal org.asamk.Signal.sendMessage string:MessageText array:string: string:<phoneNr>
method return time=1710984050.816249 sender=:1.3959 -> destination=:1.4057 serial=481 reply_serial=2
   int64 1710984049983

Dbus introspection also doesn't list a new parameter:

  <method name="sendNoteToSelfMessage" >
   <annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.Signal.Error.AttachmentInvalid" />
   <annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.Signal.Error.Failure" />
   <arg type="s" direction="in"/> // messageText
   <arg type="as" direction="in"/> // attachments
   <arg type="x" direction="out"/>
  </method>
  <method name="sendMessage" >
   <annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.Signal.Error.AttachmentInvalid" />
   <annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.Signal.Error.Failure" />
   <annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.Signal.Error.InvalidNumber" />
   <annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.Signal.Error.UntrustedIdentity" />
   <arg type="s" direction="in"/> // messageText
   <arg type="as" direction="in"/> // attachments
   <arg type="as" direction="in"/> // receiver list
   <arg type="x" direction="out"/>
  </method>
  <method name="sendMessage" >
   <annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.Signal.Error.AttachmentInvalid" />
   <annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.Signal.Error.Failure" />
   <annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.Signal.Error.InvalidNumber" />
   <annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.Signal.Error.UntrustedIdentity" />
   <arg type="s" direction="in"/> // messageText
   <arg type="as" direction="in"/> // attachments
   <arg type="s" direction="in"/> // receiver
   <arg type="x" direction="out"/>
  </method>

Running version signal-cli 0.13.1 so should be up to date, isn't it?