Use example.org on examples instead of domain.com which is a real domain

Signed-off-by: Konstantinos Sideris <sideris.konstantin@gmail.com>

api/client-server/administrative_contact.yaml

@@ -171,7 +171,7 @@ paths:
               address:
                 type: string
                 description: The third party address being removed.
-                example: "example@domain.com"
+                example: "example@example.org"
             required: ['medium', 'address']
       responses:
         200:

api/client-server/appservice_room_directory.yaml

@@ -59,7 +59,7 @@ paths:
           name: roomId
           description: The room ID to add to the directory.
           required: true
-          x-example: "!somewhere:domain.com"
+          x-example: "!somewhere:example.org"
         - in: body
           name: body
           required: true

api/client-server/read_markers.yaml

@@ -42,7 +42,7 @@ paths:
           name: roomId
           description: The room ID to set the read marker in for the user.
           required: true
-          x-example: "!somewhere:domain.com"
+          x-example: "!somewhere:example.org"
         - in: body
           name: body
           description: The read marker and optional read receipt locations.
@@ -55,14 +55,14 @@ paths:
                 description: |-
                   The event ID the read marker should be located at. The
                   event MUST belong to the room.
-                example: "$somewhere:domain.com"
+                example: "$somewhere:example.org"
               "m.read":
                 type: string
                 description: |-
                   The event ID to set the read receipt location at. This is
-                  equivalent to calling ``/receipt/m.read/$elsewhere:domain.com``
+                  equivalent to calling ``/receipt/m.read/$elsewhere:example.org``
                   and is provided here to save that extra call.
-                example: "$elsewhere:domain.com"
+                example: "$elsewhere:example.org"
             required: ['m.fully_read']
       responses:
         200:

api/client-server/report_content.yaml

@@ -46,7 +46,7 @@ paths:
           name: eventId
           description: The event to report.
           required: true
-          x-example: "$something:domain.com"
+          x-example: "$something:example.org"
         - in: body
           name: body
           schema:

api/server-server/backfill.yaml

@@ -20,7 +20,7 @@ host: localhost:8448
 schemes:
   - https
 basePath: /_matrix/federation/v1
-consumes: 
+consumes:
   - application/json
 produces:
   - application/json
@@ -49,7 +49,7 @@ paths:
           type: array
           items:
             type: string
-          description: The event IDs to backfill from. 
+          description: The event IDs to backfill from.
           required: true
           x-example: ["$abc123:matrix.org"]
         - in: query
@@ -118,18 +118,18 @@ paths:
                   the previous events of ``latest_events``.
                 items:
                   type: string
-                example: ["$missing_event:domain.com"]
+                example: ["$missing_event:example.org"]
               latest_events:
                 type: array
                 description: The events to retrieve the previous events for.
                 items:
                   type: string
-                example: ["$event_that_has_the_missing_event_as_a_previous_event:domain.com"]
+                example: ["$event_that_has_the_missing_event_as_a_previous_event:example.org"]
             required: ['earliest_events', 'latest_events']
       responses:
         200:
           description: |-
-            The previous events for ``latest_events``, excluding any ``earliest_events``, up to the 
+            The previous events for ``latest_events``, excluding any ``earliest_events``, up to the
             provided ``limit``.
           schema:
             type: object

api/server-server/definitions/event-schemas/m.presence_deny.yaml

@@ -18,12 +18,12 @@ description: |-
   An EDU representing a declination or revocation for the observing user
   to subscribe to the presence of the observed user.
 example: {
-  "origin": "domain.com",
+  "origin": "example.org",
   "destination": "elsewhere.org",
   "edu_type": "m.presence_deny",
   "content": {
     "observed_user": "@alice:elsewhere.org",
-    "observer_user": "@john:domain.com"
+    "observer_user": "@john:example.org"
   }
 }
 allOf:

api/server-server/definitions/event-schemas/m.receipt.yaml

@@ -69,7 +69,7 @@ allOf:
               required: ['event_ids', 'data']
           required: ['m.read']
         example: {
-          "!some_room:domain.com": {
+          "!some_room:example.org": {
             "m.read": {
               "@john:matrix.org": {
                 "event_ids": ["$read_this_event:matrix.org"],

api/server-server/definitions/unsigned_pdu.yaml

@@ -126,11 +126,11 @@ properties:
       replaces_state:
         type: string
         description: The event ID of the state event this event replaces.
-        example: "$state_event:domain.com"
+        example: "$state_event:example.org"
       prev_sender:
         type: string
         description: The sender of the replaced state event.
-        example: "@someone:domain.com"
+        example: "@someone:example.org"
       prev_content:
         type: object
         description: The content of the replaced state event.

api/server-server/event_auth.yaml

@@ -47,7 +47,7 @@ paths:
           type: string
           description: The event ID to get the auth chain of.
           required: true
-          x-example: "$helloworld:domain.com"
+          x-example: "$helloworld:example.org"
       responses:
         200:
           description: The auth chain for the event.
@@ -90,7 +90,7 @@ paths:
           type: string
           description: The event ID to compare the auth chain of.
           required: true
-          x-example: "$helloworld:domain.com"
+          x-example: "$helloworld:example.org"
         - in: body
           name: body
           schema:
@@ -127,7 +127,7 @@ paths:
                         The reason for the event being rejected.
                   required: ['reason']
                 example: {
-                  "$some_event:domain.com": {
+                  "$some_event:example.org": {
                     "reason": "auth_error"
                   }
                 }
@@ -153,7 +153,7 @@ paths:
                   after comparing the "remote auth" and "local auth" chains.
                 items:
                   type: string
-                example: ["$a_missing_event:domain.com"]
+                example: ["$a_missing_event:example.org"]
               rejects:
                 type: object
                 description: |-
@@ -173,7 +173,7 @@ paths:
                         The reason for the event being rejected.
                   required: ['reason']
                 example: {
-                  "$some_event:domain.com": {
+                  "$some_event:example.org": {
                     "reason": "auth_error"
                   }
                 }

api/server-server/events.yaml

@@ -110,14 +110,14 @@ paths:
                   of the room, and their authorization events, recursively.
                 items:
                   type: string
-                example: ["$an_event:domain.com"]
+                example: ["$an_event:example.org"]
               pdu_ids:
                 type: array
                 description: |-
                   The fully resolved state of the room at the given event.
                 items:
                   type: string
-                example: ["$an_event:domain.com"]
+                example: ["$an_event:example.org"]
             required: ['auth_chain_ids', 'pdu_ids']
   "/event/{eventId}":
     get:

api/server-server/third_party_invite.yaml

@@ -222,7 +222,7 @@ paths:
                 type: string
                 description: |-
                   The third party identifier itself. For example, an email address.
-                example: "alice@domain.com"
+                example: "alice@example.com"
               mxid:
                 type: string
                 description: The user that is now bound to the third party identifier.
@@ -245,7 +245,7 @@ paths:
                       type: string
                       description: |-
                         The third party identifier that received the invite.
-                      example: "alice@domain.com"
+                      example: "alice@example.com"
                     mxid:
                       type: string
                       description: The now-bound user ID that received the invite.

api/server-server/transactions.yaml

@@ -107,7 +107,7 @@ paths:
               200,
               {
                 "pdus": {
-                  "$successful_event:domain.com": {},
+                  "$successful_event:example.org": {},
                   "$failed_event:example.org": {
                     "error": "You are not allowed to send a message to this room."
                   }

drafts/human-id-rules.rst

@@ -66,8 +66,8 @@ In the event of a failed room alias check, well behaved homeservers MUST:
 
 Examples::
 
-  @ebаy:domain.com (Cyrillic 'a', everything else English)
+  @ebаy:example.org (Cyrillic 'a', everything else English)
-  @@xn--eby-7cd:domain.com (Punycode with additional '@')
+  @@xn--eby-7cd:example.org (Punycode with additional '@')
 
 Homeservers SHOULD NOT allow two user IDs that differ only by case. This
 SHOULD be applied based on the capitalisation rules in the CLDR dataset:
@@ -95,7 +95,7 @@ entirely Latin.
 
 User ID localparts cannot start with ``@`` so that a namespace of localparts
 beginning with ``@`` can be created. This namespace is used for user IDs which
-fail the ID checks. A failed ID could look like ``@@xn--c1yn36f:domain.com``.
+fail the ID checks. A failed ID could look like ``@@xn--c1yn36f:example.org``.
 
 If a user ID fails the check, the user ID on the event is renamed. This doesn't
 require extra work for clients, and users will see an odd user ID rather than a
@@ -128,6 +128,6 @@ Capitalisation
 --------------
 
 The capitalisation rules outlined above are nice but do not fully resolve issues
-where ``@alice:example.com`` tries to speak with ``@bob:domain.com`` using
+where ``@alice:example.com`` tries to speak with ``@bob:example.org`` using
-``@Bob:domain.com``. It is up to ``domain.com`` to map ``Bob`` to ``bob`` in
+``@Bob:example.org``. It is up to ``example.org`` to map ``Bob`` to ``bob`` in
 a sensible way.

drafts/pstn_gatewaying.txt

@@ -45,4 +45,4 @@ the Matrix specification.
 
 For SMS routing, options are:
  * Terminate traffic only (from a shared shortcode originator)
- * Two-way traffic via a VMN. To save allocating huge numbers of VMNs to Matrix users, the VMN can be allocated from a pool such that each {caller,callee} tuple is unique (but the caller number will only work from that specific callee).
+ * Two-way traffic via a VMN. To save allocating huge numbers of VMNs to Matrix users, the VMN can be allocated from a pool such that each {caller,callee} tuple is unique (but the caller number will only work from that specific callee).

event-schemas/examples/core/room_edu.json

@@ -1,4 +1,4 @@
 {
     "$ref": "event.json",
-    "room_id": "!jEsUZKDJdhlrceRyVU:domain.com"
+    "room_id": "!jEsUZKDJdhlrceRyVU:example.org"
 }

event-schemas/examples/core/room_event.json

@@ -1,8 +1,8 @@
 {
     "$ref": "event.json",
-    "event_id": "$143273582443PhrSn:domain.com",
+    "event_id": "$143273582443PhrSn:example.org",
-    "room_id": "!jEsUZKDJdhlrceRyVU:domain.com",
+    "room_id": "!jEsUZKDJdhlrceRyVU:example.org",
-    "sender": "@example:domain.com",
+    "sender": "@example:example.org",
     "origin_server_ts": 1432735824653,
     "unsigned": {
       "age": 1234

event-schemas/examples/m.fully_read

@@ -1,8 +1,8 @@
 {
   "$ref": "core/event.json",
   "type": "m.fully_read",
-  "room_id": "!somewhere:domain.com",
+  "room_id": "!somewhere:example.org",
   "content": {
-    "event_id": "$someplace:domain.com"
+    "event_id": "$someplace:example.org"
   }
 }

event-schemas/examples/m.ignored_user_list

@@ -3,7 +3,7 @@
   "type": "m.ignored_user_list",
   "content": {
     "ignored_users": {
-      "@someone:domain.com": {}
+      "@someone:example.org": {}
     }
   }
 }

event-schemas/examples/m.room.aliases

@@ -1,8 +1,8 @@
 {
   "$ref": "core/state_event.json",
-  "state_key": "domain.com",
+  "state_key": "example.org",
   "type": "m.room.aliases",
   "content": {
-    "aliases": ["#somewhere:domain.com", "#another:domain.com"]
+    "aliases": ["#somewhere:example.org", "#another:example.org"]
   }
 }

event-schemas/examples/m.room.avatar

@@ -9,6 +9,6 @@
         "mimetype": "image/jpeg",
         "size": 31037
     },
-    "url": "mxc://domain.com/JWEIFJgwEIhweiWJE"
+    "url": "mxc://example.org/JWEIFJgwEIhweiWJE"
   }
 }

event-schemas/examples/m.room.create

@@ -3,7 +3,7 @@
   "type": "m.room.create",
   "state_key": "",
   "content": {
-    "creator": "@example:domain.com",
+    "creator": "@example:example.org",
     "room_version": "1",
     "m.federate": true
   }

event-schemas/examples/m.room.member

@@ -1,10 +1,10 @@
 {
   "$ref": "core/state_event.json",
-  "state_key": "@alice:domain.com",
+  "state_key": "@alice:example.org",
   "type": "m.room.member",
   "content": {
     "membership": "join",
-    "avatar_url": "mxc://domain.com/SEsfnsuifSDFSSEF#auto",
+    "avatar_url": "mxc://example.org/SEsfnsuifSDFSSEF#auto",
     "displayname": "Alice Margatroid"
   }
 }

event-schemas/examples/m.room.member#invite_room_state

@@ -2,7 +2,7 @@
   "$ref": "m.room.member",
   "content": {
     "membership": "invite",
-    "avatar_url": "mxc://domain.com/SEsfnsuifSDFSSEF#auto",
+    "avatar_url": "mxc://example.org/SEsfnsuifSDFSSEF#auto",
     "displayname": "Alice Margatroid"
   },
   "unsigned": {

event-schemas/examples/m.room.member#third_party_invite

@@ -2,12 +2,12 @@
   "$ref": "m.room.member",
   "content": {
     "membership": "invite",
-    "avatar_url": "mxc://domain.com/SEsfnsuifSDFSSEF#auto",
+    "avatar_url": "mxc://example.org/SEsfnsuifSDFSSEF#auto",
     "displayname": "Alice Margatroid",
     "third_party_invite": {
       "display_name": "alice",
       "signed": {
-        "mxid": "@alice:domain.com",
+        "mxid": "@alice:example.org",
         "signatures": {
           "magic.forest": {
             "ed25519:3": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"

event-schemas/examples/m.room.message#m.audio

@@ -3,7 +3,7 @@
   "type": "m.room.message",
   "content": {
     "body": "Bee Gees - Stayin' Alive",
-    "url": "mxc://domain.com/ffed755USFFxlgbQYZGtryd",
+    "url": "mxc://example.org/ffed755USFFxlgbQYZGtryd",
     "info": {
       "duration": 2140786,
       "size": 1563685,

event-schemas/examples/m.room.message#m.file

@@ -9,6 +9,6 @@
       "size": 46144
     },
     "msgtype": "m.file",
-    "url": "mxc://domain.com/FHyPlCeYUSFFxlgbQYZmoEoe"
+    "url": "mxc://example.org/FHyPlCeYUSFFxlgbQYZmoEoe"
   }
 } 

event-schemas/examples/m.room.message#m.image

@@ -9,7 +9,7 @@
         "mimetype": "image/jpeg",
         "size": 31037
     },
-    "url": "mxc://domain.com/JWEIFJgwEIhweiWJE",
+    "url": "mxc://example.org/JWEIFJgwEIhweiWJE",
     "msgtype": "m.image"
   }
 }

event-schemas/examples/m.room.message#m.location

@@ -5,7 +5,7 @@
     "body": "Big Ben, London, UK",
     "geo_uri": "geo:51.5008,0.1247",
     "info": {
-      "thumbnail_url": "mxc://domain.com/FHyPlCeYUSFFxlgbQYZmoEoe",
+      "thumbnail_url": "mxc://example.org/FHyPlCeYUSFFxlgbQYZmoEoe",
       "thumbnail_info": {
         "mimetype": "image/jpeg",
         "size": 46144,

event-schemas/examples/m.room.message#m.video

@@ -3,9 +3,9 @@
   "type": "m.room.message",
   "content": {
     "body": "Gangnam Style",
-    "url": "mxc://domain.com/a526eYUSFFxlgbQYZmo442",
+    "url": "mxc://example.org/a526eYUSFFxlgbQYZmo442",
     "info": {
-      "thumbnail_url": "mxc://domain.com/FHyPlCeYUSFFxlgbQYZmoEoe",
+      "thumbnail_url": "mxc://example.org/FHyPlCeYUSFFxlgbQYZmoEoe",
       "thumbnail_info": {
         "mimetype": "image/jpeg",
         "size": 46144,

event-schemas/examples/m.room.pinned_events

@@ -3,6 +3,6 @@
   "type": "m.room.pinned_events",
   "state_key": "",
   "content": {
-    "pinned": ["$someevent:domain.com"]
+    "pinned": ["$someevent:example.org"]
   }
 }

specification/appendices/identifier_grammar.rst

@@ -352,14 +352,14 @@ a view for the user to participate in the room.
 
 Examples of matrix.to URIs are:
 
-* Room alias: ``https://matrix.to/#/#somewhere:domain.com``
+* Room alias: ``https://matrix.to/#/#somewhere:example.org``
-* Room: ``https://matrix.to/#/!somewhere:domain.com``
+* Room: ``https://matrix.to/#/!somewhere:example.org``
-* Permalink by room: ``https://matrix.to/#/!somewhere:domain.com/$event:example.org``
+* Permalink by room: ``https://matrix.to/#/!somewhere:example.org/$event:example.org``
-* Permalink by room alias: ``https://matrix.to/#/#somewhere:domain.com/$event:example.org``
+* Permalink by room alias: ``https://matrix.to/#/#somewhere:example.org/$event:example.org``
 * User: ``https://matrix.to/#/@alice:example.org``
-* Group: ``https://matrix.to/#/+example:domain.com``
+* Group: ``https://matrix.to/#/+example:example.org``
 
 .. Note::
    Room ID permalinks are unroutable as there is no reliable domain to send requests
    to upon receipt of the permalink. Clients should do their best route Room IDs to
-   where they need to go, however they should also be aware of `issue #1579 <https://github.com/matrix-org/matrix-doc/issues/1579>`_.
+   where they need to go, however they should also be aware of `issue #1579 <https://github.com/matrix-org/matrix-doc/issues/1579>`_.

specification/application_service_api.rst

@@ -169,7 +169,7 @@ An example registration file for an IRC-bridging application service is below:
     url: "http://127.0.0.1:1234"
     as_token: "30c05ae90a248a4188e620216fa72e349803310ec83e2a77b34fe90be6081f46"
     hs_token: "312df522183efd404ec1cd22d2ffa4bbc76a8c1ccf541dd692eef281356bb74e"
-    sender_localpart: "_irc_bot" # Will result in @_irc_bot:domain.com
+    sender_localpart: "_irc_bot" # Will result in @_irc_bot:example.org
     namespaces:
       users:
         - exclusive: true
@@ -352,7 +352,7 @@ An example request would be::
 
    ::
 
-    PUT /_matrix/client/r0/rooms/!somewhere:domain.com/send/m.room.message/txnId?ts=1534535223283
+    PUT /_matrix/client/r0/rooms/!somewhere:example.org/send/m.room.message/txnId?ts=1534535223283
     Authorization: Bearer YourApplicationServiceTokenHere
 
     Content: The event to send, as per the Client-Server API.

specification/client_server_api.rst

@@ -1333,7 +1333,7 @@ Care should be taken to avoid setting the wrong ``state key``::
 The ``state_key`` is often used to store state about individual users, by using
 the user ID as the ``state_key`` value. For example::
 
-  PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Adomain.com
+  PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Aexample.org
   { "animal" : "cat", "reason": "fluffy" }
 
 In some cases, there may be no need for a ``state_key``, so it can be omitted::

specification/index.rst

@@ -277,7 +277,7 @@ the structure of a room ID.
 The following conceptual diagram shows an
 ``m.room.message`` event being sent to the room ``!qporfwt:matrix.org``::
 
-       { @alice:matrix.org }                             { @bob:domain.com }
+       { @alice:matrix.org }                             { @bob:example.org }
                |                                                 ^
                |                                                 |
       [HTTP POST]                                  [HTTP GET]
@@ -288,7 +288,7 @@ The following conceptual diagram shows an
                V                                                 |
        +------------------+                          +------------------+
        |   homeserver     |                          |   homeserver     |
-       |   matrix.org     |                          |   domain.com     |
+       |   matrix.org     |                          |   example.org    |
        +------------------+                          +------------------+
                |                                                 ^
                |         [HTTP PUT]                              |
@@ -300,18 +300,18 @@ The following conceptual diagram shows an
                          Transaction-layer metadata
                          PKI Authorization header
 
-                     ...................................
+                     ....................................
-                    |           Shared Data             |
+                    |           Shared Data              |
-                    | State:                            |
+                    | State:                             |
-                    |   Room ID: !qporfwt:matrix.org    |
+                    |   Room ID: !qporfwt:matrix.org     |
-                    |   Servers: matrix.org, domain.com |
+                    |   Servers: matrix.org, example.org |
-                    |   Members:                        |
+                    |   Members:                         |
-                    |    - @alice:matrix.org            |
+                    |    - @alice:matrix.org             |
-                    |    - @bob:domain.com              |
+                    |    - @bob:example.org              |
-                    | Messages:                         |
+                    | Messages:                          |
-                    |   - @alice:matrix.org             |
+                    |   - @alice:matrix.org              |
-                    |     Content: { JSON object }      |
+                    |     Content: { JSON object }       |
-                    |...................................|
+                    |....................................|
 
 Federation maintains *shared data structures* per-room between multiple home
 servers. The data is split into ``message events`` and ``state events``.
@@ -363,11 +363,11 @@ that are in the room that can be used to join via.
 ::
 
         HTTP GET
-   #matrix:domain.com      !aaabaa:matrix.org
+   #matrix:example.org      !aaabaa:matrix.org
            |                    ^
            |                    |
     _______V____________________|____
-   |          domain.com            |
+   |          example.org           |
    | Mappings:                      |
    | #matrix >> !aaabaa:matrix.org  |
    | #golf   >> !wfeiofh:sport.com  |

specification/modules/end_to_end_encryption.rst

@@ -308,7 +308,7 @@ Example:
     "content": {
       "body": "something-important.jpg",
       "file": {
-        "url": "mxc://domain.com/FHyPlCeYUSFFxlgbQYZmoEoe",
+        "url": "mxc://example.org/FHyPlCeYUSFFxlgbQYZmoEoe",
         "mimetype": "image/jpeg",
         "v": "v2",
         "key": {
@@ -340,7 +340,7 @@ Example:
             "kty": "oct"
           },
           "mimetype": "image/jpeg",
-          "url": "mxc://domain.com/pmVJxyxGlmxHposwVSlOaEOv",
+          "url": "mxc://example.org/pmVJxyxGlmxHposwVSlOaEOv",
           "v": "v2"
         },
         "thumbnail_info": {
@@ -353,10 +353,10 @@ Example:
       },
       "msgtype": "m.image"
     },
-    "event_id": "$143273582443PhrSn:domain.com",
+    "event_id": "$143273582443PhrSn:example.org",
     "origin_server_ts": 1432735824653,
-    "room_id": "!jEsUZKDJdhlrceRyVU:domain.com",
+    "room_id": "!jEsUZKDJdhlrceRyVU:example.org",
-    "sender": "@example:domain.com",
+    "sender": "@example:example.org",
     "type": "m.room.message",
     "unsigned": {
         "age": 1234

specification/modules/instant_messaging.rst

@@ -432,7 +432,7 @@ The ``formatted_body`` should use the following template:
 
   <mx-reply>
     <blockquote>
-      <a href="https://matrix.to/#/!somewhere:domain.com/$event:domain.com">In reply to</a>
+      <a href="https://matrix.to/#/!somewhere:example.org/$event:example.org">In reply to</a>
       <a href="https://matrix.to/#/@alice:example.org">@alice:example.org</a>
       <br />
       <!-- This is where the related event's HTML would be. -->
@@ -498,7 +498,7 @@ is also inserted ahead of the user's ID:
 
   <mx-reply>
     <blockquote>
-      <a href="https://matrix.to/#/!somewhere:domain.com/$event:domain.com">In reply to</a>
+      <a href="https://matrix.to/#/!somewhere:example.org/$event:example.org">In reply to</a>
       * <a href="https://matrix.to/#/@alice:example.org">@alice:example.org</a>
       <br />
       <!-- This is where the related event's HTML would be. -->
@@ -526,7 +526,7 @@ the output looks similar to the following::
 
   <mx-reply>
     <blockquote>
-      <a href="https://matrix.to/#/!somewhere:domain.com/$event:domain.com">In reply to</a>
+      <a href="https://matrix.to/#/!somewhere:example.org/$event:example.org">In reply to</a>
       <a href="https://matrix.to/#/@alice:example.org">@alice:example.org</a>
       <br />
       sent a file.

specification/modules/read_markers.rst

@@ -47,7 +47,7 @@ The read markers API can additionally update the user's read receipt (``m.read``
 location in the same operation as setting the fully read marker location. This is
 because read receipts and read markers are commonly updated at the same time,
 and therefore the client might wish to save an extra HTTP call. Providing an
-``m.read`` location performs the same task as a request to ``/receipts/m.read/$event:domain.com``.
+``m.read`` location performs the same task as a request to ``/receipts/m.read/$event:example.org``.
 
 {{read_markers_cs_http_api}}
 
@@ -56,7 +56,7 @@ Server behaviour
 The server MUST prevent clients from setting ``m.fully_read`` directly in
 room account data. The server must additionally ensure that it treats the
 presence of ``m.read`` in the ``/read_markers`` request the same as how it
-would for a request to ``/receipts/m.read/$event:domain.com``.
+would for a request to ``/receipts/m.read/$event:example.org``.
 
 Upon updating the ``m.fully_read`` event due to a request to ``/read_markers``,
 the server MUST send the updated account data event through to the client via