archive
/
matrix-spec
mirror of https://github.com/matrix-org/matrix-spec
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix non-permanent links in MSCs to withstand time (#3422)

Browse Source 
As "unstable" changes and "latest" becomes no more, these sorts of links should be updated to reference the approximate section they intended to reference at the time of writing.

This change tries to link up the relevant bits for the time of the proposal, though it's not a perfect match. Some MSCs were brought into the spec before an API version could be assigned to the "old" text, so github permalinks are used instead.
pull/977/head
Travis Ralston 3 years ago committed by GitHub
parent 95d850c418
commit f295e828dc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
10 changed files with 37 additions and 37 deletions
Show Stats Download Patch File Download Diff File

2
proposals/1442-state-resolution.md
Unescape Escape View File

@ -571,7 +571,7 @@ rejected.
[^1]: In the current room protocol these are: the create event, power levels, [^1]: In the current room protocol these are: the create event, power levels,
membership, join rules and third party invites. See the membership, join rules and third party invites. See the
[spec](https://matrix.org/docs/spec/server_server/unstable.html#pdu-fields). [spec](https://github.com/matrix-org/matrix-doc/blob/7cb918407dc8c505c67c750578c63b43042c8425/specification/server_server_api.rst#41pdu-fields).
[^2]: In the current protocol these are: power levels, kicks, bans and join [^2]: In the current protocol these are: power levels, kicks, bans and join
rules. rules.

2
proposals/1708-well-known-for-federation.md
Unescape Escape View File

@ -17,7 +17,7 @@ with a `.well-known` lookup.
## Proposal ## Proposal
For reference, the current [specification for resolving server For reference, the current [specification for resolving server
names](https://matrix.org/docs/spec/server_server/unstable.html#resolving-server-names) names](https://github.com/matrix-org/matrix-doc/blob/6dab4b28f80f5beeb1d4f475ddc624cf9e7ad085/specification/server_server_api.rst#21resolving-server-names)
is as follows: is as follows:
1. If the hostname is an IP literal, then that IP address should be used, 1. If the hostname is an IP literal, then that IP address should be used,

4
proposals/1711-x509-for-federation.md
Unescape Escape View File

@ -65,7 +65,7 @@ approach for servers whose TLS certificates fail validation.
However, this fallback will be strictly time-limited, and Matrix S2S spec r0 However, this fallback will be strictly time-limited, and Matrix S2S spec r0
will not accept self-signed certificates, nor will it include the will not accept self-signed certificates, nor will it include the
`tls_fingerprints` property of the `tls_fingerprints` property of the
[`/_matrix/key/v2`](https://matrix.org/docs/spec/server_server/unstable.html#retrieving-server-keys) [`/_matrix/key/v2`](https://github.com/matrix-org/matrix-doc/blob/6dab4b28f80f5beeb1d4f475ddc624cf9e7ad085/specification/server_server_api.rst#23retrieving-server-keys)
endpoints. Synapse 1.0 will not accept self-signed certificates by default. endpoints. Synapse 1.0 will not accept self-signed certificates by default.
The `matrix.org` team will proactively attempt to reach out to homeserver The `matrix.org` team will proactively attempt to reach out to homeserver
@ -97,7 +97,7 @@ intercepted by a MitM who can control the DNS response for the `SRV` record
(perhaps via cache-poisoning or falsifying DNS responses). (perhaps via cache-poisoning or falsifying DNS responses).
This will be in line with the current This will be in line with the current
[requirements](https://matrix.org/docs/spec/server_server/unstable.html#resolving-server-names) [requirements](https://github.com/matrix-org/matrix-doc/blob/6dab4b28f80f5beeb1d4f475ddc624cf9e7ad085/specification/server_server_api.rst#21resolving-server-names)
in the Federation API specification for the `Host`, and by implication, the TLS in the Federation API specification for the `Host`, and by implication, the TLS
Server Name Indication <sup id="a2">[2](#f2)</sup>. It is also consistent with Server Name Indication <sup id="a2">[2](#f2)</sup>. It is also consistent with
the recommendations of the recommendations of

2
proposals/1719-olm_unwedging.md
Unescape Escape View File

@ -26,7 +26,7 @@ already created one for that given device in the past 1 hour.
Clients may wish to take steps to mitigate the loss of the undecryptable Clients may wish to take steps to mitigate the loss of the undecryptable
messages. For example, megolm sessions that were sent using the old session messages. For example, megolm sessions that were sent using the old session
would have been lost, so the client can send would have been lost, so the client can send
[`m.room_key_request`](https://matrix.org/docs/spec/client_server/latest.html#m-room-key-request) [`m.room_key_request`](https://matrix.org/docs/spec/client_server/r0.6.1.html#m-room-key-request)
messages to re-request any megolm sessions that it is unable to decrypt. messages to re-request any megolm sessions that it is unable to decrypt.
The spec currently says, "If a client has multiple sessions established with The spec currently says, "If a client has multiple sessions established with

6
proposals/1819-remove-presence-lists.md
Unescape Escape View File

@ -35,9 +35,9 @@ CS API: Remove
/_matrix/client/r0/presence/list/{userId}](https://matrix.org/docs/spec/client_server/r0.4.0.html#get-matrix-client-r0-presence-list-userid) /_matrix/client/r0/presence/list/{userId}](https://matrix.org/docs/spec/client_server/r0.4.0.html#get-matrix-client-r0-presence-list-userid)
SS API: Remove SS API: Remove
* [m.presence_invite](https://matrix.org/docs/spec/server_server/unstable.html#m-presence-invite-schema) * [m.presence_invite](https://github.com/matrix-org/matrix-doc/blob/8b65da1cf6fce5f657a2a46b5c6c8bcc24d32ae3/api/server-server/definitions/event-schemas/m.presence_invite.yaml)
* [m.presence_accept](https://matrix.org/docs/spec/server_server/unstable.html#m-presence-accept-schema) * [m.presence_accept](https://github.com/matrix-org/matrix-doc/blob/8b65da1cf6fce5f657a2a46b5c6c8bcc24d32ae3/api/server-server/definitions/event-schemas/m.presence_accept.yaml)
* [m.presence_deny](https://matrix.org/docs/spec/server_server/unstable.html#m-presence-deny-schema) * [m.presence_deny](https://github.com/matrix-org/matrix-doc/blob/8b65da1cf6fce5f657a2a46b5c6c8bcc24d32ae3/api/server-server/definitions/event-schemas/m.presence_deny.yaml)
## Tradeoffs ## Tradeoffs

2
proposals/1954-remove-prev_event-from-essential-keys-list.md
Unescape Escape View File

@ -27,7 +27,7 @@ implementations) have not implemented the bug and already omit
## Tradeoffs ## Tradeoffs
When sending events over federation the events are [hashed and When sending events over federation the events are [hashed and
signed](https://matrix.org/docs/spec/server_server/unstable.html#adding-hashes-and-signatures-to-outgoing-events), signed](https://matrix.org/docs/spec/server_server/r0.1.0#adding-hashes-and-signatures-to-outgoing-events),
this involves operating not only on the original event but also the redacted this involves operating not only on the original event but also the redacted
form of the event. The redacted hash and redacted signed event are necessary if form of the event. The redacted hash and redacted signed event are necessary if
the event is ever redacted in future. As a result, any change of the essential the event is ever redacted in future. As a result, any change of the essential

2
proposals/2312-matrix-uri.md
Unescape Escape View File

@ -49,7 +49,7 @@ This MSC does not introduce new Matrix entities, nor API endpoints -
it merely defines a mapping between URIs with the scheme name `matrix:` it merely defines a mapping between URIs with the scheme name `matrix:`
and Matrix identifiers, as well as operations on them. The MSC should be and Matrix identifiers, as well as operations on them. The MSC should be
sufficient to produce an implementation that would convert Matrix URIs to sufficient to produce an implementation that would convert Matrix URIs to
a series of [CS API](https://matrix.org/docs/spec/client_server/latest) calls, a series of [CS API](https://matrix.org/docs/spec/client_server/r0.6.1) calls,
entirely on the client side. It is recognised, however, that most of entirely on the client side. It is recognised, however, that most of
the URI processing logic can and should (eventually) be on the server side the URI processing logic can and should (eventually) be on the server side
in order to facilitate adoption of Matrix URIs; further MSCs are needed in order to facilitate adoption of Matrix URIs; further MSCs are needed

2
proposals/2320-identity-versions.md
Unescape Escape View File

@ -29,7 +29,7 @@ this identity server supports. Its response uses the following format:
## Alternative solutions ## Alternative solutions
Another solution which was considered was using the status check endpoint ([`GET Another solution which was considered was using the status check endpoint ([`GET
/_matrix/api/v1`](https://matrix.org/docs/spec/identity_service/latest#get-matrix-identity-api-v1)) /_matrix/api/v1`](https://matrix.org/docs/spec/identity_service/r0.2.0#get-matrix-identity-api-v1))
to serve this information. This solution was discarded because it's using a to serve this information. This solution was discarded because it's using a
versioned endpoint, which doesn't make sense to advertise the supported versions versioned endpoint, which doesn't make sense to advertise the supported versions
of the API to use. of the API to use.

2
proposals/3122-deprecate-starting-verifications-without-request.md
Unescape Escape View File

@ -1,7 +1,7 @@
# MSC3122: Deprecate starting key verifications without requesting first # MSC3122: Deprecate starting key verifications without requesting first
Currently, the [Key verification Currently, the [Key verification
framework](https://spec.matrix.org/unstable/client-server-api/#key-verification-framework) framework](https://matrix.org/docs/spec/client_server/r0.6.1#key-verification-framework)
allows a device to begin a verification via to-device messages by sending an allows a device to begin a verification via to-device messages by sending an
`m.key.verification.start` event without first sending or receiving an `m.key.verification.start` event without first sending or receiving an
`m.key.verification.request` message. (The last sentence of the 5th paragraph `m.key.verification.request` message. (The last sentence of the 5th paragraph

12
proposals/3173-expose-stripped-state-events.md
Unescape Escape View File

@ -9,7 +9,7 @@ the room in some situations:
* If the room has `history_visibility: world_readable`, then anyone can inspect * If the room has `history_visibility: world_readable`, then anyone can inspect
it (by calling `/state` on it). it (by calling `/state` on it).
* Rooms in the [room directory](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-publicrooms) * Rooms in the [room directory](https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-client-r0-publicrooms)
expose some of their state publicly. expose some of their state publicly.
* [Invited users](https://matrix.org/docs/spec/server_server/r0.1.4#put-matrix-federation-v2-invite-roomid-eventid) * [Invited users](https://matrix.org/docs/spec/server_server/r0.1.4#put-matrix-federation-v2-invite-roomid-eventid)
and [knocking users](https://github.com/matrix-org/matrix-doc/pull/2403) and [knocking users](https://github.com/matrix-org/matrix-doc/pull/2403)
@ -29,7 +29,7 @@ to include stripped state events which are useful for displaying the invite to a
> the room. The recommended events to include are the join rules, canonical alias, > the room. The recommended events to include are the join rules, canonical alias,
> avatar, and name of the room. > avatar, and name of the room.
The invited user receives these [stripped state events](https://spec.matrix.org/unstable/client-server-api/#get_matrixclientr0sync) The invited user receives these [stripped state events](https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-client-r0-sync)
as part of the `/sync` response: as part of the `/sync` response:
> The state of a room that the user has been invited to. These state events may > The state of a room that the user has been invited to. These state events may
@ -37,7 +37,7 @@ as part of the `/sync` response:
> events do not replace any state that the client already has for the room, for > events do not replace any state that the client already has for the room, for
> example if the client has archived the room. > example if the client has archived the room.
These are sent as part of the [`unsigned` content of the `m.room.member` event](https://spec.matrix.org/unstable/client-server-api/#mroommember) These are sent as part of the [`unsigned` content of the `m.room.member` event](https://matrix.org/docs/spec/client_server/r0.6.1#m-room-member)
containing the invite. containing the invite.
[MSC2403: Add "knock" feature](https://github.com/matrix-org/matrix-doc/pull/2403) [MSC2403: Add "knock" feature](https://github.com/matrix-org/matrix-doc/pull/2403)
@ -141,7 +141,7 @@ This does not seem to weaken the security expectations of either join rule.
### Revisions to the room directory ### Revisions to the room directory
A future MSC could include additional information from the stripped state events A future MSC could include additional information from the stripped state events
in the [room directory](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-publicrooms). in the [room directory](https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-client-r0-publicrooms).
The main missing piece seems to be the encryption information, but there may also The main missing piece seems to be the encryption information, but there may also
be other pieces of information to include. be other pieces of information to include.
@ -174,7 +174,7 @@ N/A
## Footnotes ## Footnotes
<a id="f1"/>[1]: No changes are proposed to <a id="f1"/>[1]: No changes are proposed to
[the definition of `history_visibility`](https://matrix.org/docs/spec/client_server/latest#room-history-visibility). [the definition of `history_visibility`](https://matrix.org/docs/spec/client_server/r0.6.1#room-history-visibility).
The state of a room which is `world_readable` is available to anyone. This somewhat The state of a room which is `world_readable` is available to anyone. This somewhat
implies that the stripped state is also available to anyone, regardless of the join implies that the stripped state is also available to anyone, regardless of the join
rules, but having a `world_readable`, `invite` room does not seem valuable. [↩](#a1) rules, but having a `world_readable`, `invite` room does not seem valuable. [↩](#a1)
@ -190,6 +190,6 @@ from Synapse and generally seems useful for a user to know before joining a roo
[↩](#a4) [↩](#a4)
<a id="f5"/>[5]: The room topic (`m.room.topic`) is included as part of the <a id="f5"/>[5]: The room topic (`m.room.topic`) is included as part of the
[room directory](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-publicrooms) [room directory](https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-client-r0-publicrooms)
response for public rooms. It is also planned to be included as part of [MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946) response for public rooms. It is also planned to be included as part of [MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946)
in the spaces summary response. [↩](#a5) in the spaces summary response. [↩](#a5)

Write Preview
Loading…
Cancel
Save