[Enhancement] Treat nhtMessageUpdate as updates to the client's message database instead of new messages about airmessage-android

[tagavari]

Hello, thank you for opening this issue.

I can sort of see where you're coming from, though if you don't mind me asking, what's wrong with using nhtModifierUpdate? There are 2 major reasons that AirMessage keeps separate events for new messages and message updates:

• It's more in line with what macOS offers in the Messages database.
  Events like tapbacks and stickers are all recorded as new database entries and don't touch the original message.
• The changes that were made are more obvious to the client, and it saves on sending unnecessary data.
  This way, clients don't need to compare the received message to the original one, and can take action immediately. This is important for clients that may not even have the required data in the first place, like AirMessage for web.

Is there a specific reason you're trying to approach message updates from this angle? If it has something to do with the messages structure on iOS, I may be able to help you come up with an alternative.

[SixDigitCode]

Thanks for your response! iOS handles tapbacks as separate messages as well, so it's pretty straightforward to identify orphaned tapbacks (tapbacks that don't have associated messages from the requested time interval) and send them to the client via nhtModifierUpdate.

My main reason for wondering about this is to add a little redundancy for the messages sent to the client. Maybe I'm a little paranoid, but I worry that messages could get lost in some cases if if the server only sends them once. Sometimes sent messages show up twice for me, so if the server sent a few extra redundant messages and the client tracked them by IDs, that should (in theory) help.

It would be useful for flexibility, as when the client sends a message, they could get the most recent 10 messages back in order to sort out any duplicates/missing messages.

If this introduces too much complexity or doesn't make a lot of sense for the server, don't worry about it. I just thought it might make AirMessage a little more stable.