wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

typos

Browse source
This commit is contained in:
Neil Johnson 2019-04-15 17:08:09 +01:00 • committed by GitHub
parent b41fbc86b6
commit 911fb94ea0
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -48,7 +48,7 @@ retrospectively to describe the de-facto redaction algorithm.
## Potential issues ## Potential issues
It is theoretically possible that a closed federation could exist whose servers It is theoretically possible that a closed federation could exist whose servers
do follow the spec as is. This MSC would render those servers uncompliant with do follow the spec as is. This MSC would render those servers non-compliant with
the spec. On balance this seems unlikely and in the worst case those the spec. On balance this seems unlikely and in the worst case those
implementors could add the change to a subsequent room version, eventually implementors could add the change to a subsequent room version, eventually
reaching spec consistency as older room versions are deprecated. reaching spec consistency as older room versions are deprecated.
@ -57,8 +57,8 @@ Another scenario is that a client may redact events according to the spec as is
and persist prev_content through the redaction, thereby diverting from that on and persist prev_content through the redaction, thereby diverting from that on
the server(s). Client authors will have to update their code to drop the server(s). Client authors will have to update their code to drop
```prev_content``` - however, given that prev_content should not be used in ```prev_content``` - however, given that prev_content should not be used in
important calculations and/or visualisations, this ought to be relatively important calculations and/or visualisations, this ought to be a relatively
uninvaisive change. non-invasive change.
## Security considerations ## Security considerations