Introduction

I am a HUGE fan of matrix. It allows me to organize my chats in a sensible way, it works with multiple identities and completly anonymous if I want it to. Spaces made Matrix my favourite messenger by far. Yet, there is one feature I have been missing: Disappearing messages!

Regarding the security and usability, only Signal is comparable to matrix. But: Signal offers the possibilty to define disappearing messages for groups and direct messages ranging from 30 seconds to 4 weeks. No Matrix client (to my knowledge) offers this functionality. Nevertheless, it is possible to configure matrix rooms to have the same feature. This needs a special server configuration and the sending of a special event in the room. This post tries to show both steps. If you do not administer a server you can probably skip to Room configuration

Be aware that this blogpost was written at the end of 2021 - Matrix develops fast and this could be subejct to changes.

Instance configuration

To make disappearing messages possible you need to enable retention on your matrix instance. Retention allows server and room admins to configure how long messages should be kept in the instances database before being purged from it. It is not part of the matrix specification, yet it is supported by synapse.

A client SHOULD not display these messages anymore after the max_lifetime is exceeded. This was NOT true for element web an desktop while staying logged in. Nevertheless, a newly logged in client did not have access to the messages.

To configure Synapse to make use of retention you will need to enable it in your homeserver.yaml

retention:
  enabled: true # enables the retention, is enough to enforce it once per day
  purge_jobs: 	# configures a job that delete the events from the database after some tome
    - longest_max_lifetime: 3d
      interval: 1h
    - shortest_max_lifetime: 3d
      interval: 1d

The example configuration creates two jobs that delete messages from the database. One only focuses on events that should be deleted after three days or less. These events will be deleted every hour. It is therefore possible for a message that was send in a room with a max_lifetime=7200000 (equals 2h) to be deleted one hour after the maximum lifetime.

Ansible

If you use the Ansible/Docker setup to deploy your server you can add the following to inventory/host_vars/matrix.example.com/vars.yml

matrix_synapse_configuration_extension_yaml: |
  retention:
    enabled: true
    purge_jobs:
      - longest_max_lifetime: 1d
        interval: 2h
      - shortest_max_lifetime: 1d
        interval: 1d

Room configuration

If you are a user on a server that has retention enabled, you can enable disappearing messages yourself for each room. Sadly, this is still experimental - but managable! You have to craft a m.room.retention event that defines the maximum lifetime of a message. You will need to access the rooms settings in order to do this.

First you need to open the developer tools in the rooms settings.

Then click "Send custom event" to create your event

And fill the event with the appropriate max_liftime. The time is an integer in milliseconds. X hours is therefore a value of X*3 600 000. Make sure to click the red event button. The State Key can be left empty nevertheless.

Depending on your choosen lifetime the client should not show the messages anymore.

Limitations

The process of deleting messages can not be enforced. A malicious server or chat partner could ignore the request to delete the messages or they could have saved them elsewere. You should not rely on a deletion actually happening. Nevertheless I think this is a good step to take to improve your security in real life.

Further Information

Relevant part of the Synapse configuration file: https://github.com/matrix-org/synapse/blob/v1.36.0/docs/sample_config.yaml#L451-L518
Synapse documenation on message retention policies https://matrix-org.github.io/synapse/v1.41/message_retention_policies.html

What else?

Thanks to Tastytea for helping me get this to work!

Comments

If you have questions, corrections or want to leave something else, please feel free to use the comments!

5.3 KiB Raw Blame History