Implement disappearing / ephemeral messages

[taoeffect]

Problem

Once messages are sent in a chatroom contract, they're kinda there forever, even if they're "deleted".

It would be better if there was at least an option to send a message that could be really deleted.

Solution

Create a new type of message under MESSAGE_TYPES, to allow for ephemeral messages, where the contents are stored as a separate file attachment that can be deleted (EDT: @corrideat also suggests the idea of using the KV store instead, which could also work). See related issue #1827 for storing auto-deleting attachments (that needs to be closed first).

Then update the UI to support these new message types and implement them. If designs for ephemeral messages aren't ready, then just implement the feature, but don't hook it up to the UI - or make it a simple thing like an icon (💣) next to the input field that gets toggled, and when messages are sent with this icon enabled, they are sent as ephemeral message types. And when ephemeral message types are deleted, the underlying message (in its separate file form) gets deleted.

EDIT: The kind of UI I see for this is basically a dropdown with the 💣 icon that shows these options:

• 💣 (on delete)
• 💣 1hr
• 💣 6hr
• 💣 1d
• 💣 3d
• 💣 1w
• 💣 1m
• 💣 4m

And the UI would look something like this:

[ 💣 ][ (on delete) v ]

Where the [ 💣 ] is toggleble on/off (blue background highlight when on), and the dropdown is next to it which sets the setting.

[corrideat]

I've been looking into this issue and think that going with files (as originally proposed) instead of KV (as I later suggested) is probably the simplest and most flexible solution (ETA: *).

However, something that this issue doesn't take into account is that merely deleting files may not be sufficient for a 'disappearing' feature, if copies of the file still exist. Similarly, because CIDs are used, even a 'deleted' message has some on-chain information about the file that was stored.

One way to address these issues is implementing something like the X3DH protocol for disappearing messages. Signal also has the 'double ratchet' protocol after a key is established, but we probably don't need this if we run the X3DH protocol for each message.

X3DH would require some additional keys (the 3 in the name alludes to a triple DH agreement), which could be stored in the KV store. The main advantages of using something like X3DH is that it's a solid and industry-standard protocol and that it provides the kind of assurances one would expect about disappearing messages, such as forward-secrecy. I still need to look up how X3DH works for group chats.

ETA: (*) Three reasons come to mind. KV store doesn't solve the issue of 'ephemeral' messages that have attachments, so files would still need to be used, even if as a fallback. Managing one-off KV store keys sounds complicated. Files are static while KV can be changed, which can be confusing.