Repository navigation
We should spec the max size of an EDU over federation #807
Description
Currently, there is effectively no limit to the size of a /_matrix/federation/v1/send/{txnId} request, because some EDUs (eg presence, receipts) can reasonably contain an unlimited quantity of data. I think we should specify some limits to the amount of data such EDUs can contain.
Activity
turt2live commentedon Apr 14, 2021
EDUs are events and thus are subject to the 65K limit?
richvdh commentedon Apr 15, 2021
They really aren't events: they don't follow the same structure in any other way.
Using the same limit as PDUs seems reasonable.
turt2live commentedon Apr 15, 2021
I mean the spec calls them events and already applies that limit.
richvdh commentedon Apr 15, 2021
what do you mean "applies that limit"?
I think it's a mistake to call them events. They don't have event_ids, room_ids, or anything else that makes an event an event.
turt2live commentedon Apr 15, 2021
from memory, there's a ton of mentions of them being events. It's a similar situation for account data. Events are only defined to have
contentandtype- we have a different concept of Room Events which have an ID and other fields.richvdh commentedon Apr 15, 2021
edus don't have a
type:-p (https://spec.matrix.org/unstable/server-server-api/#edus; cf also matrix-org/matrix-spec-proposals#1143)turt2live commentedon Apr 15, 2021
<insert sobbing>They have a
typeat the client-server level. We should fix this...richvdh commentedon Apr 15, 2021
they don't exist at the client-server level. They might map onto something else at that level, but they are a purely server-server concept.
KitsuneRal commentedon Apr 15, 2021
I understand that they might not look like "proper events" in the federation API, but CS API really treats them like those throughout. Not that they can be interspersed with PDUs but, e.g.,
/syncsends them just as another bunch of "events" (and even room events don't haveroom_idbecause it's resolved from the context both for PDUs and EDUs, btw).richvdh commentedon Apr 15, 2021
/sync sends things like "read receipts" and "presence updates". It calls them "Ephemeral events", but part of the entire problem here is that a single EDU can include multiple read receipts and presence updates. It's definitely not the case that these are then sent in their entirety on to clients.
In short: the "ephemeral events" that the C-S spec talks about are not the same as EDUs that happen over the S-S API. That may be less than satisfactory, but changing it is a bigger task.
[-]We should spec the max size of an EDU[/-][+]We should spec the max size of an EDU over federation[/+]KitsuneRal commentedon Apr 15, 2021
By the way, CS API applies the same restriction on all events, referring to S-S API as a source of canonicalisation algorithm; I wonder if that section should probably be updated as well.
richvdh commentedon Nov 28, 2024
Whether they are an "event" or not (for which, see #897), I still think the spec should give an explicit limit for the size of an EDU (and also the size of a to-device message).
ansiwen commentedon Jan 3, 2025
See element-hq/synapse#17035 (comment) for an example that results in 32MB to-device EDU transactions that are blocked by matrix.org (or cloudflare I guess).
Limit outgoing to_device EDU size to 65536 (#18416)
Limit outgoing to_device EDU size to 65536 (#18416)
Limit outgoing to_device EDU size to 65536 (element-hq#18416)