Signal lets you set a default timer for disappearing messages. So whenever you start a new chat with someone, the default timer is automatically set for that chat. I think it would be great to include a similar feature in Delta Chat.
For Delta Chat I think the feature should work like this. After you scan a contact’s QR code, as soon as the encryption is established, both accounts should automatically send the timer preference to each other, then compare the timer preferences of both accounts and automatically set the timer for that chat to whichever timer is lower.
You’re right that Signal isn’t so clear about this, but I don’t think it’s necessary for Delta Chat to copy the exact implementation from another app anyway. I think it’s better to take inspiration from a good idea and implement it in a way that makes sense for Delta Chat users. That’s why I suggested selecting using the minimum of both timers, but this is something which can be discussed by the Delta Chat community.
We usually look at other messengers before implementing similar features to avoid reinventing the wheel and repeating common mistakes. E.g. for initial disappearing messages we looked into at least Wire, WhatsApp, Signal, Telegram, Wickr, Keybase and Briar because there are a lot of small details: some messengers start the timer when the message is sent, some when the message is received, some when the message is read, some when the message notification is dismissed, some have multiple types of timers etc. Also the name of the function was not settled yet back then as some messengers called it “self-deleting messages”, “timed messages”, “self-destruct timers” etc.
Tested in Molly, with Signal on the other side. Have set the default timer to 8 hours. At the top of the chat it was displaying “The disappearing message time will be set to 8 hours when you message them.”. Then I received a message from this contact and the timer was not set because the contact has no default timer. Then I deleted the chat and messaged - this resulted in setting a timer to 8 hours. The experiment cannot be reproduced because apparently deleting the chat just clears it. When I delete the chat, set another default timer and go to the “non-existing” chat, it displays 8 hours at the top, so technically the chat already exists and has a timer but has no messages and is hidden from the chatlist.
It seems Signal sets the default timer when one user has the default set and another does not, but it only happens once the user with the default sends a message.
WhatsApp seems to work a bit differently, apparently the timer is set to the minimum of the two timers even before you receive any messages from the contact. Maybe the timer is published on the user profile and the minimum is taken immediately. Anyway, WhatsApp is not open source and we cannot really look into its implementation other than doing many experiments, so it’s not that interesting.
I think it makes sense to look into Signal state machine more as it seems to compare the timers asynchronously without auto-replied messages that we want to avoid. Testing it as a blackbox is not so easy because the chats cannot be deleted.
Thanks for checking how this works in the different apps. I actually prefer how WhatsApp handles this, apart from the closed source implementation. I find it intuitive and makes sense to take the minimum of both timers. This respects the wishes of the person with higher security requirements, and it also means that if a new contact who does not use a timer scans your QR code, you don’t need to worry that the first messages they send you could remain permanently in the chat, assuming the new contact does not explicitly disable the timer. I see this as an important use case for default timers and it seems strange that Signal has neglected this use case.
I doubt that people change the default timer frequently. I suspect most people set it once and then leave it alone, so I still see possibilities for the app to compare the timers asynchronously without auto-replied messages.
For example, the timer preference could be included as a field in the QR code and vcard (if vcards support this). Then when someone scans a QR code or receives a vcard, the app can still compare the two timers locally and asynchronously without the need for auto-replied messages, by making the assumption that the new contacts’s default timer didn’t change since the QR code was scanned or the vcard was sent.
Another option would be to use auto-replied messages at the same time as doing the E2EE setup with secure join. Since the secure join uses auto-replied messages anyway, why not also exchange timer preferences at the same time?
If someone changes their default timer, this could be communicated to contacts similar to how avatar changes are communicated now.
I think this is being a bit overthought, it is much simpler than that:
groups: the chat’s disappearing messages timer should be set by the chat creator, not arbitrary people’s settings, when user creates a new group, they set their default timer,
DM chats: when someone is the first one to write to you, they set whatever timer preference they have, at that point they don’t know your preference, you can always change that manually if you think it makes sense to enforce your preference over theirs,
otherwise it always looks a bit impolite if an already set timer is changed by other peer after you already had one set,
more in a group if suddenly the timer is constantly changing because some peer had 5 weeks, then another 1 week, then another with 1 hour sends a message and change it for everyone, etc. and these timer logic is already a bit hard to synchronize,
I remember people accidentally disabling it or changing it because they sent a message without waiting for full sync etc
When you create a group in Signal on Android, the timer is set to your preference by default and you can decide on the timer at the same time as you select initial members. I also don’t think it makes sense to do anything more complicated than this. The difference between messengers is in 1:1 chat logic.
I have looked a bit at the logic of Signal. There is no comparison of timers. When outgoing message is sent in a 1:1 chat and there is no timer set, the sender applies its preference. Whoever sends the message first wins, even if their timer is larger.
In Signal Desktop timer is applied to outgoing message in 1:1 chats only and if the timer is not set yet:
No minimum is taken, just the timer of the sender is applied if no timer is set yet.
On Android the check is similar:
The timer is also not set in existing 1:1 chats when I send a new message even if universal timer is enabled on the sender side. This is probably ensured by the threadId check here:
At least this logic is somewhat simple, we can implement something similar by saying that the timer equals to “universal timer” value when if the chat is a 1:1 chat that does not have any messages yet other than some predefined info messages like “this chat is end to end encrypted …”.