-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Implement MSC2228 Self destructing messages #6287
Comments
I think this was done by #6409? |
this was only a partial implementation. Next step is for us to try to put an estimate on the remainder of the work. |
I had some thoughts over the past few days about finishing up the implementation of this MSC in Synapse (i.e. implementing synthetic redactions and support for This plan makes one major assumption, which IIRC is left as an implementation detail in the MSC, which is what to do with people joining the room before the event if the history visibility setting of the room isn't First, I think we should create a new table, let's name it
We'd also need another table, let's say
This list might be expanded to include whatever is necessary to generate a synthetic redaction. Then, each time we get a read receipt:
We would also need to introduce some changes in
The sync handler would also need to read from the This way when a user syncs, for each expired ephemeral message:
Additionally, we could also add a looping background process, which, for each ephemeral message would check the event has been seen by every user that was in the room when it was sent, in which case we could plan censoring it like we currently do with redactions, as well as removing its entry in |
sounds generally right to me! Some addtional thoughts:
@babolivier I'd suggest moving what you've written out to a google doc for now, so that we can comment on it and refine it. |
Good calls, thanks, I missed these points. I've copied all of this documentation and updated it in response to your comment on https://docs.google.com/document/d/1wWX514eG_a-KllsWD9v8Y36mV2pWnsGwqON8aPYk1-Y/edit# |
Many privacy chat apps like Signal support a feature which allow you to have messages delete itself. I think this can be useful feature in Matrix for a layer of privacy on your messages and chats. Here is how it can work. -Any user can create a self destructing message |
Hi, any update on this? |
Just wanted to say that this is a must. Especially being able to view ephemeral content ala 'Stories'. Even BBM had a feed. |
In WireApp it can be set on Room level or user can choose to destruct sooner. |
As a journalist we really need this for our security. Can a bot do it kind of securely in the meantime? Also is it possible to finance this features with a donation? |
+1 |
Since there seems to be little progress in this matter, we have developed a Matrix burn-bot that can at least handle the simple "Burn-After-TTL" strategy. |
As far as I understand it, with any application/standard that implements this, it is a very thin layer of security in which you must necessarily trust the user, said user's client, and said user's [home]server to have implemented such a functionality honestly, and there is no real way to verify or enforce deletion from the other end. Maybe in the not too distant future, verified reproducible builds can be coupled with key exchanges for something that gets partially there…but I don't really see how practical that could be when there could be any number of client implementations of the protocol. |
I don't care if I can't trust the client I'm talkimg to! My contacts can take screenshot if they want & I won't ever know! I just need a reliable way to destruct message I send & receive on my devices! |
Unfortunately what the bot does on the server side is not enough. If the clients are offline they will not receive the redaction event and thus not remove the message from their local store. Since redacting messages is idempotent a good thing would be to have some kind of self-destruction policy for the room that bot the server (or a bot) and the clients need to enforce. |
As well as at a room level, I'd be interested in a per-message implementation too. E.g., some messages are more sensitive than others, so when sending it, maybe an |
I've been thinking about more advanced features as well. The next things could still be TTL related and - as you suggested - allow users to define a TTL for their own messages. |
MSC2228 (which is the topic of this issue) is specifically about message-level TTLs. For room-level retention policies you want MSC1763 (which MSC2228 is a subset of, and was turned into its own MSC to optimise scope), which is already partly implemented in Synapse (but currently lacks client support, at least as far as I'm aware): https://matrix-org.github.io/synapse/latest/message_retention_policies.html |
matrix-org/matrix-spec-proposals#2228
The text was updated successfully, but these errors were encountered: