Pretty sure the original account id is still tied to the message and sent to clients even after deletion. People can easily correlate it if they can prove just one of the messages belonged to you.
The standard fix to this is to give each message a GUID, and then when you delete a message, instead of deleting it, your store a tombstone with the GUID, and that prevents a network re-send from causing the message to reappear.
> Basically, all messages in a mailbox are numbered from 1 to N, and you can reference a message by number, and when a message is deleted all message numbers above it shift down by one.
There is no reason technical why this shifting has to happen. If there are ten messages on session creation, and message UID 3 is deleted, you then have UIDs 1-2,4-10.
If the server wishes to shift messages over it can, but it must bump UIDVALIDITY, which tells clients that there is a 'new generation' of UIDs for the given folder. But as long as the server's index of UID-to-message is not lost, there's no reason why renumbering has to occur.
It's no different than having an AUTO_INCREMENT int column in MySQL: you just keep going up without bothering to fill in any 'holes'.
That said, folders and messages can now be assigned UUIDs:
In terms of manual de-duping, we strive internally for idempotent message processing so it's fairly irrelevant, but to handle cases where it matters, all of our messages have unique id's added to them outside of NSQ.
The actual cases where messages are handled multiple times is limited to when a client disappeared during message processing (a hard restart) or it passed the allowable time window to respond and was given to another client.
If there are any specific numbers you are curious about, please ask.
You can use a database. Practically, most systems will keep a record of each message on disk in any case (at least they will have some logs) so it's not that outrageous. Safe to assume that the receiver can discard non-authenticated messages to avoid spam.
Doubtful that they are seeing the old conversations, but people with the old phone numbers can send new messages to the new account with this phone number, continuing an old conversation.
Are the messages stored on your own servers or on the users' own devices?
If they're on your servers, it should not be necessary to keep multiple copies of the same message. You could make it so that if the sender deletes a message, it is removed from the database and becomes inaccessible to recipients.
If the messages are stored on users' own devices and not on your own servers, then that is a different situation and is more like email.
This is a real headache. You can either send all the messages (and info/queries) to all logged-in devices, or you select just the most recently used. In the first case, the user gets messages repeated. In the latter, there's the risk that information is lost when a user switches device.
reply