feature: Implement MSC4373 (Server EDU type opt-out) #1135

New issue

Open

opened 2025-10-23 03:01:58 +00:00 by nex · 0 comments

nex commented

2025-10-23 03:01:58 +00:00

Owner

https://github.com/matrix-org/matrix-spec-proposals/pull/4373 (rendered)

This proposal allows us to cut down on bandwidth by both finding out what EDUs to not send to servers, and also tell other servers what we don't want to receive. This will also help with CPU and memory usage since we can simply avoid wasting time sending data to other servers or receiving it when the recipient simply doesn't care about the data and will just discard it anyway.

Returning our accepted EDU types should be pretty easy considering we already have config options for inbound EDUs like typing and presence:

#allow_incoming_typing = true

#allow_incoming_presence = true

All that would need is a ruwuma update to introduce the response body structure.

Filtering outgoing EDUs probably wouldn't be too much difficult. A database cache probably wouldn't be needed for this, an in-memory cached filled in by requesting the destination's EDU filter before sending the first transaction tagged with a timestamp to allow expiry would probably be sufficient, and modifying the sending service's select_edus function to filter out unwanted EDUs would also likely be trivial.

https://github.com/matrix-org/matrix-spec-proposals/pull/4373 ([rendered](https://github.com/velikopter/matrix-spec-proposals/blob/edutypes/proposals/4373-edu-types.md)) This proposal allows us to cut down on bandwidth by both finding out what EDUs to not send to servers, and also tell other servers what we don't want to receive. This will also help with CPU and memory usage since we can simply avoid wasting time sending data to other servers or receiving it when the recipient simply doesn't care about the data and will just discard it anyway. Returning our accepted EDU types should be pretty easy considering we already have config options for inbound EDUs like typing and presence: https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/a3592bd3b761b54f1e6cf4a080584ff6b418ac42/conduwuit-example.toml#L1168 https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/a3592bd3b761b54f1e6cf4a080584ff6b418ac42/conduwuit-example.toml#L1110 All that would need is a ruwuma update to introduce the response body structure. Filtering outgoing EDUs probably wouldn't be too much difficult. A database cache probably wouldn't be needed for this, an in-memory cached filled in by requesting the destination's EDU filter before sending the first transaction tagged with a timestamp to allow expiry would probably be sufficient, and modifying [the sending service's `select_edus`](https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/a3592bd3b761b54f1e6cf4a080584ff6b418ac42/src/service/sending/sender.rs#L368) function to filter out unwanted EDUs would also likely be trivial.