* typoes

* Appease the faulty spellcheck on the json too

Co-authored-by: Travis Ralston <travisr@matrix.org>
pull/977/head
Matthew Hodgson 3 years ago committed by GitHub
parent 4a9c236572
commit 20aa44bd13
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -1194,7 +1194,7 @@ The event signing algorithm should emit the following signed event:
"sender": "@u:domain", "sender": "@u:domain",
"signatures": { "signatures": {
"domain": { "domain": {
"ed25519:1": "Wm+VzmOUOz08Ds+0NTWb1d4CZrVsJSikkeRxh6aCcUwu6pNC78FunoD7KNWzqFn241eYHYMGCA5McEiVPdhzBA" "ed25519:1": "Wm+VzmOUOz08Ds+0NTWb1d4CZrVsJSikkeRxh6aCcUwu6pNC78FunoD7KNWzqFn241eYHYMGCA5McEiVPdhzBY"
} }
}, },
"unsigned": { "unsigned": {

@ -244,7 +244,7 @@ re-enter their password, but for homeservers which delegate to an SSO
server, this means redirecting to the authentication server during server, this means redirecting to the authentication server during
user-interactive auth. user-interactive auth.
The implemementation of this is based on the [Fallback](#fallback) mechanism for The implementation of this is based on the [Fallback](#fallback) mechanism for
user-interactive auth. user-interactive auth.
#### Client behaviour #### Client behaviour

@ -319,7 +319,7 @@ tables to mine the addresses. Similarly, clients which support the
`none` algorithm should consider at least warning the user of the risks `none` algorithm should consider at least warning the user of the risks
in sending identifiers in plain text to the identity server. in sending identifiers in plain text to the identity server.
Addresses are still potentially reversable using a calculated rainbow Addresses are still potentially reversible using a calculated rainbow
table given some identifiers, such as phone numbers, common email table given some identifiers, such as phone numbers, common email
address domains, and leaked addresses are easily calculated. For address domains, and leaked addresses are easily calculated. For
example, phone numbers can have roughly 12 digits to them, making them example, phone numbers can have roughly 12 digits to them, making them

@ -42,7 +42,7 @@ Room version 4 uses the same algorithms defined in [room version
Room version 3 generated event IDs that were difficult for client Room version 3 generated event IDs that were difficult for client
implementations which were not encoding the event ID to function in implementations which were not encoding the event ID to function in
those rooms. It additionally raised concern due to the `/` character those rooms. It additionally raised concern due to the `/` character
being interpretted differently by some reverse proxy software, and being interpreted differently by some reverse proxy software, and
generally made administration harder. generally made administration harder.
{{% /boxes/rationale %}} {{% /boxes/rationale %}}

@ -32,7 +32,7 @@ as do the versions v6 is based upon.
### Authorization rules ### Authorization rules
{{% added-in this=true %}} For checks perfomed upon `m.room.member` events, a {{% added-in this=true %}} For checks performed upon `m.room.member` events, a
new point for `membership=knock` is added. new point for `membership=knock` is added.
Events must be signed by the server denoted by the `sender` key. Events must be signed by the server denoted by the `sender` key.

Loading…
Cancel
Save