wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Add changelogs

Browse source
This commit is contained in:
Andrew Morgan 2019-02-11 09:56:54 +00:00
commit df7223f992
14 changed files with 44 additions and 21 deletions
Download patch file Download diff file Expand all files Collapse all files

4
api/server-server/keys_server.yaml
View file

@ -27,7 +27,7 @@ paths:
get:
summary: Get the homeserver's public key(s)
description: |-
Gets the homeserver's published TLS fingerprints and signing keys.
Gets the homeserver's published signing keys.
The homeserver may have any number of active keys and may have a
number of old keys.
@ -49,7 +49,7 @@ paths:
type: string
description: |-
**Deprecated**. Servers should not use this parameter and instead
opt to return all keys, not just the requested one. The key ID to
opt to return all keys, not just the requested one. The key ID to
look up.
required: false
x-example: "ed25519:abc123"

5
api/server-server/wellknown.yaml
View file

@ -35,9 +35,8 @@ paths:
The delegated server information. The ``Content-Type`` for this response SHOULD
be ``application/json``, however servers parsing the response should assume that
the body is JSON regardless of type. Failures parsing the JSON or invalid data
provided in the resulting parsed JSON must result in server discovery failure (no
attempts should be made to continue finding an IP address/port number to connect
to).
provided in the resulting parsed JSON should not result in discovery failure -
consult the server discovery process for information on how to continue.
examples:
application/json: {
"m.server": "delegated.example.com:1234"

1
changelogs/client_server/newsfragments/1838.clarification Normal file
View file

@ -0,0 +1 @@
Fix various spelling mistakes throughout the specification.

1
changelogs/client_server/newsfragments/1853.clarification Normal file
View file

@ -0,0 +1 @@
Fix various spelling mistakes throughout the specification.

1
changelogs/client_server/newsfragments/1860.clarification Normal file
View file

@ -0,0 +1 @@
Fix various spelling mistakes throughout the specification.

1
changelogs/identity_service/newsfragments/1853.clarification Normal file
View file

@ -0,0 +1 @@
Fix various spelling mistakes throughout the specification.

10
changelogs/server_server.rst
View file

@ -1,3 +1,13 @@
r0.1.1
======
Spec Clarifications
-------------------
- Remove legacy references to TLS fingerprints. (`#1844 <https://github.com/matrix-org/matrix-doc/issues/1844>`_)
- Clarify that servers should not fail to contact servers if ``/.well-known`` fails. (`#1855 <https://github.com/matrix-org/matrix-doc/issues/1855>`_)
r0.1.0
======

2
scripts/templating/matrix_templates/units.py
View file

@ -774,7 +774,7 @@ class MatrixUnits(Units):
"Privileged server plugins",
), TypeTableRow(
"`Identity Service API <identity_service/"+is_ver+".html>`_",
"unstable",
is_ver,
"Mapping of third party IDs to Matrix IDs",
), TypeTableRow(
"`Push Gateway API <push_gateway/"+push_gw_ver+".html>`_",

2
specification/client_server_api.rst
View file

@ -73,7 +73,7 @@ MUST be encoded as UTF-8. Clients are authenticated using opaque
``access_token`` strings (see `Client Authentication`_ for details), passed as a
query string parameter on all requests.
The names of the API endponts for the HTTP transport follow a convention of
The names of the API endpoints for the HTTP transport follow a convention of
using underscores to separate words (for example ``/delete_devices``). The key
names in JSON objects passed over the API also follow this convention.

2
specification/identity_service_api.rst
View file

@ -279,4 +279,4 @@ this isn't possible.
.. _`Unpadded Base64`: ../appendices.html#unpadded-base64
.. _`3PID Types`: ../appendices.html#pid-types
.. _`Signing JSON`: ../appendices.html#signing-json
.. _`/3pid/onbind`: ../server_server/r0.1.0.html#put-matrix-federation-v1-3pid-onbind
.. _`/3pid/onbind`: ../server_server/r0.1.1.html#put-matrix-federation-v1-3pid-onbind

7
specification/rooms/v1.rst
View file

@ -18,6 +18,9 @@ Room Version 1
This room version is the first ever version for rooms, and contains the building
blocks for other room versions.
.. contents:: Table of Contents
.. sectnum::
Server implementation components
--------------------------------
@ -290,5 +293,5 @@ Events in version 1 rooms have the following structure:
{{definition_ss_pdu}}
.. _`auth events selection`: ../../server_server/r0.1.0.html#auth-events-selection
.. _`Signing Events`: ../../server_server/r0.1.0.html#signing-events
.. _`auth events selection`: ../../server_server/r0.1.1.html#auth-events-selection
.. _`Signing Events`: ../../server_server/r0.1.1.html#signing-events

10
specification/rooms/v2.rst
View file

@ -18,6 +18,9 @@ Room Version 2
This room version builds off of `version 1 <v1.html>`_ with an improved state
resolution algorithm.
.. contents:: Table of Contents
.. sectnum::
Server implementation components
--------------------------------
@ -27,9 +30,8 @@ Server implementation components
details contained here, and can safely ignore their presence.
The algorithms defined here should only apply to version 2 rooms. Other algorithms
may be used by other room versions, and as such servers should be aware of which
version room they are dealing with prior to executing a given algorithm.
Room version 2 uses the base components of `room version 1 <v1.html>`_, changing
only the state resolution algorithm.
State resolution
@ -159,7 +161,7 @@ The *resolution* of a set of states is obtained as follows:
resolved state.
.. _`authorization rules`: ../server_server/r0.1.0.html#authorization-rules
.. _`authorization rules`: ../server_server/r0.1.1.html#authorization-rules
Rejected events
+++++++++++++++

7
specification/rooms/v3.rst
View file

@ -24,6 +24,9 @@ This room version builds on `version 2 <v2.html>`_ with an improved event format
where the contextual room of the request is using this room version. Rooms using
other room versions should not be affected by these sweeping requirements.
.. contents:: Table of Contents
.. sectnum::
Client considerations
---------------------
@ -117,5 +120,5 @@ The remaining rules are the same as `room version 1 <v1.html#authorization-rules
.. _`Unpadded Base64`: ../../appendices.html#unpadded-base64
.. _`Canonical JSON`: ../../appendices.html#canonical-json
.. _`Signing Events`: ../../server_server/r0.1.0.html#signing-events
.. _`reference hash`: ../../server_server/r0.1.0.html#reference-hashes
.. _`Signing Events`: ../../server_server/r0.1.1.html#signing-events
.. _`reference hash`: ../../server_server/r0.1.1.html#reference-hashes

12
specification/server_server_api.rst
View file

@ -16,6 +16,8 @@
Federation API
==============
{{unstable_warning_block_SERVER_RELEASE_LABEL}}
Matrix homeservers use the Federation APIs (also known as server-server APIs)
to communicate with each other. Homeservers use these APIs to push messages to
each other in real-time, to retrieve historic messages from each other, and to
@ -78,6 +80,7 @@ Other versions of this specification
The following other versions are also available, in reverse chronological order:
- `HEAD <https://matrix.org/docs/spec/server_server/unstable.html>`_: Includes all changes since the latest versioned release.
- `r0.1.1 <https://matrix.org/docs/spec/server_server/r0.1.1.html>`_
- `r0.1.0 <https://matrix.org/docs/spec/server_server/r0.1.0.html>`_
Server discovery
@ -157,14 +160,14 @@ The process overall is as follows:
and a port of 8448, using a ``Host`` header of ``<delegated_hostname>``.
The target server must present a valid certificate for ``<delegated_hostname>``.
4. If the `/.well-known` request resulted in an error response, a server
4. If the ``/.well-known`` request resulted in an error response, a server
is found by resolving an SRV record for ``_matrix._tcp.<hostname>``. This
may result in a hostname (to be resolved using AAAA or A records) and
port. Requests are made to the resolved IP address and port, using 8448
as a default port, with a ``Host`` header of ``<hostname>``. The target
server must present a valid certificate for ``<hostname>``.
5. If the `/.well-known` request returned an error response, and the SRV
5. If the ``/.well-known`` request returned an error response, and the SRV
record was not found, an IP address is resolved using AAAA and A records.
Requests are made to the resolved IP address using port 8448 and a ``Host``
header containing the ``<hostname>``. The target server must present a
@ -220,12 +223,11 @@ server by querying other servers.
Publishing Keys
+++++++++++++++
Homeservers publish the allowed TLS fingerprints and signing keys in a JSON
Homeservers publish their signing keys in a JSON
object at ``/_matrix/key/v2/server/{key_id}``. The response contains a list of
``verify_keys`` that are valid for signing federation requests made by the
homeserver and for signing events. It contains a list of ``old_verify_keys`` which
are only valid for signing events. Finally the response contains a list of TLS
certificate fingerprints to validate any connection made to the homeserver.
are only valid for signing events.
{{keys_server_ss_http_api}}