This adds several diagrams to the Client-Server API about how invites
are handled, including what the server is expected to do. This helps
implementors know what they are supposed to do in the common cases,
and infer where needed to get the more complex cases correct.
Although lacking in some areas, this is how third party invites work
today.
A link to the now-improved client-server documentation for third party
invites has been added to the server-server specification. The existing
server-server specification needed no further changes on the subject.
Fixes https://github.com/matrix-org/matrix-doc/issues/1366
The original text wasn't far off, except for being wrong about what the fields actually do. This commit also adds a bit of clarity for how the server is expected to behave.
We might want to consider promoting the media repo to it's own API, and maybe consider calling it the Media Repo rather than Content Repo.
Source of information: experience.
Have removed the second clause about how the client interprets them:
I was trying to think how to rephrase it but I think in reality it's
probably just redundant.
This is useful for when we start defining event schemas. This also has a sanity check for ensuring the directory exists, allowing the IS and push API paths to be uncommented.
Fixes https://github.com/matrix-org/matrix-doc/issues/1161
The IP address clarification is to add an explicit mention of how to handle the case. The prior documentation assumed that all servers would be resolvable with DNS, and does technically have a fallback to use the fallback port, however making it clear feels like a good idea.
This intentionally doesn't document the third party network aspect of the endpoint. This is scheduled for a later area for dealing with third party network/IDs and is reported as https://github.com/matrix-org/matrix-doc/issues/1476
The client-server response has been broken out to a shared file: both the client-server and server-server /publicRoom endpoints return the same thing, with slightly different inputs.
The inputs (and behaviour) are based upon the docstring here: 43ecfe0b10/synapse/federation/transport/server.py (L583-L612)