Every time I see that, I’m floored by it. The fact that message IDs in IMAP change when you delete messages has got to be one of the worst design choices in any in-use protocol. I’m flabbergasted by it.
> 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:
Wow thanks for clarifying. That is absolutely deceptive. The UI never mentions that, but I found some support docs that do. I imagine the majority of people deleting messages aren't aware of this...
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.
>If you delete a message, it's deleted from all your devices immediately, and it's gone forever. Delete an entire conversation? Gone forever.
This is expected behavior on 2-way sync. Presumably backups made before the message was deleted will still have the message but will delete it out once network connectivity is restored.
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.
The deletion would be removing your user data but not past messages, like how current deletion work. Past messages get a new user ID shared amongst all deleted messages globally - 456226577798135808 - but attachments and content stays.
> I want to give you as much time as possible to download your data and migrate to a new server.
Does it mean you can download your messages and put them back in the global conversation ? How does that work ? Are those messages stored only on one instance ? Do they disappear forever when an instance disappears ? Will users switch to new identity from another instance and import messages or is this lost ?
Right, I'm not familiar with their data model or even features, since I don't use it, but bottom line is that users are probably not in control of the data, and what you see in the app is just a client app reconstruction based on your actions and preferences. It sounds that's what you're alluding to.
> but if they "actually delete it"--which I imagine you want--then they might also forget any unique identifier stored with the message, which likely makes it hard to know that this message was both already received and deleted in the past.
I would expect any messaging app to work like email, where you're also in control of the email server. Once you receive someone else's message, it's in your inbox, and you can delete it forever as well. The email message model is more intuitive, and I would love for modern instant messaging clients to work the same way except in real time. Of course when you have that level of control, you would need to make it paywalled or subscription of some kind.
> Those messages will age out and vanish after a little while (14 days is currently the max); but before they go, they’re stored carefully and are very unlikely to go missing
can somebody expand on this? I know about the 14 days limitation but this makes it sound like you can store messages for a long time and still recover them somehow?
That's interesting, thanks for the tip. I would hope they would have a sort of garbage collection that deletes orphaned messages, but this is Discord we're talking about.
IDs can also change between sessions, and can be different between simultaneous sessions.
reply