Replace misuses of 'plaintext' with 'cleartext' and clarify spoiler docs (#1306)
This commit is contained in:
parent
b2cc836649
commit
c8242eeb35
4 changed files with 10 additions and 9 deletions
|
@ -0,0 +1 @@
|
||||||
|
Various clarifications throughout the specification.
|
|
@ -1945,14 +1945,14 @@ parent event, for example.
|
||||||
{{% /boxes/note %}}
|
{{% /boxes/note %}}
|
||||||
|
|
||||||
To allow the server to aggregate and find child events for a parent, the `m.relates_to`
|
To allow the server to aggregate and find child events for a parent, the `m.relates_to`
|
||||||
key of an event MUST be included in the plaintext copy of the event. It cannot be
|
key of an event MUST be included in the cleartext portion of the event. It cannot be
|
||||||
exclusively recorded in the encrypted payload as the server cannot decrypt the event
|
exclusively recorded in the encrypted payload as the server cannot decrypt the event
|
||||||
for processing.
|
for processing.
|
||||||
|
|
||||||
{{% boxes/warning %}}
|
{{% boxes/warning %}}
|
||||||
If an encrypted event contains an `m.relates_to` in its payload, it should be
|
If an encrypted event contains an `m.relates_to` in its payload, it should be
|
||||||
ignored and instead favour the plaintext `m.relates_to` copy (including when there
|
ignored and instead favour the cleartext `m.relates_to` copy (including when there
|
||||||
is no plaintext copy). This is to ensure the client's behaviour matches the server's
|
is no cleartext copy). This is to ensure the client's behaviour matches the server's
|
||||||
capability to handle relationships.
|
capability to handle relationships.
|
||||||
{{% /boxes/warning %}}
|
{{% /boxes/warning %}}
|
||||||
|
|
||||||
|
|
|
@ -327,11 +327,11 @@ If a reason were to be supplied, it would look like:
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
When sending a spoiler, clients SHOULD provide the plain text fallback in the `body`
|
When sending a spoiler, clients SHOULD provide the fallback in the `body` as shown above
|
||||||
as shown above (including the reason). The fallback SHOULD omit the spoiler text verbatim
|
(including the reason). The fallback SHOULD NOT include the text containing spoilers since
|
||||||
since `body` might show up in text-only clients or in notifications. To prevent spoilers
|
`body` might show up in text-only clients or in notifications. To prevent spoilers showing up in
|
||||||
showing up in such situations, clients are strongly encouraged to first upload the plaintext
|
such situations, clients are strongly encouraged to first upload the text containing spoilers
|
||||||
to the media repository then reference the MXC URI in a markdown-style link, as shown above.
|
to the media repository, then reference the MXC URI in a markdown-style link, as shown above.
|
||||||
|
|
||||||
Clients SHOULD render spoilers differently with some sort of disclosure. For example, the
|
Clients SHOULD render spoilers differently with some sort of disclosure. For example, the
|
||||||
client could blur the actual text and ask the user to click on it for it to be revealed.
|
client could blur the actual text and ask the user to click on it for it to be revealed.
|
||||||
|
|
|
@ -280,7 +280,7 @@ request.
|
||||||
|
|
||||||
#### `none`
|
#### `none`
|
||||||
|
|
||||||
This algorithm performs plaintext lookups on the identity server.
|
This algorithm performs cleartext lookups on the identity server.
|
||||||
Typically this algorithm should not be used due to the security concerns
|
Typically this algorithm should not be used due to the security concerns
|
||||||
of unhashed identifiers, however some scenarios (such as LDAP-backed
|
of unhashed identifiers, however some scenarios (such as LDAP-backed
|
||||||
identity servers) prevent the use of hashed identifiers. Identity
|
identity servers) prevent the use of hashed identifiers. Identity
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue