Remove RST alert directives, replace with simple Markdown formatting

This commit is contained in:
Will 2021-01-27 10:44:02 -08:00 committed by Richard van der Hoff
parent 00c6a866e2
commit c7cf90abfa
11 changed files with 68 additions and 70 deletions

View file

@ -31,16 +31,16 @@ description: |-
``m.room.power_levels`` event, or if the room contains no ``m.room.power_levels``
event.
.. NOTE::
**Note:**
As noted above, in the absence of an ``m.room.power_levels`` event, the
``state_default`` is 0, and all users are considered to have power level 0.
That means that **any** member of the room can send an
``m.room.power_levels`` event, changing the permissions in the room.
As noted above, in the absence of an ``m.room.power_levels`` event, the
``state_default`` is 0, and all users are considered to have power level 0.
That means that **any** member of the room can send an
``m.room.power_levels`` event, changing the permissions in the room.
Server implementations should therefore ensure that each room has an
``m.room.power_levels`` event as soon as it is created. See also the
documentation of the ``/createRoom`` API.
Server implementations should therefore ensure that each room has an
``m.room.power_levels`` event as soon as it is created. See also the
documentation of the ``/createRoom`` API.
properties:
content:

View file

@ -22,26 +22,26 @@ description: |-
#. If the server name matches an entry in the ``allow`` list, allow.
#. Otherwise, deny.
.. Note::
Server ACLs do not restrict the events relative to the room DAG via authorisation
rules, but instead act purely at the network layer to determine which servers are
allowed to connect and interact with a given room.
**Note:**
Server ACLs do not restrict the events relative to the room DAG via authorisation
rules, but instead act purely at the network layer to determine which servers are
allowed to connect and interact with a given room.
.. WARNING::
Failing to provide an ``allow`` rule of some kind will prevent **all**
servers from participating in the room, including the sender. This renders
the room unusable. A common allow rule is ``[ "*" ]`` which would still
permit the use of the ``deny`` list without losing the room.
.. WARNING::
All compliant servers must implement server ACLs. However, legacy or noncompliant
servers exist which do not uphold ACLs, and these MUST be manually appended to
the denied hosts list when setting an ACL to prevent them from leaking events from
banned servers into a room. Currently, the only way to determine noncompliant hosts is
to check the ``prev_events`` of leaked events, therefore detecting servers which
are not upholding the ACLs. Server versions can also be used to try to detect hosts that
will not uphold the ACLs, although this is not comprehensive. Server ACLs were added
in Synapse v0.32.0, although other server implementations and versions exist in the world.
**Warning:**
Failing to provide an ``allow`` rule of some kind will prevent **all**
servers from participating in the room, including the sender. This renders
the room unusable. A common allow rule is ``[ "*" ]`` which would still
permit the use of the ``deny`` list without losing the room.
**Warning:**
All compliant servers must implement server ACLs. However, legacy or noncompliant
servers exist which do not uphold ACLs, and these MUST be manually appended to
the denied hosts list when setting an ACL to prevent them from leaking events from
banned servers into a room. Currently, the only way to determine noncompliant hosts is
to check the ``prev_events`` of leaked events, therefore detecting servers which
are not upholding the ACLs. Server versions can also be used to try to detect hosts that
will not uphold the ACLs, although this is not comprehensive. Server ACLs were added
in Synapse v0.32.0, although other server implementations and versions exist in the world.
allOf:
- $ref: core-event-schema/state_event.yaml
type: object
@ -55,7 +55,7 @@ properties:
deny. Defaults to true if missing or otherwise not a boolean.
This is strongly recommended to be set to ``false`` as servers running
with IP literal names are strongly discouraged in order to require
with IP literal names are strongly discouraged in order to require
legitimate homeservers to be backed by a valid registered domain name.
allow:
type: array