!!Currently this patch is only a draft following our meetings!!
Note: Following notes are not organized yet. Just some line of thoughts.
For a serious group chat feature, we also need serious crypto. With the current design, if a certificate is stolen as the previous DHT values of a conversation, the conversation can be decrypted. Maybe we need to go to something like Double ratchet.
Note: a lib might exists to implement group conversations. TODO, investigate.
Needs ECC support in OpenDHT
There is two major use case for group chats:
Something like a Mattermost in a company, with private channels, and some roles (admin/spectator/bot/etc) or for educations (where only a few are active).
Horizontal conversations like a conversation between friends.
Ring will be for which one?
A certificate for a group which sign user with a flag for a role. Adding or revoking can also be done.
Join a conversation
Only via a direct invite
Via a link/QR Code/whatever
Via a room name? (a hash on the DHT)
What we need
Confidentiality: members outside of the group chat should not be able to read messages in the group
Forward secrecy: if any key from the group os compromised, previous messages should remain confidential (as much as possible)
Message ordering: There is a need to have messages in the right order
Synchronization: There is also a need to be sure to have all messages at soon as possible.
Persistence: Actually, a message on the DHT lives only 10 minutes. Because it's the best timing calculated for this kind of DHT. To persist datas, the node must re-put the value on the DHT every 10 minutes. Another way to do when the node is offline is to let nodes re-put the data. But, if after 10 minutes, 8 nodes are still here, they will do 64 requests (and it's exponential). The current way to avoid spamming for that is queries. This will still do 64 requests but limit the max redundency to 8 nodes.
Other distributed ways
IPFS: Need some investigation
BitMessage: Need some investigation
Maidsafe: Need some investigation
Based on current work we have
Groups chat can be based on the same work we already have for multi devices (but here, with a group certificate). Problems to solve:
History sync. This need to move the database from the client into the daemon.
If nobody is connected, the synchronization can't be done, and the person will never see the conversation