You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an alternative to #939 (which probably will not be implemented shortly), I am building a custom wrapper to queue and retry messages when there is no connection possible to the Signal servers. However, messages that live in the queue for a while will have a misleading timestamp, as it will use the timestamp generated during the successful send call, not the original timestamp when the message was originally put in the queue.
To solve this, it possible to add a custom --message-timestamp option to the send command (and JSON-RPC interface)? This will make it possible to specify the original timestamp.
The text was updated successfully, but these errors were encountered:
As an alternative to #939 (which probably will not be implemented shortly), I am building a custom wrapper to queue and retry messages when there is no connection possible to the Signal servers. However, messages that live in the queue for a while will have a misleading timestamp, as it will use the timestamp generated during the successful send call, not the original timestamp when the message was originally put in the queue.
To solve this, it possible to add a custom
--message-timestamp
option to the send command (and JSON-RPC interface)? This will make it possible to specify the original timestamp.The text was updated successfully, but these errors were encountered: