Commit graph

7 commits

Author SHA1 Message Date
Will 00c6a866e2 Move raw API and event schemas into /data directory
Historical note: this was originally a series of several commits, spread out
over several weeks. They have been squashed together to make `git annotate`
work properly.

The original commits were:
 * 91ab3934 <Will> 2021-01-25 21:16:42 -0800 Add raw API end event schemas into /data directory
 * aae22f47 <Will> 2021-01-25 21:33:06 -0800 Remove non-data files
 * 1092d4ca <Will> 2021-01-26 20:41:33 -0800 Add data-compatiuble extension (.yaml) to all data files that currently omit one
 * 21060109 <Will> 2021-01-26 20:57:28 -0800 Remove symlink to event-schemas, and update openAPI schema paths accordingly
 * 4f633845 <Travis Ralston> 2021-04-12 21:54:54 -0600 Fix event schema examples too
 * 301c7b2f <Will> 2021-02-05 10:15:42 -0800 Restore docs describing OpenAPI extensions that we use
2021-08-27 19:16:39 +01:00
Will 42bb5127be
Fix typo in API title 2020-11-08 09:44:11 -08:00
Kitsune Ral bda05a0d44 capabilities.yaml: drop an extraneous title
AvailableRoomVersions sticks itself as a property type, preempting
the mention of RoomVersionStability in the generated text.
2020-06-01 09:50:18 +02:00
Kitsune Ral 65cd10249c Render enums inside additionalProps as one more table
Closes #2242.
2019-08-24 21:56:48 +09:00
Travis Ralston d31d2f5e57 Correctly nest the capabilities response object
Everything is contained in a "capabilities" property, which is not represented by the schema. The example was correct.
2019-02-11 20:31:48 -07:00
Travis Ralston 9193d57dfd full stop 2019-01-30 19:47:16 -07:00
Travis Ralston ccce6c196d Specify how capabilities work in the c2s API
Original proposals:
* https://github.com/matrix-org/matrix-doc/pull/1753
* https://github.com/matrix-org/matrix-doc/pull/1804

Implementation proof:
* https://github.com/matrix-org/synapse/pull/4472
* https://github.com/matrix-org/matrix-js-sdk/pull/830

There is one change to MSC1753 which is included in this commit. MSC1804 remains unchanged. In the original proposal, the change password capability being present was an indication that password changes were possible. It was found that this doesn't really communicate the state very well to clients in that lack of a capability (or a 404, etc) would mean that users would erroneously not be able to change their passwords. A simple boolean flag was added to assist clients in detecting this capability.
2019-01-30 19:43:55 -07:00