I'm keeping track of a `last_received` and a `last_read` timestamp on the chats for each of the bros in a broup, the distinction is there because you can receive it but not yet read it yet. 
If you and all the other bros in the broup have received a message it can be removed. The receive time for each bro is updated if the broup is opened and the messages are retrieved or if the app is open when the message is received. This seemed like a nice solution to find out which message still needs to be read and which can be removed from the server. It can already be removed if it has been received but is only read after the read timestamp is updated. However I don't think keeping track and comparing timestamps in the backend is the way to go.
The main catalyst for my thinking now is that I seem to have seen a situation where a message was send but it was not retrieved on my client. But messages afterwards were received. This might be an issue with how the phone handles the socket connection and API calls when the app minimizes or pauses and then returns again. It might send a read update even though a new message was send and not yet retrieved.
I'm thinking of just adding a receive_remaining id list on each message for every bro that still needs to receive it. If the list is empty the message can be removed. This makes it much more clear who still needs to retrieve a message and leaves no room for errors. You can only be removed from the id list if you have retrieved the message. Also, on each of the broup objects it keeps track of the last message id that that bro has read and on the chat object it keeps track of the lowest last message read id. If that id is updated, than a  message indicator is send along with the latest id. On the client it can update all the messages with that id or lower to be read.
Instead of relying on timestamps it relies on remaining ids and current read message ids which are a lot clearer and unambiguous.