Add GitHub Action to check spelling (#3591)

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

.github/_typos.toml

@@ -0,0 +1,12 @@
+[files]
+extend-exclude = ["/themes", "/attic", "/data-definitions", "*.css", "package-lock.json"]
+
+[default]
+check-filename = true
+
+[default.extend-identifiers]
+au1ba7o = "au1ba7o"
+
+[default.extend-words]
+Appy = "Appy"
+fo = "fo"

.github/workflows/spell-check.yaml

@@ -0,0 +1,15 @@
+name: Spell Check
+on: [pull_request]
+
+jobs:
+  run:
+    name: Spell Check with Typos
+    runs-on: ubuntu-latest
+    steps:
+    - name: Checkout Actions Repository
+      uses: actions/checkout@v2
+
+    - name: Check spelling of proposals
+      uses: crate-ci/typos@master
+      with:
+        config: ${{github.workspace}}/.github/_typos.toml

changelogs/client_server/newsfragments/3492.clarification

@@ -1 +1 @@
-Explicity mention RFC5870 in the definition of `m.location` events
+Explicitly mention RFC5870 in the definition of `m.location` events

changelogs/legacy/client_server.rst

@@ -497,7 +497,7 @@ This release includes the following changes since r0.0.1:
     ``GET /rooms/{roomId}/context/{eventId}``, as well as correcting the
     example for that API
   - Clarify the behaviour of the "Room History Visibility" module; in
-    particular, the behaviour of the ``shared`` history visibilty, and how
+    particular, the behaviour of the ``shared`` history visibility, and how
     events at visibility boundaries should be handled
   - Separate the "Room Previews" module from "Guest access"
   - Reword the description of the ``profile_tag`` property in

data/api/client-server/create_room.yaml

@@ -186,7 +186,7 @@ paths:
                   with type, state_key and content keys set.
 
                   Takes precedence over events set by `preset`, but gets
-                  overriden by `name` and `topic` keys.
+                  overridden by `name` and `topic` keys.
                 items:
                   type: object
                   title: StateEvent

data/api/client-server/old_sync.yaml

@@ -257,7 +257,7 @@ paths:
                             If the user is a member of the room this will be a
                             list of the most recent messages for this room. If
                             the user has left the room this will be the
-                            messages that preceeded them leaving. This array
+                            messages that preceded them leaving. This array
                             will consist of at most `limit` elements.
                           items:
                             type: object

data/api/client-server/room_initial_sync.yaml

@@ -116,7 +116,7 @@ paths:
                       If the user is a member of the room this will be a
                       list of the most recent messages for this room. If
                       the user has left the room this will be the
-                      messages that preceeded them leaving. This array
+                      messages that preceded them leaving. This array
                       will consist of at most `limit` elements.
                     items:
                       type: object

data/api/identity/v2_email_associations.yaml

@@ -63,7 +63,7 @@ paths:
             $ref: "definitions/sid.yaml"
         400:
           description: |
-            An error ocurred.  Some possible errors are:
+            An error occurred.  Some possible errors are:
 
             - `M_INVALID_EMAIL`: The email address provided was invalid.
             - `M_EMAIL_SEND_ERROR`: The validation email could not be sent.

data/api/identity/v2_phone_associations.yaml

@@ -63,7 +63,7 @@ paths:
             $ref: "definitions/sid.yaml"
         400:
           description: |
-            An error ocurred. Some possible errors are:
+            An error occurred. Some possible errors are:
 
             - `M_INVALID_ADDRESS`: The phone number provided was invalid.
             - `M_SEND_ERROR`: The validation SMS could not be sent.

data/api/identity/v2_ping.yaml

@@ -34,7 +34,7 @@ paths:
         To discover that an identity server is available at a specific URL,
         this endpoint can be queried and will return an empty object.
 
-        This is primarly used for auto-discovery and health check purposes
+        This is primarily used for auto-discovery and health check purposes
         by entities acting as a client for the identity server.
       operationId: pingV2
       responses:

data/api/identity/v2_store_invite.yaml

@@ -88,7 +88,7 @@ paths:
                   The Matrix room alias for the room to which the user is
                   invited. This should be retrieved from the `m.room.canonical_alias`
                   state event.
-                example: "#somewhere:exmaple.org"
+                example: "#somewhere:example.org"
               room_avatar_url:
                 type: string
                 description: |-
@@ -150,7 +150,7 @@ paths:
               }
         400:
           description: |
-            An error has occured.
+            An error has occurred.
 
             If the 3pid is already bound to a Matrix user ID, the error code
             will be `M_THREEPID_IN_USE`.  If the medium is unsupported, the

data/api/server-server/wellknown.yaml

@@ -48,6 +48,6 @@ paths:
               "m.server":
                 type: string
                 description: |-
-                  The server name to delegate server-server communciations to, with optional
+                  The server name to delegate server-server communications to, with optional
                   port. The delegated server name uses the same grammar as
                   [server names in the appendices](/appendices/#server-name).

meta/releasing.md

@@ -6,7 +6,7 @@ machinery works.
 
 ## Prerequisites / preparation
 
-First, can we even release the spec? This stage is mostly preperation work needed
+First, can we even release the spec? This stage is mostly preparation work needed
 to ensure a consistent and reliable specification.
 
 1. Ensure `main` is committed with all the spec changes you expect to be there.

proposals/1442-state-resolution.md

@@ -85,7 +85,7 @@ of end users, though not strictly essential. These include:
 *   Banning and changing power levels should "do the right thing", i.e. end
     users shouldn't have to take extra steps to make the state resolution
     produce the "right" results.
-*   Minimise occurences of "state resets". Servers will sometimes point to
+*   Minimise occurrences of "state resets". Servers will sometimes point to
     disparate parts of the room DAG (due to a variety of reasons), which ideally
     should not result in changes in the state.
 *   Be efficient; state resolution can happen a lot on some large rooms. Ideally
@@ -177,7 +177,7 @@ would include B.
 (This is also the root cause of the "Hotel California" issue, where left users
 get spontaneously rejoined to rooms. This happens when a user has a sequence of
 memberships changes of the form: leave (A), join (B) and then another leave (C).
-In the current algorithm a resoluton of A and C would pick A, and a resolution
+In the current algorithm a resolution of A and C would pick A, and a resolution
 of A and B would then pick B, i.e. the join. This means that a suitably forked
 graph can reset the state to B. This is fixed if when resolving A and C we also
 consider B, since its in the auth chain of C.)
@@ -334,7 +334,7 @@ unconflicted events, it is unclear exactly which combination is best (and least
 manipulatable by malicious servers).
 
 Care has to be taken if we want to ensure that old auth events that appear in
-the _auth chain difference_ can't supercede unconflicted state entries.
+the _auth chain difference_ can't supersede unconflicted state entries.
 
 Due to auth chain differences being added to the resolved states during
 _iterative auth checks_, we therefore need to re-apply the unconflicted state

proposals/1717-key_verification.md

@@ -51,7 +51,7 @@ To initiate a key verification process, Bob's device sends a `to_device` event
 to one of Alice's devices with the `type` set to `m.key.verification.start`.
 This may either be done in response to an `m.key.verification.request` message,
 or can be done independently.  If it is done in response to an
-`m.key.verification.request` messsage, it should use the same `transaction_id`
+`m.key.verification.request` message, it should use the same `transaction_id`
 as the `m.key.verification.request` message.  If Alice's device receives an
 `m.key.verification.start` message in response to an
 `m.key.verification.request` message, it should send an
@@ -97,7 +97,7 @@ Properties:
 - `from_device` (string): Required. The device ID of the device starting the
   verification process.
 - `transaction_id` (string): Required. An identifier for the verification
-  process.  If this message is sent in reponse to an
+  process.  If this message is sent in response to an
   `m.key.verification.request` event, then it must use the same
   `transaction_id` as the one given in the `m.key.verification.request`.
 - `next_method` (string): Optional. If the selected verification method only
@@ -139,7 +139,7 @@ Properties:
     device, an `m.key.verification.cancel` message with `code` set to
     `m.accepted` is sent to the other devices
 - `reason` (string): human-readable reason for cancelling.  This should only be
-  used if the recieving client does not understand the code given in the `code`
+  used if the receiving client does not understand the code given in the `code`
   property.
 
 Verification methods may define their own additional cancellation codes.

proposals/1730-cs-api-in-login-response.md

@@ -68,7 +68,7 @@ Alternative solutions might include:
 
 ### Have all users on one homeserver
 
-In many situtations, it might be more appropriate to have a single homeserver,
+In many situations, it might be more appropriate to have a single homeserver,
 so users' MXids would look like `@user:ac.cdl` instead of
 `@user:eng.ac.cdl`.
 

proposals/1772-groups-as-rooms.md

@@ -1,6 +1,6 @@
 # Proposal for Matrix "spaces" (formerly known as "groups as rooms (take 2)")
 
-This MSC, and related proposals, supercede
+This MSC, and related proposals, supersede
 [MSC1215](https://github.com/matrix-org/matrix-doc/issues/1215).
 
 ## Background and objectives
@@ -345,7 +345,7 @@ None at present.
   using smaller spaces).
 
 * The requirement that `m.space.parent` links be ignored unless the sender has a
-  high PL in the parent room could lead to suprising effects where a parent
+  high PL in the parent room could lead to surprising effects where a parent
   link suddenly ceases to take effect because a user loses their PL in the
   parent room. This is mitigated in the general case by honouring the parent
   link when there is a corresponding `m.space.child` event, however it remains

proposals/1819-remove-presence-lists.md

@@ -17,7 +17,7 @@ This MSC addresses
 
 Presence lists seem like a good fit for ['MSC1769: Extensible profiles as
 rooms'](https://github.com/matrix-org/matrix-doc/pull/1769) proposal, meaning
-that the current design will most likely be superceded.
+that the current design will most likely be superseded.
 
 Additionally, no major client has implemented the behaviour to date and the
 only server implementation of presence lists (Synapse) auto-accepts invites
@@ -51,5 +51,5 @@ there today.
 
 This is a common sense attempt to remove unused portions of the spec ahead of
 an r0 release. It does not suggest that the ability to subscribe to the
-presence of others is undesirable and assumes that this behvaiour will return
+presence of others is undesirable and assumes that this behaviour will return
 again in some form.

proposals/1954-remove-prev_event-from-essential-keys-list.md

@@ -73,5 +73,5 @@ precedent that the federation can deviate from the spec.
 
 ## Conclusions
 Removing ```prev_content``` is pragmatic response to the current situation. It
-alligns the federation and the spec, and does so in a way that removes
-unecessary overhead.
+aligns the federation and the spec, and does so in a way that removes
+unnecessary overhead.

proposals/1960-integrations-openid.md

@@ -22,7 +22,7 @@ the integration manager which might be running it.
 The protocol sequence defined here is based upon the previous discussion in the Element Web
 issue tracker: https://github.com/vector-im/element-web/issues/7153
 
-It is proposed that after the capabilities negotation, the widget can ask the client for
+It is proposed that after the capabilities negotiation, the widget can ask the client for
 an OpenID Connect credential object so it can pass it along to its backend for validation.
 The request SHOULD result in the user being prompted to confirm that the widget can have
 their information. Because of this user interaction, it's not always possible for the user
@@ -174,7 +174,7 @@ Prior to this proposal, widgets could use an undocumented `scalar_token` paramet
 send it to the widget. Clients typically chose to send it if the widget's URL matched a whitelist for URLs
 the client trusts. With the widget specification as written, widgets cannot rely on this behaviour.
 
-Widgets may wish to look into cookies and other storage techniques to avoid continously requesting
+Widgets may wish to look into cookies and other storage techniques to avoid continuously requesting
 credentials. Widgets should also look into [MSC1961](https://github.com/matrix-org/matrix-doc/pull/1961)
 for information on how to properly verify the OpenID Connect credentials it will be receiving. The
 widget is ultimately responsible for how it deals with the credentials, though the author recommends

proposals/2134-identity-hash-lookup.md

@@ -107,7 +107,7 @@ GET /_matrix/identity/v2/hash_details
 The name `lookup_pepper` was chosen in order to account for pepper values
 being returned for other endpoints in the future. The contents of
 `lookup_pepper` MUST match the regular expression `[a-zA-Z0-9]+`, whether
-hashing is being performed or not. When no hashing is occuring, a valid
+hashing is being performed or not. When no hashing is occurring, a valid
 pepper value of at least length 1 is still required.
 
 If hashing, the client appends the pepper to the end of the 3PID string,

proposals/2140-terms-of-service-2.md

@@ -11,7 +11,7 @@ Managers.
 Requirements for this proposal are:
  * ISes and IMs should be able to give multiple documents a user must agree to
    abide by
- * Each document shoud be versioned
+ * Each document should be versioned
  * ISes and IMs must, for each request that they handle, know that the user
    making the request has agreed to their data being used. This need not be
    absolute proof (we will always have to trust that the client actually

proposals/2229-rebind-existing-3pid.md

@@ -7,7 +7,7 @@ homeserver, and another for binding to an identity server. These new
 endpoints will allow the homeserver to enforce rules on emails that already
 exist on the homeserver, only when modifying homeserver email, while only
 needing to forward requests when binding to an identity server. This removes
-the problem MSC2229 is trying to solve, and it is thus made obselete.
+the problem MSC2229 is trying to solve, and it is thus made obsolete.
 
 ---
 

proposals/2230-identity-server-account-data.md

@@ -5,7 +5,7 @@ login time and then used for the lifetime of a login session. If users wish to
 specify a custom one, they must do so each time they log in on every client.
 Once they have chosen an Identity Server to advertise their 3PIDs on, it would
 be normal that they would wish to continue using this Identity Server for all
-Identity requests in their account accross all clients. This proposal aims to
+Identity requests in their account across all clients. This proposal aims to
 make this easier.
 
 ## Proposal
@@ -68,4 +68,4 @@ if they gained control of any of a user's logins.
 This makes the ID server an account setting which means it persists between
 logins. The intention would be to phase out clients ever asking for an ID
 Server URL at registration or login: this will be much easier for users to
-understand whilst still retaining the flexibilty for those who want it.
+understand whilst still retaining the flexibility for those who want it.

proposals/2265-email-lowercase.md

@@ -85,7 +85,7 @@ make e-mail addresses go through a full case folding before storing them.
 
 The need for case folding in services on the Internet doesn't seem to be very
 large currently (probably due to its young age), therefore there seem to be only
-a few third-party implementation librairies out there. However, both
+a few third-party implementation libraries out there. However, both
 [Go](https://godoc.org/golang.org/x/text/cases#Fold), [Python
 2](https://docs.python.org/2/library/stringprep.html#stringprep.map_table_b3)
 and [Python 3](https://docs.python.org/3/library/stdtypes.html#str.casefold)

proposals/2324-when-to-ship.md

@@ -87,7 +87,7 @@ To clarify:
 ### Specific examples outside of the client-server API
 
 There are some instances where a change might be made outside of the client-server API,
-which is where much of this proposal is targetted. The general spirit of the process
+which is where much of this proposal is targeted. The general spirit of the process
 should be followed where possible, if implementations decide to work ahead of spec releases.
 
 #### Room versions

proposals/2472-symmetric-ssss.md

@@ -51,7 +51,7 @@ is able to store data.
   2. store the `iv` and `mac` in the `m.secret_storage.key.[key ID]`
      account-data.
 
-* The `passthrough` property specified in the "Enconding the recovery key for
+* The `passthrough` property specified in the "Encoding the recovery key for
   server-side storage via MSC1946" section of MSC1219 is removed.  The primary
   purpose of that property was to allow easy migration of pre-MSC1946 backups,
   so that users could reuse the backup recovery key as the Secret Storage key

proposals/2540-stricter-event-validation.md

@@ -13,7 +13,7 @@ the inclusive range of `[-(2^53) + 1, (2^53) - 1]`, which matches the requiremen
 not explicit, but all floats are invalid.
 
 It is worth mentioning that there are common extensions to JSON which produce 
-invalid JSON according to the Matrix specification; some programming langauges
+invalid JSON according to the Matrix specification; some programming languages
 even support these by default. One common additional feature is handling
 "special" float values: `Infinity`, `-Infinity`, and `NaN`.
 

proposals/2582-remove-mimetype-from-encrypted-file.md

@@ -4,7 +4,7 @@
 ## Proposal
 The example in the spec currently lists `mimetype` in the [examples for `EncryptedFile`](https://matrix.org/docs/spec/client_server/r0.6.1#extensions-to-m-message-msgtypes) but not in
 the object definition. As that is duplicate information of the `info` block of file events, the
-mimetype should just be removed alltogether.
+mimetype should just be removed altogether.
 
 
 ## Potential issues

proposals/2674-event-relationships.md

@@ -133,10 +133,10 @@ we already have.  So, we'll show inconsistent data until we backfill the gap.
    time, so by the time your server comes back there won't be any more reactions
    pulling the missing ones in.
  * Could we also ask the server, after a gap, to provide all the relations which
-   happened during the gap to events whose root preceeded the gap.
+   happened during the gap to events whose root preceded the gap.
    * "Give me all relations which happened between this set of
      forward-extremities when I lost sync, and the point i've rejoined the DAG,
-     for events which preceeded the gap"?
+     for events which preceded the gap"?
    * Would be hard to auth all the relations which this api coughed up.
      * We could auth them based only the auth events of the relation, except we
        lose the context of the nearby DAG which we'd have if it was a normal

proposals/2758-textual-id-grammar.md

@@ -52,5 +52,5 @@ for user-visible strings.
 ### Rationale
 
  * Avoiding non-ascii characters sidesteps any issues with homoglyphs or
-   altenative encodings of the same characters.
+   alternative encodings of the same characters.
  * Avoiding upper-case character sidesteps any concerns over case-sensitivity.

proposals/2765-widget-avatars.md

@@ -5,7 +5,7 @@ for a favicon-like experience. This proposal introduces such a concept.
 
 ## Proposal
 
-A new optional paramater named `avatar_url` is added to the widget definition. This parameter is
+A new optional parameter named `avatar_url` is added to the widget definition. This parameter is
 an MXC URI to an image clients can use to associate with the widget, likely alongside the `name`
 and/or `title`.
 

proposals/2778-appservice-login.md

@@ -92,7 +92,7 @@ could store this information rather than calling `POST /login` at all. This does
 - Quite a few appservices which only support unencrypted messaging do not use/store the `device_id`/`access_token` from a register call.
   In the event that an appservice eventually gains the ability to support encryption, they would be unable to fetch a new `device_id`/
   `access_token` for any existing users (as `/register` would fail for an existing user).
-- If user tokens were lost or exposed, there is no way to programattically create new access tokens for these users.
+- If user tokens were lost or exposed, there is no way to programmatically create new access tokens for these users.
 - Finally, if a user was registered externally and the appservice would like to masquerade as it, it would be unable to fetch
   an access token for that user.
 

proposals/2844-global-versioning.md

@@ -168,7 +168,7 @@ instead of the inspired system proposed here. So, why shouldn't we use semantic
 
 2. It has potential for causing very high major version numbers. Though largely an aesthetic concern,
    it can be hard to market Matrix v45 (or even Matrix v4) to potential ecosystem adopters due to
-   the apparant unstable-ness of the specification. Similarly, the major version is used for advertising
+   the apparent unstable-ness of the specification. Similarly, the major version is used for advertising
    purposes which could be confusing or overly noisy to say there's a major version every few
    releases. By instead staying in the 1.x series for a long period of time, the specification appears
    stable and easy to work with, attracting potential adopters and making that 2.0 release feel all

proposals/2858-Multiple-SSO-Identity-Providers.md

@@ -95,7 +95,7 @@ of an object with the following fields:
 
    [Rationale: this grammar is based on the
    [MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758), removing the
-   requirements for a namespaced heirarchy. In
+   requirements for a namespaced hierarchy. In
    [discussion](https://github.com/matrix-org/matrix-doc/pull/2858#discussion_r565506802),
    it was agreed that a separate registry was seen as important for a
    lightweight process by which implementations can agree on identifiers. The
@@ -137,7 +137,7 @@ For a reauthentication operation, the server implementation is free to choose
 any suitable IdP to authenticate the user. (Often, this will simply be
 the IdP that the user logged in with.)
 
-### Proposed initial identifiers for the `brand` indentifier
+### Proposed initial identifiers for the `brand` identifier
 
 The following identifiers are proposed for the initial content of the `brand`
 identifier registry. The descriptions are guidelines to help server

proposals/3288-pass_room_type_in_3pid_invite.md

@@ -33,7 +33,7 @@ Content-Type: application/json
   "address": "foo@example.com",
   "room_id": "!something:example.org",
   "sender": "@bob:example.com",
-  "room_alias": "#somewhere:exmaple.org",
+  "room_alias": "#somewhere:example.org",
   "room_avatar_url": "mxc://example.org/s0meM3dia",
   "room_join_rules": "public",
   "room_name": "The Bob Project",

scripts/proposals.js

@@ -113,7 +113,7 @@ getIssues().then(processIssues);
 /**
  * Rather than just store the complete issue, we'll extract
  * only the pieces we need.
- * We'll also do some transformation of the issues, jsut because
+ * We'll also do some transformation of the issues, just because
  * it's easier to do in JS than in the template.
  */
 function getProposalFromIssue(issue) {