You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The total size of any event MUST NOT exceed 65 KB.
The spec almost hits a bullseye here but there are a few issues:
65 KB is not clear enough for a technical specification. Is that 65000 bytes or is that 65536 bytes? I'm unsure because both 65 KB and 65 KiB are rare orders in the world of computing. 64 KB would be more obvious to assume 64 KiB or 65536 bytes, but 65 KB really requires clarification and it should be in exact bytes.
This is in the client-server spec. The server-server spec should reflect this with even more clarity, assuring a maximum size for the total information of a single event, on the wire, including signatures.
Regardless of this clarification, any effort to update the specification should make this value at or below 65507 bytes. As the current choice is quite close at either 65536 bytes or 65000 bytes and this change at this stage probably won't have any disruption but the benefits of doing this are more glorious than one may first consider.
At 65507 bytes an event can fit into a single UDP datagram which can be transmitted without fragmentation. This lays the groundwork for a massively distributed mesh of fire-and-forget message passing from every homeserver to every other homeserver without establishing and holding TCP connections if such a direction is ever satiating in the future.
I see no reason to preclude that as a future possibility even if one feels it's unlikely the protocol will ever go that route. Sometime in the future if that becomes a worthy direction it would be sad to write it off merely because of a few events floating around which are a few bytes over this few byte difference all because the spec didn't preempt the issue now.
Lastly, I think the exact limit the spec should have is actually 65000 bytes. This gives a fair amount of tolerance (507 bytes) for more ambiguities that haven't been contemplated yet.
So in effect, this issue may not change the spec at all. :)
The text was updated successfully, but these errors were encountered:
You probably won't like it, but I've clarified the current situation at #1023 (see https://matrix.org/docs/spec/client_server/unstable.html#size-limits for the rendered version). That, at least, deals with the clarification side of this issue (modulo the fact that the server-server spec is in general woefully weak).
As to what could have been - you're welcome to raise a separate issue.
The specification says (https://matrix.org/docs/spec/client_server/r0.2.0.html#size-limits)
The spec almost hits a bullseye here but there are a few issues:
65 KB
is not clear enough for a technical specification. Is that65000 bytes
or is that65536 bytes
? I'm unsure because both65 KB
and65 KiB
are rare orders in the world of computing.64 KB
would be more obvious to assume64 KiB
or65536
bytes, but65 KB
really requires clarification and it should be in exact bytes.This is in the client-server spec. The server-server spec should reflect this with even more clarity, assuring a maximum size for the total information of a single event, on the wire, including signatures.
Regardless of this clarification, any effort to update the specification should make this value at or below
65507
bytes. As the current choice is quite close at either 65536 bytes or 65000 bytes and this change at this stage probably won't have any disruption but the benefits of doing this are more glorious than one may first consider.At
65507 bytes
an event can fit into a single UDP datagram which can be transmitted without fragmentation. This lays the groundwork for a massively distributed mesh of fire-and-forget message passing from every homeserver to every other homeserver without establishing and holding TCP connections if such a direction is ever satiating in the future.I see no reason to preclude that as a future possibility even if one feels it's unlikely the protocol will ever go that route. Sometime in the future if that becomes a worthy direction it would be sad to write it off merely because of a few events floating around which are a few bytes over this few byte difference all because the spec didn't preempt the issue now.
Lastly, I think the exact limit the spec should have is actually
65000 bytes
. This gives a fair amount of tolerance (507 bytes) for more ambiguities that haven't been contemplated yet.So in effect, this issue may not change the spec at all. :)
The text was updated successfully, but these errors were encountered: