From 01cd41de6886bc1562d218c2bdf01a3872730573 Mon Sep 17 00:00:00 2001 From: Aaron Raimist Date: Tue, 28 Dec 2021 10:17:49 -0600 Subject: [PATCH] Add GitHub Action to check spelling (#3591) Signed-off-by: Aaron Raimist --- .github/_typos.toml | 12 ++++++++++++ .github/workflows/spell-check.yaml | 15 +++++++++++++++ .../newsfragments/3492.clarification | 2 +- changelogs/legacy/client_server.rst | 2 +- data/api/client-server/create_room.yaml | 2 +- data/api/client-server/old_sync.yaml | 2 +- data/api/client-server/room_initial_sync.yaml | 2 +- data/api/identity/v2_email_associations.yaml | 2 +- data/api/identity/v2_phone_associations.yaml | 2 +- data/api/identity/v2_ping.yaml | 2 +- data/api/identity/v2_store_invite.yaml | 4 ++-- data/api/server-server/wellknown.yaml | 2 +- meta/releasing.md | 2 +- proposals/1442-state-resolution.md | 6 +++--- proposals/1717-key_verification.md | 6 +++--- proposals/1730-cs-api-in-login-response.md | 2 +- proposals/1772-groups-as-rooms.md | 4 ++-- proposals/1819-remove-presence-lists.md | 4 ++-- ...-remove-prev_event-from-essential-keys-list.md | 4 ++-- proposals/1960-integrations-openid.md | 4 ++-- proposals/2134-identity-hash-lookup.md | 2 +- proposals/2140-terms-of-service-2.md | 2 +- proposals/2229-rebind-existing-3pid.md | 2 +- proposals/2230-identity-server-account-data.md | 4 ++-- proposals/2265-email-lowercase.md | 2 +- proposals/2324-when-to-ship.md | 2 +- proposals/2472-symmetric-ssss.md | 2 +- proposals/2540-stricter-event-validation.md | 2 +- .../2582-remove-mimetype-from-encrypted-file.md | 2 +- proposals/2674-event-relationships.md | 4 ++-- proposals/2758-textual-id-grammar.md | 2 +- proposals/2765-widget-avatars.md | 2 +- proposals/2778-appservice-login.md | 2 +- proposals/2844-global-versioning.md | 2 +- proposals/2858-Multiple-SSO-Identity-Providers.md | 4 ++-- proposals/3288-pass_room_type_in_3pid_invite.md | 2 +- scripts/proposals.js | 2 +- 37 files changed, 74 insertions(+), 47 deletions(-) create mode 100644 .github/_typos.toml create mode 100644 .github/workflows/spell-check.yaml diff --git a/.github/_typos.toml b/.github/_typos.toml new file mode 100644 index 00000000..38078207 --- /dev/null +++ b/.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" \ No newline at end of file diff --git a/.github/workflows/spell-check.yaml b/.github/workflows/spell-check.yaml new file mode 100644 index 00000000..e8a2a99e --- /dev/null +++ b/.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 \ No newline at end of file diff --git a/changelogs/client_server/newsfragments/3492.clarification b/changelogs/client_server/newsfragments/3492.clarification index 1ad1e83d..efa0cf84 100644 --- a/changelogs/client_server/newsfragments/3492.clarification +++ b/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 diff --git a/changelogs/legacy/client_server.rst b/changelogs/legacy/client_server.rst index 6f8aee1c..c5b8fae9 100644 --- a/changelogs/legacy/client_server.rst +++ b/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 diff --git a/data/api/client-server/create_room.yaml b/data/api/client-server/create_room.yaml index c5369108..2a7a47ec 100644 --- a/data/api/client-server/create_room.yaml +++ b/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 diff --git a/data/api/client-server/old_sync.yaml b/data/api/client-server/old_sync.yaml index 57305416..bfbbe840 100644 --- a/data/api/client-server/old_sync.yaml +++ b/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 diff --git a/data/api/client-server/room_initial_sync.yaml b/data/api/client-server/room_initial_sync.yaml index aa028a16..df212066 100644 --- a/data/api/client-server/room_initial_sync.yaml +++ b/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 diff --git a/data/api/identity/v2_email_associations.yaml b/data/api/identity/v2_email_associations.yaml index 08e8c9fa..600fea41 100644 --- a/data/api/identity/v2_email_associations.yaml +++ b/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. diff --git a/data/api/identity/v2_phone_associations.yaml b/data/api/identity/v2_phone_associations.yaml index 72680064..85b523e4 100644 --- a/data/api/identity/v2_phone_associations.yaml +++ b/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. diff --git a/data/api/identity/v2_ping.yaml b/data/api/identity/v2_ping.yaml index 61f5d35b..e056e321 100644 --- a/data/api/identity/v2_ping.yaml +++ b/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: diff --git a/data/api/identity/v2_store_invite.yaml b/data/api/identity/v2_store_invite.yaml index c3fbc7ca..1cb7acdd 100644 --- a/data/api/identity/v2_store_invite.yaml +++ b/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 diff --git a/data/api/server-server/wellknown.yaml b/data/api/server-server/wellknown.yaml index 54da2c75..c1a060d9 100644 --- a/data/api/server-server/wellknown.yaml +++ b/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). diff --git a/meta/releasing.md b/meta/releasing.md index 36f01d2d..e76ae60c 100644 --- a/meta/releasing.md +++ b/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. diff --git a/proposals/1442-state-resolution.md b/proposals/1442-state-resolution.md index 848fe931..db9ad1d3 100644 --- a/proposals/1442-state-resolution.md +++ b/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 diff --git a/proposals/1717-key_verification.md b/proposals/1717-key_verification.md index 429e3a97..be0bcfe4 100644 --- a/proposals/1717-key_verification.md +++ b/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. diff --git a/proposals/1730-cs-api-in-login-response.md b/proposals/1730-cs-api-in-login-response.md index f3a498ca..2520f82f 100644 --- a/proposals/1730-cs-api-in-login-response.md +++ b/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`. diff --git a/proposals/1772-groups-as-rooms.md b/proposals/1772-groups-as-rooms.md index 1d431f84..254c297c 100644 --- a/proposals/1772-groups-as-rooms.md +++ b/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 diff --git a/proposals/1819-remove-presence-lists.md b/proposals/1819-remove-presence-lists.md index f82ebac5..9bac5720 100644 --- a/proposals/1819-remove-presence-lists.md +++ b/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. diff --git a/proposals/1954-remove-prev_event-from-essential-keys-list.md b/proposals/1954-remove-prev_event-from-essential-keys-list.md index ccaab34f..6b83005b 100644 --- a/proposals/1954-remove-prev_event-from-essential-keys-list.md +++ b/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. diff --git a/proposals/1960-integrations-openid.md b/proposals/1960-integrations-openid.md index 6f33001f..2fc6e444 100644 --- a/proposals/1960-integrations-openid.md +++ b/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 diff --git a/proposals/2134-identity-hash-lookup.md b/proposals/2134-identity-hash-lookup.md index 2fdda034..86ef8a72 100644 --- a/proposals/2134-identity-hash-lookup.md +++ b/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, diff --git a/proposals/2140-terms-of-service-2.md b/proposals/2140-terms-of-service-2.md index 6bff8ebb..c7a4fbf8 100644 --- a/proposals/2140-terms-of-service-2.md +++ b/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 diff --git a/proposals/2229-rebind-existing-3pid.md b/proposals/2229-rebind-existing-3pid.md index 398e6513..3d32a4bd 100644 --- a/proposals/2229-rebind-existing-3pid.md +++ b/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. --- diff --git a/proposals/2230-identity-server-account-data.md b/proposals/2230-identity-server-account-data.md index 19fb3062..09067468 100644 --- a/proposals/2230-identity-server-account-data.md +++ b/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. diff --git a/proposals/2265-email-lowercase.md b/proposals/2265-email-lowercase.md index e4fe5313..97c09e00 100644 --- a/proposals/2265-email-lowercase.md +++ b/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) diff --git a/proposals/2324-when-to-ship.md b/proposals/2324-when-to-ship.md index 47ed5247..c3081cad 100644 --- a/proposals/2324-when-to-ship.md +++ b/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 diff --git a/proposals/2472-symmetric-ssss.md b/proposals/2472-symmetric-ssss.md index 7fe9f179..1f9115d1 100644 --- a/proposals/2472-symmetric-ssss.md +++ b/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 diff --git a/proposals/2540-stricter-event-validation.md b/proposals/2540-stricter-event-validation.md index 31c4c39b..d77cdd8e 100644 --- a/proposals/2540-stricter-event-validation.md +++ b/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`. diff --git a/proposals/2582-remove-mimetype-from-encrypted-file.md b/proposals/2582-remove-mimetype-from-encrypted-file.md index 3b1f83c7..93d6a6ff 100644 --- a/proposals/2582-remove-mimetype-from-encrypted-file.md +++ b/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 diff --git a/proposals/2674-event-relationships.md b/proposals/2674-event-relationships.md index 95f077ba..49962157 100644 --- a/proposals/2674-event-relationships.md +++ b/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 diff --git a/proposals/2758-textual-id-grammar.md b/proposals/2758-textual-id-grammar.md index 626f84ae..4e99a9f1 100644 --- a/proposals/2758-textual-id-grammar.md +++ b/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. diff --git a/proposals/2765-widget-avatars.md b/proposals/2765-widget-avatars.md index a9030d29..48d6d208 100644 --- a/proposals/2765-widget-avatars.md +++ b/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`. diff --git a/proposals/2778-appservice-login.md b/proposals/2778-appservice-login.md index fd509ab8..9a60b55f 100644 --- a/proposals/2778-appservice-login.md +++ b/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. diff --git a/proposals/2844-global-versioning.md b/proposals/2844-global-versioning.md index ce4b299d..930e810b 100644 --- a/proposals/2844-global-versioning.md +++ b/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 diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 1e49d070..43dd42d0 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/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 diff --git a/proposals/3288-pass_room_type_in_3pid_invite.md b/proposals/3288-pass_room_type_in_3pid_invite.md index 408573c0..af3a8507 100644 --- a/proposals/3288-pass_room_type_in_3pid_invite.md +++ b/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", diff --git a/scripts/proposals.js b/scripts/proposals.js index cb810a97..9a2d2b4e 100644 --- a/scripts/proposals.js +++ b/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) {