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