There isn't a whole lot to this section that needed work. The section overall lost the table schema in favour of having the endpoints close by.
The directory query is improved in https://github.com/matrix-org/matrix-doc/pull/1443
Most of the text has been shuffled into the swagger definitions to bring it closer to where it matters.
This also attempts to clarify what is out in the wild. Most importantly, the first version of the key exchange is outright removed from the specification. Other research points/questions are:
* What is a "Key ID"?
* 1241156c82/synapse/rest/key/v2/local_key_resource.py (L81-L83)
* 1241156c82/synapse/rest/key/v2/local_key_resource.py (L88-L91)
* Returning a cached response if the server throws a 400, 500, or otherwise not-offline status code
* 1241156c82/synapse/rest/key/v2/remote_key_resource.py (L227-L229)
* `minimum_valid_until_ts` default
* This branch of the ladder: 1241156c82/synapse/rest/key/v2/remote_key_resource.py (L192)
* Returning empty arrays when querying offline/no servers
* Queried by hand against matrix.org as a notary server with a fake domain name to query
* Returning all keys even when querying for specific keys
* Queried by hand using matrix.org as a notary server against a server publishing multiple keys.
The examples and descriptions were also improved as part of this commit.
This is a mix of Synapse and Dendrite behaviour, mostly Dendrite. Synapse returns `null` for field values that aren't set, however Dendrite just doesn't return them and instead opts for an empty object.
Further, synapse is lacking in error codes in this area. Dendrite does some additional validation on this API which introduces more errors for bad requests, instead of defaulting to empty objects/200 OK responses.
Likewise, Dendrite returns a 404 when the user is not found while Synapse returns 200 OK/empty object.
The whole section reads like a description for the endpoint, and has been replaced by the swagger definition now (rather than at a later stage). All the same information should be kept.
There's two kinds of transactions currently: one with EDUs and one without. The one with EDUs is only used on /send, however the schema is still somewhat worth splitting out for simplicity.
The examples are brought apart to make them slightly more reusable for when they get dumped into the relevant sections of the spec (see TODO in server_server_api.rst)
Further, the Transactions stuff introduces tuples to the spec. The units.py has been updated to support this.
