Jonathan de Jong

PDUs are immutable anyways, i think the wording is still okayish, as i'm just mainly referring to *generating* data that way. (though, lemme add that...)

I think https://github.com/ruma/ruma/issues/894 could help with some version incompatibilities, should they rise up in the future.

:+1: to a seperate `FederationClient`, I had some doubts with merging those two in the first place.

After discussing https://github.com/ruma/ruma/issues/894 a bit in the spec room, i think that the federation client needs to handle versioning differently than the normal client, as the primary intention for the...

Is there a lint of sorts that we could use for this? Or could we possibly detect this with the macros that wrap those requests/responses?

> Required: The maximum depth of the prev_events, plus one. **Must be less than the maximum value for an integer (2^63 - 1).** If the room’s depth is already at...

Other than V1, `depth` isn't used anywhere. However, I think that this should be noted in a clarification issue. Edit: Created: https://github.com/matrix-org/matrix-doc/issues/3629

For reference, my server currently sends the following in the versions array; ```json "versions": [ "r0.0.1", "r0.1.0", "r0.2.0", "r0.3.0", "r0.4.0", "r0.5.0", "r0.6.0", "r0.6.1" ] ```

It's mainly as there's some ambiguity through https://github.com/matrix-org/matrix-spec/issues/12, where "no v1.0 exists" is upheld, yet it should be denoted as *something* to maintain some form of compatibility/continuity between legacy and...

And, with ruma-client, it'd have the advantage of fetching / integrating / knowing a server's API version before it'll perform any requests, which would help along low-level serialization/API versioning requirements...