Skip to content

Customize Rageshake Server

The so called rageshake server is used to collect debug logs from the client applications, both web and mobile, to make it easier for the Element team to resolve technical issues reported by the end users. Note that debug logs are not sent proactively by the clients, only when a user is reporting an issue and agrees to share the debug logs.

By default the debug logs are sent to the rageshake server run by Element. Logs are designed to not contain any truly private data such as message content or private keys. However, they do contain metadata such as user, room and event IDs. Thus, there are cases where it may be necessary to make sure that such logs are never sent to Element (for example, due to compliance reasons). Also, in an air-gapped network, Element's rageshake server is not reachable.

In such a case, one can set up their own rageshake server and send the logs in there (manually sharing them with Element on a need to have basis), or disable sending the logs. Note that the rageshake server is not a product of Element and not included in ESS. It is available at matrix-org/rageshake as an open source software.

Due to the platform differences, the means to customizing the rageshake server are different for web and mobile clients.

Web

For Element Web & Desktop, the configuration is installation-based, e.g. when the organization example.com deploys Element Web for their users on https://element.example.com, they can configure this installation to use a specific rageshake server with the bug_report_endpoint_url configuration option or disable sending logs, by removing the configuration option.

For how to apply these configuration options to Element Web via ESS, please see the snippet below or configuring Element Web using the example fragment at charts/matrix-stack/ci/fragments/custom-rageshake-server.yaml.

elementWeb:
  additional:
    custom-rageshake-server.json: |
      {
        "bug_report_endpoint_url": "https://rs.example.com"
      }
  • For details about Element Web & Desktop configuration options as such regarding the rageshake server, see Element Web config documentation.
  • For how to apply these configuration options to Element Desktop, please see configuring Element Desktop.

Installation-based configuration means that regardless of which account provider (server) the user logs in to, the logs will always be sent to the same rageshake server. In practice, that is unlikely to make a difference, because people using the https://element.example.com installation, are typically only using example.com as their account provider.

Mobile

Like web, mobile has an installation-based configuration option available, too. However, this assumes the organization example.com publishes their own custom mobile apps in the app stores (with rageshake server being hardcoded into that app) which isn't the case for all organizations. Therefore, the Element Pro mobile app supports a dynamic configuration, read from the example.com server when a user logs in to it.

This dynamic configuration is made available to the mobile client using the Well Known URIs method. In the ESS deployment, the necessary values are injected to the well-known by configuring the well-known delegation "component":

wellKnownDelegation:
  additional:
    element: |
      {
        "rageshake_url": "https://rs.example.com",
        "enforce_element_pro": true
      }

In the example above, the rageshake server is set to https://rs.example.com. Alternatively, to disable sending logs set the value of the rageshake_url to an empty string, e.g. "".

As the rageshake server URL only takes only effect when using the Element Pro app, it is advised also to enforce the usage of the Element Pro for the example.com users. That's why the enforce_element_pro configuration option is set to true above.

The example fragment in charts/matrix-stack/ci/fragments/custom-rageshake-server.yaml covers both web and mobile and the URL should be updated in both locations in that fragment.