airmessage
[Enhancement] Treat nhtMessageUpdate as updates to the client's message database instead of new messages
I may be overlooking something (if I did, sorry), but would it be possible to treat the data from nhtMessageUpdate as an update to the AirMessage client's database, similar to a mass retrieval? I think that would help solve some issues and make AirMessage overall more stable.
As it stands now (as far as I can tell), anything the client receives via nhtMessageUpdate is assumed to be new. So, if the server sends messages (via nhtMessageUpdate) that the client has already seen, the client will still add them to the end of the conversation.
Would it be possible to change this so each message in the database is updated, similar to a mass retrieval? (i.e. if the server tells the client about a message the client already knows about, the client simply updates the message instead of adding it to the list again?) Each message GUID appears to be unique (so I assume it's relatively easy to update the database), but I'm not sure if there are any weird barriers that prevent this from happening.
That way, there wouldn't need to be another message type for nhtModifierUpdate, as the server could simply re-send a message via nhtMessageUpdate if the tapbacks change. This could also help if Apple introduces other iMessage features in the future, such as editable messages.
This could also help with stability. If the client sends a message to a conversation, the server could return the last 10 messages from the conversation, including the sent one. That could help cut down on strange sending bugs as the client would get a lot more messages and that would help fill any gaps in the client's database.
Again, apologies if I misunderstood the situation. Please let me know if you have any questions. Thanks!
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.
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.