4

Implement Time To Live (TTL) for messages in API

This request appears similar but not identical to other requests such as https://joaoapps.helprace.com/i574-automatic-timeout-for-join-send-push-tasker-action and https://joaoapps.helprace.com/i559-add-timeout-to-api-flags (my request is about Join's usage of google FCM protocol, whereas those other requests seem to be about Join's usage of Android notifications).

Most messages I get join to send to my phone are meant to be realtime.  If a message didn't get through because the phone lacked reception, then I might as well drop the message immediately.  Some other messages I send might have a lifetime of 10 minutes before they lose meaningfulness (my server will want to send an updated state anyway).  But join specifies a default Time To Live (TTL) that seems to be weeks in length, and I can sometimes see that in the number of unhandled Android notifications piling up.

As per Google's FCM api documentation:

https://firebase.google.com/docs/cloud-messaging/concept-options

"Another advantage of specifying the lifespan of a message is that FCM never throttles messages with a time-to-live value of 0 seconds. In other words, FCM guarantees best effort for messages that must be delivered "now or never." Keep in mind that a time_to_live value of 0 means messages that can't be delivered immediately are discarded. However, because such messages are never stored, this provides the best latency for sending notification messages."

Messages may be greatly throttled (once per 9 minutes) if the user asks Join to send messages frequently enough to the phone.

So I'd benefit twice by being able to set my own TTL - for those messages that were meant to be either realtime or ignored, I'd set a TTL of 0.  I have a feeling autoremote used to implement this with the old Google Cloud Messaging.

Follow

1 reply

Votes Newest Oldest
S

I believe my request is on the same as above for the most part but in laymans terms.

Occasionally my conversations get held hostage because Join for Chrome is not able to send my remote SMS messages immediately (sometimes for 10 minutes or more). I am left with the choice of leaving the conversation on hold or continuing it on another device but knowing that all the unsent remote SMS messages are going to get sent out later at some random time. Both options are undesirable.

If it is possible to have remote SMS messages be "now or never" that would be excellent. Or at the very least a 'cancel' option would be very helpful.

Comment
Reply