Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-04-14 23:24:09 +02:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Fix typos

Browse source 
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This commit is contained in:
Kévin Commaille 2023-10-05 16:45:50 +02:00
parent 6b3ae471ae
commit 634717c2f4
No known key found for this signature in database
GPG key ID: 29A48C1F03620416
6 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
data/api/client-server/create_room.yaml
View file

@ -209,7 +209,7 @@ paths:
based on a preset.
If unspecified, the server should use the `visibility` to determine
which preset to use. A visbility of `public` equates to a preset of
which preset to use. A visibility of `public` equates to a preset of
`public_chat` and `private` visibility equates to a preset of
`private_chat`.
is_direct:

2
data/api/client-server/login_token.yaml
View file

@ -39,7 +39,7 @@ paths:
In v1.7 of the specification, transmission of the generated token to an unauthenticated client is
left as an implementation detail. Future MSCs such as [MSC3906](https://github.com/matrix-org/matrix-spec-proposals/pull/3906)
might standarise a way to transmit the token between clients.
might standardise a way to transmit the token between clients.
The generated token MUST only be valid for a single login, enforced by the server. Clients which
intend to log in multiple devices must generate a token for each.

2
data/api/server-server/joins-v2.yaml
View file

@ -27,7 +27,7 @@ paths:
exception of the response format being fixed.
This endpoint is preferred over the v1 API as it provides
a more standarised response format. Senders which receive
a more standardised response format. Senders which receive
a 400, 404, or other status code which indicates this endpoint
is not available should retry using the v1 API instead.

2
data/api/server-server/leaving-v2.yaml
View file

@ -27,7 +27,7 @@ paths:
exception of the response format being fixed.
This endpoint is preferred over the v1 API as it provides
a more standarised response format. Senders which receive
a more standardised response format. Senders which receive
a 400, 404, or other status code which indicates this endpoint
is not available should retry using the v1 API instead.

2
meta/documentation_style.rst
View file

@ -191,4 +191,4 @@ Describing grammar
Use `RFC5234-style ABNF <https://datatracker.ietf.org/doc/html/rfc5234>`_ when describing
the grammar for something in the spec, such as user IDs or server names. Use lowercase
and underscore-deliminated element names (`user_id`, not `UserID` or `user-id`).
and underscore-delimited element names (`user_id`, not `UserID` or `user-id`).

2
meta/releasing.md
View file

@ -31,7 +31,7 @@ day until the release has actually happened & blog post published.
Once a release is scheduled, the SCT will begin planning what the next release is
expected to look like. The plan should be included in the spec release blog post,
and be ready for exeuction on spec release day. Plans are guides and not promises.
and be ready for execution on spec release day. Plans are guides and not promises.
A blog post for the SCT members to review should be ready at minimum 1 week before
the target release date. 1-2 days before the release itself, the prerequisite steps