From a974bdaf450ba815e14bc9e70c39acad619f7349 Mon Sep 17 00:00:00 2001 From: Will Date: Tue, 9 Feb 2021 17:10:41 -0800 Subject: [PATCH] Remove h7 and h8 headings --- .../modules/instant_messaging.md | 20 ++----- content/client-server-api/modules/push.md | 56 +++++++++---------- content/client-server-api/modules/secrets.md | 2 - 3 files changed, 31 insertions(+), 47 deletions(-) diff --git a/content/client-server-api/modules/instant_messaging.md b/content/client-server-api/modules/instant_messaging.md index 6f60d5a0..8e6df01d 100644 --- a/content/client-server-api/modules/instant_messaging.md +++ b/content/client-server-api/modules/instant_messaging.md @@ -298,7 +298,7 @@ when using the `m.heroes` to calculate the name. Clients SHOULD use minimum 5 heroes to calculate room names where possible, but may use more or less to fit better with their user experience. -##### Forming relationships between events +##### Rich replies In some cases, events may wish to reference other events. This could be to form a thread of messages for the user to follow along with, or to @@ -311,14 +311,6 @@ Relationships are defined under an `m.relates_to` key in the event's `m.relates_to` key MUST NOT be covered by the encryption and instead be put alongside the encryption information held in the `content`. -###### Rich replies - -Users may wish to reference another message when forming their own -message, and clients may wish to better embed the referenced message for -the user to have a better context for the conversation being had. This -sort of embedding another message in a message is known as a "rich -reply", or occasionally just a "reply". - A rich reply is formed through use of an `m.relates_to` relation for `m.in_reply_to` where a single key, `event_id`, is used to reference the event being replied to. The referenced event ID SHOULD belong to the @@ -351,7 +343,7 @@ An `m.in_reply_to` relationship looks like the following: } ``` -####### Fallbacks and event representation +##### Fallbacks for rich replies Some clients may not have support for rich replies and therefore need a fallback to use instead. Clients that do not support rich replies should @@ -385,7 +377,7 @@ If the related event does not have a `formatted_body`, the event's Note that the `href` in both of the anchors use a [matrix.to URI](/appendices#matrixto-navigation). -######## Stripping the fallback +###### Stripping the fallback Clients which support rich replies MUST strip the fallback from the event before rendering the event. This is because the text provided in @@ -405,7 +397,7 @@ a line is encountered without the prefix. This prefix is known as the To strip the fallback on the `formatted_body`, the client should remove the entirety of the `mx-reply` tag. -######## Fallback for `m.text`, `m.notice`, and unrecognised message types +###### Fallback for `m.text`, `m.notice`, and unrecognised message types Using the prefix sequence, the first line of the related event's `body` should be prefixed with the user's ID, followed by each line being @@ -418,7 +410,7 @@ prefixed with the fallback prefix sequence. For example: The `formatted_body` uses the template defined earlier in this section. -######## Fallback for `m.emote` +###### Fallback for `m.emote` Similar to the fallback for `m.text`, each line gets prefixed with the fallback prefix sequence. However an asterisk should be inserted before @@ -441,7 +433,7 @@ asterisk is also inserted ahead of the user's ID: This is where the reply goes. -######## Fallback for `m.image`, `m.video`, `m.audio`, and `m.file` +###### Fallback for `m.image`, `m.video`, `m.audio`, and `m.file` The related event's `body` would be a file name, which may not be very descriptive. The related event should additionally not have a `format` diff --git a/content/client-server-api/modules/push.md b/content/client-server-api/modules/push.md index 90546050..e98d7eda 100644 --- a/content/client-server-api/modules/push.md +++ b/content/client-server-api/modules/push.md @@ -183,25 +183,14 @@ dictionary with a `set_tweak` key whose value is the name of the tweak to set. It may also have a `value` key which is the value to which it should be set. -Actions that have no parameters are represented as a string. Otherwise, -they are represented as a dictionary with a key equal to their name and -other keys as their parameters, e.g. -`{ "set_tweak": "sound", "value": "default" }` - -####### Tweaks - -The `set_tweak` action is used to add an entry to the 'tweaks' -dictionary that is sent in the notification request to the Push Gateway. The following tweaks are defined: -`sound` -A string representing the sound to be played when this notification +* `sound`: A string representing the sound to be played when this notification arrives. A value of `default` means to play a default sound. A device may choose to alert the user by some other means if appropriate, eg. vibration. -`highlight` -A boolean representing whether or not this message should be highlighted +* `highlight`: A boolean representing whether or not this message should be highlighted in the UI. This will normally take the form of presenting the message in a different colour and/or style. The UI might also be adjusted to draw particular attention to the room in which the event occurred. If a @@ -214,6 +203,11 @@ applications and Push Gateways may agree on additional tweaks. For example, a tweak may be added to specify how to flash the notification light on a mobile device. +Actions that have no parameters are represented as a string. Otherwise, +they are represented as a dictionary with a key equal to their name and +other keys as their parameters, e.g. +`{ "set_tweak": "sound", "value": "default" }` + ###### Conditions `override` and `underride` rules MAY have a list of 'conditions'. All @@ -265,22 +259,22 @@ the push rule disabled. way, but instead have predefined conditions. In the cases of `room` and `sender` rules, the `rule_id` of the rule determines its behaviour. -###### Predefined Rules +##### Predefined Rules Homeservers can specify "server-default rules" which operate at a lower priority than "user-defined rules". The `rule_id` for all server-default rules MUST start with a dot (".") to identify them as "server-default". The following server-default rules are specified: -####### Default Override Rules +###### Default Override Rules -######## `.m.rule.master` +**`.m.rule.master`** Matches all events. This can be enabled to turn off all push notifications other than those generated by override rules set by the user. By default this rule is disabled. -Definition +Definition: ```json { @@ -294,7 +288,7 @@ Definition } ``` -######## `.m.rule.suppress_notices` +**`.m.rule.suppress_notices`** Matches messages with a `msgtype` of `notice`. @@ -318,7 +312,7 @@ Definition: } ``` -######## `.m.rule.invite_for_me` +**`.m.rule.invite_for_me`** Matches any invites to a new room for this user. @@ -356,7 +350,7 @@ Definition: } ``` -######## `.m.rule.member_event` +**`.m.rule.member_event`** Matches any `m.room.member_event`. @@ -380,7 +374,7 @@ Definition: } ``` -######## `.m.rule.contains_display_name` +**`.m.rule.contains_display_name`** Matches any message whose content is unencrypted and contains the user's current display name in the room in which it was sent. @@ -410,7 +404,7 @@ Definition: } ``` -######## `.m.rule.tombstone` +**`.m.rule.tombstone`** Matches any state event whose type is `m.room.tombstone`. This is intended to notify users of a room when it is upgraded, similar to what @@ -444,7 +438,7 @@ Definition: } ``` -######## `.m.rule.roomnotif` +**`.m.rule.roomnotif`** Matches any message whose content is unencrypted and contains the text `@room`, signifying the whole room should be notified of the event. @@ -476,9 +470,9 @@ Definition: } ``` -####### Default Content Rules +###### Default Content Rules -######## `.m.rule.contains_user_name` +**`.m.rule.contains_user_name`** Matches any message whose content is unencrypted and contains the local part of the user's Matrix ID, separated by word boundaries. @@ -504,9 +498,9 @@ Definition (as a `content` rule): } ``` -####### Default Underride Rules +###### Default Underride Rules -######## `.m.rule.call` +**`.m.rule.call`** Matches any incoming VOIP call. @@ -534,7 +528,7 @@ Definition: } ``` -######## `.m.rule.encrypted_room_one_to_one` +**`.m.rule.encrypted_room_one_to_one`** Matches any encrypted event sent in a room with exactly two members. Unlike other push rules, this rule cannot be matched against the content @@ -570,7 +564,7 @@ Definition: } ``` -######## `.m.rule.room_one_to_one` +**`.m.rule.room_one_to_one`** Matches any message sent in a room with exactly two members. @@ -602,7 +596,7 @@ Definition: } ``` -######## `.m.rule.message` +**`.m.rule.message`** Matches all chat messages. @@ -626,7 +620,7 @@ Definition: } ``` -######## `.m.rule.encrypted` +**`.m.rule.encrypted`** Matches all encrypted events. Unlike other push rules, this rule cannot be matched against the content of the event by nature of it being diff --git a/content/client-server-api/modules/secrets.md b/content/client-server-api/modules/secrets.md index 8db2bb3d..3289c936 100644 --- a/content/client-server-api/modules/secrets.md +++ b/content/client-server-api/modules/secrets.md @@ -222,8 +222,6 @@ has an `algorithm` property that indicates how to generate the key from the passphrase. Other properties of the `passphrase` property are defined by the `algorithm` specified. -####### `m.pbkdf2` - For the `m.pbkdf2` algorithm, the `passphrase` property has the following properties: