Description
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:
typedef void tox_friend_message_pending_cb(Tox *tox, uint32_t friend_number, Tox_Message_Type type, uint32_t message_id, const uint8_t *message, size_t length, void *user_data);
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.
void tox_friend_message_confirm(Tox *tox, uint32_t friend_number, uint32_t message_id, Tox_err_message_confirm *error);
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.