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
Currently an application cannot control when read receipts are sent back to a friend.
This is a problem if a client crashes after a read receipt is sent back but before some messages are saved to the client history. It also prevents Toxcore from reliably implementing componentized clients that isolate the core from history and frontend, because if the core receives messages while the the history component is not active, the messages would be dropped but the sender would still see a confirmation. I have a minimalist client that I am working on that has this problem.
The solution to me would be to add a message callback type that receives a message id:
the name "read receipt" is a misnomer. https://github.com/TokTok/c-toxcore/blob/master/toxcore/tox.h#L1825
it actually means that the message callback was called on the receivers toxcore and the callback returned.
so the name should be more like "message received" rather than "message read"
this still causes issues since most modern clients do things asynchronously.
there is a fix for this issue for 1:1 text messaging called msgV3
you can see the patch here:
Currently an application cannot control when read receipts are sent back to a friend.
This is a problem if a client crashes after a read receipt is sent back but before some messages are saved to the client history. It also prevents Toxcore from reliably implementing componentized clients that isolate the core from history and frontend, because if the core receives messages while the the history component is not active, the messages would be dropped but the sender would still see a confirmation. I have a minimalist client that I am working on that has this problem.
The solution to me would be to add a message callback type that receives a message id:
And a procedure to confirm the message when the application has processed it. This could be called during the message callback or at a later time.
The read receipt behavior could be selected by which friend message callback type was set, or as an option to
tox_new
.I'm willing to implement this if the proposal is acceptable.
The text was updated successfully, but these errors were encountered: