| 15 Feb 2024 |
 xekoukou | More or less, the users of the room will enter into a form of concensus (which i havent figured yet), they will determine the next state and all previous msgs need not exist. | 11:04:32 |
| xekoukou | Does reduction delete the msgs or are theyt still in the server? | 11:04:54 |
 cos | Servers usually store the messages for a week or so, to prevent abuse (send abuse and redact it before admins notice) | 11:05:29 |
| cos | But eventually redacted message content is deleted (assuming normal servers, there's no way to guarantee it) | 11:06:03 |
| cos | You can run modified matrix server that never deletes anything, there's no way to prevent that | 11:06:46 |
| xekoukou | Mostly, i wonder of what is considered normal use, I will use a lot of ephemeral msgs, that need to be retained till most of the users enter into a consensus, thus about a few days, I suppose. | 11:08:28 |
 Timo K. | What is the reason to delete the messages. Deleting is a very hypathetical concept in the digital world.
The clients will have had the message at some point and from that point on its on their own to delete or keep them. If I have setup my phone or computer to do regular backups of my application data directory I of course will have the message forever.
To put it into simple words: Once someone saw data you always have to go with the assumption that this person still knows about it.
(It could be that the person just took a pen and noted down what was in the message)
What is a much more solid concept is encryption. If I sent a message into a room and I only want a subset of ppl to be able to read the content and ppl who join the room in the future should not be able to read it i can encrypt it and only share the key with a subset.
If its just about storage optimization then redaction is exactly what you want. Its basically telling all participating instances that they dont need to continue to store the data. | 11:35:34 |
| Timo K. | * What is the reason to delete the messages. Deleting is a very hypothetical concept in the digital world.
The clients will have had the message at some point and from that point on its on their own to delete or keep them. If I have setup my phone or computer to do regular backups of my application data directory I of course will have the message forever.
To put it into simple words: Once someone saw data you always have to go with the assumption that this person still knows about it.
(It could be that the person just took a pen and noted down what was in the message)
What is a much more solid concept is encryption. If I sent a message into a room and I only want a subset of ppl to be able to read the content and ppl who join the room in the future should not be able to read it i can encrypt it and only share the key with a subset.
If its just about storage optimization then redaction is exactly what you want. Its basically telling all participating instances that they dont need to continue to store the data. | 11:36:08 |
| Timo K. | Actual ephemeral data that is not stored in the dag can be sent via toDevice messages | 11:36:54 |
| cos | That's why it's called redaction, not deletion. Deletion cannot be guaranteed in decentralized world. | 11:37:36 |
| Timo K. | To not make decentralized systems look bad:
One can also argue that calling sth deleting is always a scam. Also in a system like telegram or whatsapp there is nothing hindering me to store all messages in a room (for instance with a matrix bridge or just taking screenshots form my phone where the room meessages are shown)
If someone deletes a message they have the claim that the whatsapp servers will delete it but my copy of it is still in my control.
The same can be said about matrix. If I control/trust the my homeserver as I trust the whatsappservers the message will be deletef from that server. But all the other participants can still do whatever they want and keep archives/backups however long they want.
Independent on the technology you will end up with the fundamental setup that If you dont keep information to yourself the only thing that is stopping this information get spread into the world is the good will of the people you gave that information. | 11:46:11 |
| cos | True | 11:58:11 |
 rako | It doesn't sound like @xekoukou is worried of sensitive information being kept after deletion, it's more about efficiency: old messages are useless, so they might as well be deleted to save space. | 12:07:42 |
| rako | I don't think Matrix is the best tool here. Matrix is built to synchronize everything everywhere all the time, deletion is an afterthought. A much better/simpler system is XMPP or, yes, email. | 12:08:42 |
| rako | If users share an IMAP account on a specific folder, IMAP has everything to make it a pubsub queue with easy deletion of old events | 12:10:53 |
| Timo K. | (or ToDevice messages if any of the other features of matrix are benefitial: encryption authentication via oidc, device verification, matrixRTC) | 12:11:18 |
|  @petrichor:envs.net left the room. | 13:00:28 |
|  Bari_51 changed their display name from Bari_51 to 🇩🇿Bari🇵🇸ALi🇩🇿. | 23:13:14 |
| 1 Mar 2024 |
|  Yan changed their display name from Yan to Yan (ooo until 6th march). | 07:54:04 |
|  Milton Moura joined the room. | 15:49:11 |
|  Denise [away] changed their display name from Denise to Denise (away). | 17:27:19 |
| 4 Mar 2024 |
|  nutcracker500 joined the room. | 05:02:12 |
| 5 Mar 2024 |
| Denise [away] changed their display name from Denise (away) to Denise. | 11:16:22 |
|  Andrew Morgan (anoa) changed their display name from Andrew Morgan (anoa) to Andrew Morgan (anoa). | 14:31:02 |
| 6 Mar 2024 |
| Yan changed their display name from Yan (ooo until 6th march) to Yan. | 13:22:44 |
|  @tandy1000:matrix.org left the room. | 13:39:45 |
| 7 Mar 2024 |
| Bari_51 changed their display name from 🇩🇿Bari🇵🇸ALi🇩🇿 to Bari_51. | 08:43:13 |
| 8 Mar 2024 |
|  stonedpony420 joined the room. | 12:51:00 |
| 14 Mar 2024 |
|  Davide changed their display name from Davide to Davide[away]. | 15:10:44 |
| 19 Mar 2024 |
| Davide changed their display name from Davide[away] to Davide. | 07:16:57 |
