You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Delete file attachments if message is removed.:
In some cases, such as direct messages, a user may want to send an image file or other attachment privately.
After deleting the message in Matrix, the client no longer shows the image/file and says "Message deleted", however the image server link (/_matrix/media/v1/download/....) remains available.
This becomes very obvious in a situation such as when I send a message to a bridge, and the whole media server link is readily available. Removing this file once posted seems impossible in the current implementation.
It would both save server disk space, and enable better privacy, if the file could be deleted when the message is removed. At the very least, removing access through the API makes sense, especially in case the user dragged a sensitive file into their client by accident.
The text was updated successfully, but these errors were encountered:
When I say "message is removed" I mean I click the "..." menu in Element and I click "Remove". Then the message says "Message Removed". If the technical term in the protocol for this is "redacting" the message, then yes that is what I mean, you may be correct this is a duplicate of #1263.
Delete file attachments if message is removed.:
In some cases, such as direct messages, a user may want to send an image file or other attachment privately.
After deleting the message in Matrix, the client no longer shows the image/file and says "Message deleted", however the image server link (/_matrix/media/v1/download/....) remains available.
This becomes very obvious in a situation such as when I send a message to a bridge, and the whole media server link is readily available. Removing this file once posted seems impossible in the current implementation.
It would both save server disk space, and enable better privacy, if the file could be deleted when the message is removed. At the very least, removing access through the API makes sense, especially in case the user dragged a sensitive file into their client by accident.
The text was updated successfully, but these errors were encountered: