Remove h7 and h8 headings

pull/977/head
Will 4 years ago committed by Richard van der Hoff
parent f1711ff3e4
commit a974bdaf45

@ -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:
</mx-reply>
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`

@ -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

@ -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:

Loading…
Cancel
Save