Remove RST alert directives, replace with simple Markdown formatting

data/api/client-server/administrative_contact.yaml

@@ -96,11 +96,11 @@ paths:
         This endpoint is deprecated in favour of the more specific ``/3pid/add``
         and ``/3pid/bind`` endpoints.
 
-        .. Note::
-           Previously this endpoint supported a ``bind`` parameter. This parameter
-           has been removed, making this endpoint behave as though it was ``false``.
-           This results in this endpoint being an equivalent to ``/3pid/bind`` rather
-           than dual-purpose.
+        **Note:**
+        Previously this endpoint supported a ``bind`` parameter. This parameter
+        has been removed, making this endpoint behave as though it was ``false``.
+        This results in this endpoint being an equivalent to ``/3pid/bind`` rather
+        than dual-purpose.
       operationId: post3PIDs
       deprecated: true
       security:

data/api/client-server/content-repo.yaml

@@ -347,11 +347,11 @@ paths:
         Get information about a URL for the client. Typically this is called when a
         client sees a URL in a message and wants to render a preview for the user.
 
-        .. Note::
-          Clients should consider avoiding this endpoint for URLs posted in encrypted
-          rooms. Encrypted rooms often contain more sensitive information the users
-          do not want to share with the homeserver, and this can mean that the URLs
-          being shared should also not be shared with the homeserver.
+        **Note:**
+        Clients should consider avoiding this endpoint for URLs posted in encrypted
+        rooms. Encrypted rooms often contain more sensitive information the users
+        do not want to share with the homeserver, and this can mean that the URLs
+        being shared should also not be shared with the homeserver.
 
       operationId: getUrlPreview
       produces: ["application/json"]

data/api/client-server/directory.yaml

@@ -132,12 +132,12 @@ paths:
         Servers may choose to implement additional access control checks here, for instance that
         room aliases can only be deleted by their creator or a server administrator.
 
-        .. Note::
-           Servers may choose to update the ``alt_aliases`` for the ``m.room.canonical_alias``
-           state event in the room when an alias is removed. Servers which choose to update the
-           canonical alias event are recommended to, in addition to their other relevant permission
-           checks, delete the alias and return a successful response even if the user does not
-           have permission to update the ``m.room.canonical_alias`` event.
+        **Note:**
+        Servers may choose to update the ``alt_aliases`` for the ``m.room.canonical_alias``
+        state event in the room when an alias is removed. Servers which choose to update the
+        canonical alias event are recommended to, in addition to their other relevant permission
+        checks, delete the alias and return a successful response even if the user does not
+        have permission to update the ``m.room.canonical_alias`` event.
 
       operationId: deleteRoomAlias
       security:
@@ -184,10 +184,10 @@ paths:
         such as allowing server administrators to view aliases regardless of
         membership.
 
-        .. Note::
-           Clients are recommended not to display this list of aliases prominently
-           as they are not curated, unlike those listed in the ``m.room.canonical_alias``
-           state event.
+        **Note:**
+        Clients are recommended not to display this list of aliases prominently
+        as they are not curated, unlike those listed in the ``m.room.canonical_alias``
+        state event.
 
       operationId: getLocalAliases
       security:

data/api/server-server/backfill.yaml

@@ -64,13 +64,13 @@ paths:
             A transaction containing the PDUs that preceded the given event(s), including the given
             event(s), up to the given limit.
 
-            .. Note::
-               Though the PDU definitions require that ``prev_events`` and ``auth_events`` be limited
-               in number, the response of backfill MUST NOT be validated on these specific restrictions.
+            **Note:**
+            Though the PDU definitions require that ``prev_events`` and ``auth_events`` be limited
+            in number, the response of backfill MUST NOT be validated on these specific restrictions.
 
-               Due to historical reasons, it is possible that events which were previously accepted
-               would now be rejected by these limitations. The events should be rejected per usual by
-               the ``/send``, ``/get_missing_events``, and remaining endpoints.
+            Due to historical reasons, it is possible that events which were previously accepted
+            would now be rejected by these limitations. The events should be rejected per usual by
+            the ``/send``, ``/get_missing_events``, and remaining endpoints.
           schema:
             $ref: "definitions/unlimited_pdu_transaction.yaml"
   "/get_missing_events/{roomId}":

data/api/server-server/invites-v2.yaml

@@ -31,9 +31,9 @@ paths:
     put:
       summary: Invites a remote user to a room
       description: |-
-        .. Note::
-           This API is nearly identical to the v1 API with the exception of the request
-           body being different, and the response format fixed.
+        **Note:**
+        This API is nearly identical to the v1 API with the exception of the request
+        body being different, and the response format fixed.
 
         Invites a remote user to a room. Once the event has been  signed by both the inviting
         homeserver and the invited homeserver, it can be sent to all of the servers in the

data/api/server-server/joins-v1.yaml

@@ -171,14 +171,13 @@ paths:
               "errcode": "M_NOT_FOUND",
               "error": "Unknown room",
             }
-  
+
   "/send_join/{roomId}/{eventId}":
     put:
       summary: Submit a signed join event to a resident server
       description: |-
-        .. Note::
-           Servers should instead prefer to use the v2 ``/send_join``
-           endpoint.
+        **Note:**
+        Servers should instead prefer to use the v2 ``/send_join`` endpoint.
 
         Submits a signed join event to the resident server for it
         to accept it into the room's graph. Note that events have

data/api/server-server/joins-v2.yaml

@@ -33,9 +33,9 @@ paths:
     put:
       summary: Submit a signed join event to a resident server
       description: |-
-        .. Note::
-           This API is nearly identical to the v1 API with the
-           exception of the response format being fixed.
+        **Note:**
+        This API is nearly identical to the v1 API with the
+        exception of the response format being fixed.
 
         This endpoint is preferred over the v1 API as it provides
         a more standarised response format. Senders which receive

data/api/server-server/leaving-v1.yaml

@@ -143,9 +143,8 @@ paths:
     put:
       summary: Submit a signed leave event to a resident server
       description: |-
-        .. Note::
-           Servers should instead prefer to use the v2 ``/send_leave``
-           endpoint.
+        **Note:**
+        Servers should instead prefer to use the v2 ``/send_leave`` endpoint.
 
         Submits a signed leave event to the resident server for it
         to accept it into the room's graph. Note that events have

data/api/server-server/leaving-v2.yaml

@@ -33,9 +33,9 @@ paths:
     put:
       summary: Submit a signed leave event to a resident server
       description: |-
-        .. Note::
-           This API is nearly identical to the v1 API with the
-           exception of the response format being fixed.
+        **Note:**
+        This API is nearly identical to the v1 API with the
+        exception of the response format being fixed.
 
         This endpoint is preferred over the v1 API as it provides
         a more standarised response format. Senders which receive

data/event-schemas/schema/m.room.power_levels.yaml

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

data/event-schemas/schema/m.room.server_acl.yaml

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