Fix several spelling mistakes

Signed-off-by: Aaron Raimist <aaron@raim.ist>

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

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.

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

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

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

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": "<sender_curve25519_key>",
         "device_id": "<sender_device_id>",
         "session_id": "<outbound_group_session_id>",
-        "ciphertext": "<encypted_payload_base_64>"
+        "ciphertext": "<encrypted_payload_base_64>"
       }
     }
 

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.
 

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

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

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.

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

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<y` if
 
   1. the closest mainline event to :math:`x` appears *before* the closest

specification/server_server_api.rst

@@ -142,7 +142,7 @@ The process overall is as follows:
      the IP address, including the port if one was provided.
 
    * If ``<delegated_hostname>`` is not an IP literal, and ``<delegated_port>``
-     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 ``<delegated_hostname>``. The resulting IP address is
      used, alongside the ``<delegated_port>``. Requests must be made with a
      ``Host`` header of ``<delegated_hostname>:<delegated_port>``. 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]]