Configurable history retention limits for rooms

[ara4n]

there doesn't seem to be a riot bug to track the need to define a configurable retention limit for a room, as needed for compliance and other enterprise uses.

[uhoreg]

related to element-hq/element-web#3177

[lampholder]

I've P3'ed this for now; obviously this is a hard requirement for enterprise use so this will very likely become higher priority in the future.

[roadkillazpartybird]

An option to set the number of messages, or amount of days until messages 'expire' would be lovely.

At the moment Riot accumulates all chat history forever, which can be annoying and sometimes bad for privacy.

[aaronraimist]

This is pretty close to element-hq/element-web#3104 (but this has a few more 👍s)

[Perflyst]

Support for this was added in synapse with 1.7.0rc1

[4nd3r]

this is major blocker before many homeservers can rollout message retention.

room admins must be able to configure room retention straight from client and users must be able to see current retention policy.

please make it happen. who I have to pay to get this?

[michaelBenin]

Support for this was added in synapse with 1.7.0rc1

Is there documentation where to set this in the ui?

[t3chguy]

It has support in Synapse but no support in any UI yet.

[rubo77]

So how do you set it?

[t3chguy]

The Matrix API

[michaelBenin]

Users on the free matrix, can we set it there? Or would we need to host our own to set this?

[michaelBenin]

FTR I have a group coming from Keybase. Ever since they were bought by Zoom our groups are thinking about moving to Riot.

[michaelBenin]

The Matrix API

If you have time, could we get a link to the api docs where to set this?

[t3chguy]

@michaelBenin https://github.com/matrix-org/matrix-doc/blob/matthew/msc1763/proposals/1763-configurable-retention-periods.md#room-admin-specified-per-room-retention

[rubo77]

Is there an issue in riot already, to implement this retention setting there for room admins?

[t3chguy]

Yes. This one.

[catscratchedme]

Sorry if I'm misunderstanding something, I'm a layman user.

The doc that t3chguy linked says the following:

The above example means that servers receiving messages in this room should store the event for only 86400 seconds (1 day), as measured from that event's origin_server_ts, after which they MUST purge all references to that event (e.g. from their db and any in-memory queues).

We consciously do not redact the event, as we are trying to eliminate metadata and save disk space at the cost of deliberately discarding older messages from the DAG.

This seems to imply that that purging messages is different from redacting them. My understanding is that redacting a message asks the server to mark the message as redact, and then the server may either delete the encrypted message contents, or choose not to delete it. But the metadata is all retained.

It seems like purging a message would ask the server to delete all the metadata related to that message. I recall reading somewhere that matrix retained lots of metadata because deleting it would 'break the timeline,' and cause the room to break. Is this no longer true?

[t3chguy]

That's not a query for riot-web and you'll get a better response elsewhere

[progserega]

It very nice feature! 👍

[altsalt]

Related to matrix-org/synapse#6287

[kittykat]

Thank you, we appreciate that you took your time to file this enhancement request. I am going to close it for now in favour of a cross-platform issue to help us track the request more effectively. Please follow this issue for further updates: /issues/82

[pztrn]

There is still no possibility to configure retention per room via web, why closing? Self-destructing messages even sounds completely different with this issue.

[SimonBrandner]

There is still no possibility to configure retention per room via web, why closing? Self-destructing messages even sounds completely different with this issue.

Ah, you're right retention limit != self-destructing messages, I am assuming closing this issue was an accident. Thanks for letting us know

[mijutu]

It is possible to send custom events from developer tools of element web and set room retention time there. Something like: Right-click a room → Settings → Advanced → Open developer tools → Send custom event

type: m.room.retention
content: { "max_lifetime": 34560000002 }

Click the red "Event"-button and then send.

After sending, you can verify that the retention is set: Go back and choose room state and m.room.retention there. Or with sql: SELECT * FROM room_retention WHERE room_id='!...';

[MurzNN]

The problem is that Element can send this event, but will not follow it :( Only Synapse now actually follow this rule and delete expired events, but all Elements and other clients still store them in cache :( So we've got a strange situation when event is deleted on server, but still present on clients...

[SamiLehtinen]

Expired events also cause other annoying problems like this one: matrix-org/synapse#10787

[t3chguy]

This can now be supported via https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/msc1763/proposals/1763-configurable-retention-periods.md

[moan0s]

As retention currently causes bugs in existing installations and is important for some groups of people (companies, activists) I would really like to see this move forward.

[kittykat]

Moving this issue to discussions in Element meta as we need to make a cross platform decision on how to proceed 👍

[ER-EPR]

The current state of this retention function is 'supported by server but not clients'. Am I right?