Message persistence on demand

[jrmi]

I don't want to get into a war between Whatsapp vs. Signal vs. Telegram vs. Slack vs... but who gets all their contacts on the same tool? I don't want to create an account on all these platforms to be able to communicate with everyone. And what if I want to create a temporary group with customers for example. Do they all have to create an account on a common tool for a few months?

To my knowledge, there is no chatroom yet that

• does not require an account or phone number,
• which is easily shared via a link,
• whose messages are e2e encrypted,
• which displays desktop notifications,
• which is open source and may be installed on multiple servers,
• which allows you to retrieve messages that were sent while he was away because I'm not always in front of my computer when one of my contacts wants to talk to me.

With such a solution, I no longer need to make a choice. Not to mention the fact that I have to install a utility or that uses the phone number or the email. Yes I know my issue looks like that but eh, we are developers ;-)

In order for Darkwire to answer all these points, the last point is mainly missing, i.e. the possibility to receive the messages that were sent during my absence. I don't want to keep an ad vitam history of the messages, but just the last messages I didn't receive (within a month for example).
The idea is not to put an end to the ephemeral aspect of this chat but to complete it with a slightly longer term use. As long as you use it regularly, it stays alive. Messages are erased as they get older and if nobody uses the room for a while, it is totally deleted. This would be an option to be activated by the owner of the room if needed.

To meet this need I propose 3 technical solutions:

Option 1

The first idea is to use symmetrical AES-type encryption to encrypt messages. When you choose to enable persistence, a hash is added to the URL containing a passphrase to encrypt and decrypt messages. Each time a message is sent, it is stored encrypted in the store on the backend side and the messages are all sent back to each user who logs in. Only users with the correct hash in the url will be able to decrypt the messages.

Pros

• Simple to implement
• You have the URL, you have the history that goes with it.

Cons

• The security of symmetrical encryption is significantly lower than asymmetrical encryption. The user should be warned that when he makes this choice, he decreases his security level compared to symmetrical encryption.

Option 2

With this option, the server keeps a list of users who logged in with their public key. When someone logs in, they receive a list of all users, even those who are not logged in anymore for this room. Each message are sent to the server encrypted with the public key of each recipients, like now, but messages whose recipient is not logged in are kept on the server until the user concerned logs in or until the message expires.

Pros

• Maintains the same level of security
• Easier to implement

Cons

• Risk of keeping a lot of unnecessary messages if some users were only present at one time.
• The history cannot be retrieved before a user's first connection since messages were not transmitted to him. We can imagine a fallback based on the re-transmission of the owner's messages in this case.

Option 3

This time, the first user in a room creates two encryption key pairs at the first connection. One for him as usual and one for messages. Then, for each user who logs in, the room owner sends the key messages encrypted with the user's public key (like a normal message in fact). The difference is that each time a message is sent, it is encrypted with the public key of the message and is sent only once. The message history is therefore kept only once on the server side and the encryption method remains asymmetrical. We can even imagine that is the default way of exchanging messages.

Pros

• Same level of security as today (maybe even better? because the same message is encrypted only once which could limit statistical attacks from a compromised server? I don't know).
• No extra storage cost depending on the number of users

Cons

• Intermediate complexity
• It is mandatory that a user with the message key must be present so that a new person can connect, but we can imagine to put this new user on hold while waiting for an owner with the message key.

---

What do you think? Did I miss an option?

[jrmi]

@alanfriedman @seripap do you have any preference about the options ?

[seripap]

If we were to add any persistence, i'd probably go option #1 and use the current redis implementation.

I would be hesitant on implementing any other type of long term persistence that requires another database.

[jrmi]

I don't think there is a difference about the way data are stored server side, I think all three options can use the redis implementation. May be I'm missing something ?

[seripap]

chat data isn't stored in the current implementation. the server acts like a mailman, sending data between clients. all messages are encrypted on the client then transmitted via server to clients that are currently connected in the room. any new user that enters, the previous message would not exist as the only trace of the message is on previously connected clients.

[jrmi]

And that's exactly the purpose of this ticket, adding a persistence server side on demand. I mean, in my previous message, that all three future implementations can use the same data store for the new persistence functionality, i.e. Redis