Upgrade typos CI action (#4135)

pull/4014/merge
Kévin Commaille 2 weeks ago committed by GitHub
parent 72e694ba0b
commit d6edcbd946
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

@ -8,3 +8,4 @@ OTKs = "OTKs"
[default.extend-words]
OTK = "OTK"
OTKs = "OTKs"
Iy = "Iy"

@ -14,6 +14,6 @@ jobs:
uses: actions/checkout@v4
- name: Check spelling of proposals
uses: crate-ci/typos@9be36f97fdbe645ee9a12449fb13aca856c2516a
uses: crate-ci/typos@f2c1f08a7b3c1b96050cb786baaa2a94797bdb7d # v1.20.10
with:
config: ${{github.workspace}}/.github/_typos.toml

@ -174,7 +174,7 @@ certificates comes with a number of downsides.
Configuring a working, federating homeserver is a process fraught with
pitfalls. This proposal adds the requirement to obtain a signed certificate to
that process. Even with modern intiatives such as Let's Encrypt, this is
that process. Even with modern initiatives such as Let's Encrypt, this is
another procedure requiring manual intervention across several moving parts.
On the other hand: obtaining an SSL certificate should be a familiar process to

@ -88,7 +88,7 @@ right encoding.
A potential extension would be to change *all* Base64 encodings to be
URL-safe. This would address the inconsistency. However, it feels like a
large job which would span the entire matrix ecosystem (far larger than
updating clients to URL-encode their URL prarameters), and again the
updating clients to URL-encode their URL parameters), and again the
situation would be confusing while the transition was in progress.
2. Incompleteness. Event IDs are certainly not the only identifier which can

@ -34,7 +34,7 @@ way that Homeservers do.
## Proposal
Throuhgout this proposal, $prefix will be used to refer to the prefix of the
Throughout this proposal, $prefix will be used to refer to the prefix of the
API in question, ie. `/_matrix/identity/v2` for the IS API and
`/_matrix/integrations/v1` for the IM API.

@ -51,7 +51,7 @@ property should contains a `key` that indicates the annotation being
applied. For example, when reacting with emojis, the `key` contains the emoji
being used.
An event annotating another with the thumbs-up emoji would therefore have the following `m.relates_to` propperty:
An event annotating another with the thumbs-up emoji would therefore have the following `m.relates_to` property:
```json
"m.relates_to": {

@ -40,7 +40,7 @@ the room administrator's understanding of their room's function.
Another possible approach is to have servers prevent sending faulty ACL events by preventing their
local clients from doing so, such as by rejecting redaction requests. This doesn't solve the issue
over federation, but can reduce the liklihood of such events making it to the federation layer. This
over federation, but can reduce the likelihood of such events making it to the federation layer. This
is what Synapse currently does to help mitigate the issue. This is only effective if the server (or
client, locally) implements it - it's common for both clients and servers to forget to add these checks
during development, leading to occasional room breakage. This MSC instead tries to resolve the issue

@ -152,7 +152,7 @@ the room was created.
## Alternatives
We chose the current `/timestamp_to_event` route because it sounded like the
easist path forward to bring it to fruition and get some real-world experience.
easiest path forward to bring it to fruition and get some real-world experience.
And was on our mind during the [initial discussion](https://docs.google.com/document/d/1KCEmpnGr4J-I8EeaVQ8QJZKBDu53ViI7V62y5BzfXr0/edit#bookmark=id.qu9k9wje9pxm) because there was some prior art with a [WIP
implementation](https://github.com/matrix-org/synapse/pull/9445/commits/91b1b3606c9fb9eede0a6963bc42dfb70635449f)
from @erikjohnston. The alternatives haven't been thrown out for a particular

Loading…
Cancel
Save