From fe7f58223324d28559a460f60c1be8241456f318 Mon Sep 17 00:00:00 2001 From: Aaron Raimist Date: Fri, 1 Feb 2019 16:42:49 -0600 Subject: [PATCH] Fix several spelling mistakes Signed-off-by: Aaron Raimist --- specification/appendices/base64.rst | 2 +- specification/appendices/identifier_grammar.rst | 2 +- specification/client_server_api.rst | 6 +++--- specification/index.rst | 2 +- specification/modules/account_data.rst | 2 +- specification/modules/end_to_end_encryption.rst | 4 ++-- specification/modules/mentions.rst | 2 +- specification/modules/tags.rst | 2 +- specification/modules/third_party_invites.rst | 2 +- specification/push_gateway.rst | 2 +- specification/rooms/v1.rst | 2 +- specification/rooms/v2.rst | 2 +- specification/server_server_api.rst | 8 ++++---- 13 files changed, 19 insertions(+), 19 deletions(-) diff --git a/specification/appendices/base64.rst b/specification/appendices/base64.rst index d046e0fc..a918c2f9 100644 --- a/specification/appendices/base64.rst +++ b/specification/appendices/base64.rst @@ -52,6 +52,6 @@ Examples of strings encoded using unpadded Base64:: UNPADDED_BASE64("foobar") = "Zm9vYmFy" When decoding Base64, implementations SHOULD accept input with or without -padding characters whereever possible, to ensure maximum interoperability. +padding characters wherever possible, to ensure maximum interoperability. .. _`RFC 4648`: https://tools.ietf.org/html/rfc4648 diff --git a/specification/appendices/identifier_grammar.rst b/specification/appendices/identifier_grammar.rst index b4678988..a0cdf298 100644 --- a/specification/appendices/identifier_grammar.rst +++ b/specification/appendices/identifier_grammar.rst @@ -203,7 +203,7 @@ a homeserver creating a user ID for a new user based on the username passed to Implementations are free to do this mapping however they choose. Since the user ID is opaque except to the implementation which created it, the only -requirement is that the implemention can perform the mapping +requirement is that the implementation can perform the mapping consistently. However, we suggest the following algorithm: 1. Encode character strings as UTF-8. diff --git a/specification/client_server_api.rst b/specification/client_server_api.rst index 8f4a9a1d..c506af4e 100644 --- a/specification/client_server_api.rst +++ b/specification/client_server_api.rst @@ -158,7 +158,7 @@ Other error codes the client might encounter are: Sent when the room alias given to the ``createRoom`` API is already in use. :``M_INVALID_ROOM_STATE``: - Sent when the intial state given to the ``createRoom`` API is invalid. + Sent when the initial state given to the ``createRoom`` API is invalid. :``M_THREEPID_IN_USE``: Sent when a threepid given to an API cannot be used because the same threepid is already in use. @@ -636,7 +636,7 @@ To use this authentication type, clients should submit an auth dict as follows: where the ``identifier`` property is a user identifier object, as described in `Identifier types`_. -For example, to authenticate using the user's Matrix ID, clients whould submit: +For example, to authenticate using the user's Matrix ID, clients would submit: .. code:: json @@ -928,7 +928,7 @@ Third-party ID :Type: ``m.id.thirdparty`` :Description: - The user is identified by a third-party identifer in canonicalised form. + The user is identified by a third-party identifier in canonicalised form. A client can identify a user using a 3pid associated with the user's account on the homeserver, where the 3pid was previously associated using the diff --git a/specification/index.rst b/specification/index.rst index 05b85ab7..aa4471c4 100644 --- a/specification/index.rst +++ b/specification/index.rst @@ -474,7 +474,7 @@ Room versions are divided into two distinct groups: stable and unstable. Stable room versions may be used by rooms safely. Unstable room versions are everything else which is either not listed in the specification or flagged as unstable for some other reason. Versions can switch between stable and unstable periodically -for a variety of reasons, including discovered security vulnerabilites and age. +for a variety of reasons, including discovered security vulnerabilities and age. Clients should not ask room administrators to upgrade their rooms if the room is running a stable version. Servers SHOULD use room version 1 as the default room diff --git a/specification/modules/account_data.rst b/specification/modules/account_data.rst index f0bf285f..a67e503a 100644 --- a/specification/modules/account_data.rst +++ b/specification/modules/account_data.rst @@ -27,7 +27,7 @@ The account_data may be either global or scoped to a particular rooms. Events ------ -The client recieves the account data as events in the ``account_data`` sections +The client receives the account data as events in the ``account_data`` sections of a ``/sync``. These events can also be received in a ``/events`` response or in the diff --git a/specification/modules/end_to_end_encryption.rst b/specification/modules/end_to_end_encryption.rst index 72bfae35..a605875b 100644 --- a/specification/modules/end_to_end_encryption.rst +++ b/specification/modules/end_to_end_encryption.rst @@ -450,7 +450,7 @@ previously-received ``request`` message with the same ``request_id`` and .. NOTE:: Key sharing can be a big attack vector, thus it must be done very carefully. - A reasonable stategy is for a user's client to only send keys requested by the + A reasonable strategy is for a user's client to only send keys requested by the verified devices of the same user. Key exports @@ -696,7 +696,7 @@ An event encrypted using Megolm has the following format: "sender_key": "", "device_id": "", "session_id": "", - "ciphertext": "" + "ciphertext": "" } } diff --git a/specification/modules/mentions.rst b/specification/modules/mentions.rst index 4501b776..dc078f3b 100644 --- a/specification/modules/mentions.rst +++ b/specification/modules/mentions.rst @@ -44,7 +44,7 @@ In addition to using the appropriate ``matrix.to URI`` for the mention, clients should use the following guidelines when making mentions in events to be sent: -* When mentioning users, use the user's potentially ambigious display name for +* When mentioning users, use the user's potentially ambiguous display name for the anchor's text. If the user does not have a display name, use the user's ID. diff --git a/specification/modules/tags.rst b/specification/modules/tags.rst index 739ead2c..a4b0becf 100644 --- a/specification/modules/tags.rst +++ b/specification/modules/tags.rst @@ -48,7 +48,7 @@ The tag namespace is defined as follows: * The namespace ``u.*`` is reserved for user-defined tags. The portion of the string after the ``u.`` is defined to be the display name of this tag. No other semantics should be inferred from tags in this namespace. -* A client or app willing to use special tags for advanced functionnality should namespace them similarly to state keys: ``tld.name.*`` +* A client or app willing to use special tags for advanced functionality should namespace them similarly to state keys: ``tld.name.*`` * Any tag in the ``tld.name.*`` form but not matching the namespace of the current client should be ignored * Any tag not matching the above rules should be interpreted as a user tag from the ``u.*`` namespace, as if the name had already had ``u.`` stripped from the start (ie. the name of the tag is used as the diff --git a/specification/modules/third_party_invites.rst b/specification/modules/third_party_invites.rst index df71d215..3e11d929 100644 --- a/specification/modules/third_party_invites.rst +++ b/specification/modules/third_party_invites.rst @@ -229,7 +229,7 @@ verification must still be performed, so the attack surface here is minimized. Security considerations ----------------------- -There are a number of privary and trust implications to this module. +There are a number of privacy and trust implications to this module. It is important for user privacy that leaking the mapping between a matrix user ID and a third party identifier is hard. In particular, being able to look up diff --git a/specification/push_gateway.rst b/specification/push_gateway.rst index a77d43db..cba38b6c 100644 --- a/specification/push_gateway.rst +++ b/specification/push_gateway.rst @@ -84,7 +84,7 @@ This describes the format used by "HTTP" pushers to send notifications of events to Push Gateways. If the endpoint returns an HTTP error code, the homeserver SHOULD retry for a reasonable amount of time using exponential backoff. -When pushing notifications for events, the hoemserver is expected to include all of +When pushing notifications for events, the homeserver is expected to include all of the event-related fields in the ``/notify`` request. When the homeserver is performing a push where the ``format`` is ``"event_id_only"``, only the ``event_id``, ``room_id``, ``counts``, and ``devices`` are required to be populated. diff --git a/specification/rooms/v1.rst b/specification/rooms/v1.rst index e09420e4..d7939c61 100644 --- a/specification/rooms/v1.rst +++ b/specification/rooms/v1.rst @@ -275,7 +275,7 @@ The rules are as follows: Some consequences of these rules: * Unless you are a member of the room, the only permitted operations (apart - from the intial create/join) are: joining a public room; accepting or + from the initial create/join) are: joining a public room; accepting or rejecting an invitation to a room. * To unban somebody, you must have power level greater than or equal to both diff --git a/specification/rooms/v2.rst b/specification/rooms/v2.rst index d39a7caa..c95fc4c9 100644 --- a/specification/rooms/v2.rst +++ b/specification/rooms/v2.rst @@ -116,7 +116,7 @@ Mainline ordering of condition 1 below. The *mainline ordering based on* :math:`P` of a set of events is the - ordering, from smallest to largest, using the following comparision relation + ordering, from smallest to largest, using the following comparison relation on events: for events :math:`x` and :math:`y`, :math:`x`` is not an IP literal, and ```` - is present, an IP address is disovered by looking up an AAAA or A + is present, an IP address is discovered by looking up an AAAA or A record for ````. The resulting IP address is used, alongside the ````. Requests must be made with a ``Host`` header of ``:``. The @@ -1125,7 +1125,7 @@ including content hashes. It is calculated as follows. 3. The event is converted into `Canonical JSON`_. -4. A sha256 hash is calculed on the resulting JSON object. +4. A sha256 hash is calculated on the resulting JSON object. Calculating the content hash for an event @@ -1170,7 +1170,7 @@ Example code # Keys under "unsigned" can be modified by other servers. # They are useful for conveying information like the age of an # event that will change in transit. - # Since they can be modifed we need to exclude them from the hash. + # Since they can be modified we need to exclude them from the hash. event_object.pop("unsigned", None) # Signatures will depend on the current value of the "hashes" key. @@ -1192,7 +1192,7 @@ Example code [[TODO(markjh): Since the ``hash`` object cannot be redacted a server shouldn't allow too many hashes to be listed, otherwise a server might embed - illict data within the ``hash`` object. + illicit data within the ``hash`` object. We might want to specify a maximum number of keys for the ``hash`` and we might want to specify the maximum output size of a hash]]