Merge pull request #1650 from mujx/use-example-org

Use example.org on examples instead of domain.com which is a real domain
pull/977/head
Matthew Hodgson 6 years ago committed by GitHub
commit 8a949af23a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

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

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

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

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

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

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

@ -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"],

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

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

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

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

@ -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."
}

@ -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)
@@xn--eby-7cd:domain.com (Punycode with additional '@')
@ebаy:example.org (Cyrillic 'a', everything else English)
@@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
``@Bob:domain.com``. It is up to ``domain.com`` to map ``Bob`` to ``bob`` in
where ``@alice:example.com`` tries to speak with ``@bob:example.org`` using
``@Bob:example.org``. It is up to ``example.org`` to map ``Bob`` to ``bob`` in
a sensible way.

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

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

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

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

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

@ -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"]
}
}

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

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

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

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

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

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

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

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

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

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

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

@ -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: ``https://matrix.to/#/!somewhere:domain.com``
* Permalink by room: ``https://matrix.to/#/!somewhere:domain.com/$event:example.org``
* Permalink by room alias: ``https://matrix.to/#/#somewhere:domain.com/$event:example.org``
* Room alias: ``https://matrix.to/#/#somewhere:example.org``
* Room: ``https://matrix.to/#/!somewhere:example.org``
* Permalink by room: ``https://matrix.to/#/!somewhere:example.org/$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>`_.

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

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

@ -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 |
| State: |
| Room ID: !qporfwt:matrix.org |
| Servers: matrix.org, domain.com |
| Members: |
| - @alice:matrix.org |
| - @bob:domain.com |
| Messages: |
| - @alice:matrix.org |
| Content: { JSON object } |
|...................................|
....................................
| Shared Data |
| State: |
| Room ID: !qporfwt:matrix.org |
| Servers: matrix.org, example.org |
| Members: |
| - @alice:matrix.org |
| - @bob:example.org |
| Messages: |
| - @alice:matrix.org |
| 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 |

@ -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",
"sender": "@example:domain.com",
"room_id": "!jEsUZKDJdhlrceRyVU:example.org",
"sender": "@example:example.org",
"type": "m.room.message",
"unsigned": {
"age": 1234

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

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

Loading…
Cancel
Save