From b47de28da543f165795812afa366cacd64211a01 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 24 Jan 2020 00:40:33 +0100 Subject: [PATCH 01/26] MSC2422: Allow color on font tag Signed-off-by: Nicolas Werner --- .../2422-allow-color-attribute-on-font-tag.md | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 proposals/2422-allow-color-attribute-on-font-tag.md diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md new file mode 100644 index 00000000000..4287a696b27 --- /dev/null +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -0,0 +1,38 @@ +# MSC2422: Allow `color` as attribute for `` in messages + +Currently the spec requires you to use `data-mx-color` instead of the standard +`color` html attribute for the `` tag. This is probably done to make it +consistent with ``, where you may not want to allow a generic style tag for. + +On the other hand the /rainbow command on almost every client just uses the +`color` attribute of the `` tag. While some clients support +`data-mx-color` (i.e. Riot Web), most clients don't. Most clients support +rendering `color` however. + +It would probably be for the best to allow or even prefer `color` on the +`` tag. + +## Proposal + +Add the `color` attribute to the allowed attributes of `` in section +13.2.1.7. Allow only hexcodes as allowed value for this attribute for now. + +## Potential issues + +- We now have a redundant attribute in the spec. While it matches, what the + clients currently do, it may be better to fix each client instead. +- Clients may not sanitize the color attribute and will let other color values + through, increasing compatibility issues again. +- Clients may never support the data-mx-* attributes now. +- Old messages could loose their color +- This proposal doesn't touch span at all, maybe it should? + +## Alternatives + +- fix the clients +- remove the `data-mx-color` and `data-mx-bg-color` attributes entirely, leaving + us just with `color` for `` +- Add a section to tell the clients to prefer `color` over `mx-data-color` +- Spec an entirely different format for messages (that would probably not make + this proposal obsolete) + From 6bd4b3c08a7a5137700c8fbf76008b27de92efe0 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 10 Feb 2020 20:29:38 +0000 Subject: [PATCH 02/26] MSC: Updated semantics for publishing room aliases --- proposals/2432-revised-alias-publishing.md | 225 +++++++++++++++++++++ 1 file changed, 225 insertions(+) create mode 100644 proposals/2432-revised-alias-publishing.md diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md new file mode 100644 index 00000000000..8ef08f7db53 --- /dev/null +++ b/proposals/2432-revised-alias-publishing.md @@ -0,0 +1,225 @@ +# MSC2432: Updated semantics for publishing room aliases + +This MSC offers an alternative to [MSC2260](https://github.com/matrix-org/matrix-doc/issues/2260). + +## Background + +The [`m.room.aliases`](https://matrix.org/docs/spec/client_server/r0.6.0#m-room-aliases) +state event exists to list the available aliases for a given room. This serves +two purposes: + + * It allows existing members of the room to discover alternative aliases, + which may be useful for them to pass this knowledge on to others trying to + join. + + * Secondarily, it helps to educate users about how Matrix works by + illustrating multiple aliases per room and giving a perception of the size + of the network. + +However, it has problems: + + * Any user in the entire ecosystem can create aliases for rooms, which are + then unilaterally added to `m.room.aliases`, and room admins are unable to + remove them. This is an abuse + vector (https://github.com/matrix-org/matrix-doc/issues/625). + + * For various reasons, the `m.room.aliases` event tends to get out of sync + with the actual aliases (https://github.com/matrix-org/matrix-doc/issues/2262). + +## Proposal + +We propose that that room moderators should be able to manually curate a list +of "official" aliases for their room, instead of matrix servers automatically +publishing lists of all room aliases into the room state. No particular +guarantees are offered that this alias list is entirely accurate: it becomes +room moderators' responsibilty to keep it so. + +Meanwhile, the aliases that map to a given room on a given server become +the ultimate responsibility of the administrators of that server. We give them +tools to inspect the alias list and clean it up when necessary, in addition to +the current tools which allow restriction of who can create aliases in the +first place. + +A detailed list of proposed modifications to the Matrix spec follows: + + * `m.room.aliases` loses any special meaning within the spec. In particular: + + * Clients should no longer format it specially in room timelines. + + * Clients and servers should no longer consider `m.room.aliases` when + [calculating the display name for a + room](https://matrix.org/docs/spec/client_server/r0.6.0#calculating-the-display-name-for-a-room). + + (Note: servers follow the room display-name algorithm when calculating + room names for certain types of push notification.) + + * A future room version will remove the special [authorization +rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and +[redaction rules](https://matrix.org/docs/spec/client_server/r0.6.0#redactions). + + * [`m.room.canonical_alias`](https://matrix.org/docs/spec/client_server/r0.6.0#m-room-canonical-alias) + is extended to include a new `alt_aliases` property. This, if present, + should be a list of alternative aliases for the room. An example event might + look like: + + ```json + { + "content": { + "alias": "#somewhere:localhost", + "alt_aliases": [ + "#somewhere:overthere.com", + "#somewhereelse:example.com" + ] + }, + "room_id": "!jEsUZKDJdhlrceRyVU:example.org", + "state_key": "", + "type": "m.room.canonical_alias" + } + ``` + + It is valid for `alt_aliases` to be non-empty even if `alias` is absent or + empty. This means that no alias has been picked out as the 'main' alias. + + (Note: although the spec currently claims that `alias` is mandatory, Synapse + generates `m.room.canonical` alias events with no `alias` property when the + main alias is deleted. This change would legitimise that behaviour.) + + (For clarity: it is not proposed that the `alt_aliases` be considered when + calculating the displayname for a room.) + + * [`PUT /_matrix/client/r0/rooms/{roomId}/state/{eventType}/{stateKey}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-rooms-roomid-state-eventtype-statekey) + is extended to recommend that servers validate any *new* aliases added to + `m.room.canonical_alias` by checking that it is a valid alias according to + the [syntax](https://matrix.org/docs/spec/appendices#room-aliases), and by + looking up the alias and and that it corresponds to the expected room ID. + + (Note: Synapse currently implements this check on the main alias, though + this is unspecced.) + + (TODO: what error code should be returned if the alias is invalid, or if it + points to the wrong room?) + + * Currently, [`PUT /_matrix/client/r0/directory/room/{roomAlias}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-directory-room-roomalias) + attempts to send updated `m.room.aliases` events on the caller's + behalf. (This is implemented in Synapse but does not appear to be explicitly + specced.) This functionality should be removed. + + * Currently, [`DELETE /_matrix/client/r0/directory/room/{roomAlias}`](https://matrix.org/docs/spec/client_server/r0.6.0#delete-matrix-client-r0-directory-room-roomalias), + attempts to send updated `m.room.aliases` and/or `m.room.canonical_alias` + events on the caller's behalf, removing any aliases which have been + deleted. (Again, this is implemented in Synapse but does not appear to be + explicitly specced.) The `m.room.aliases` functionality should be removed, + and the `m.room.canonical_alias` functionality should be extended to cover + `alt_aliases`. As today, no error occurs if the caller does not have + permission to send such an event. + + * A new api endpoint, `GET /_matrix/client/r0/rooms/{roomId}/aliases` is + added, which returns the list of aliases currently defined on the local + server for the given room. The response looks like: + + ```json + { + "aliases": [ + "#somewhere:example.com", + "#somewhereelse:example.com", + "#special_alias:example.com" + ] + } + ``` + + This API can be called by any current member of the room (calls from other + users result in `M_FORBIDDEN`). + + TODO: should this be tied in with `history_visibilty` to allow peeking from + non-members? On the one hand that feels like pointless clutter; on the other + it feels like it makes it more consistent with peekable rooms. + +Various APIs are currently subject to implementation-defined access +restrictions. No change to the specification is changed in this regard +(implementations will continue to be free to impose their own +restrictions). Nevertheless as part of this MSC it is useful to consider some +proposed changes to Synapse's implementation: + + * No change: `PUT /_matrix/client/r0/directory/room/{roomAlias}`: Synapse + only allows access to current members of the room, and also exposes some + configuration options which allow restriction of which users are allowed to + create aliases in general. + + * `DELETE /_matrix/client/r0/directory/room/{roomAlias}`: in this case, + currently Synapse restricts its use to the user that created the alias, and + server admins. + + It is proposed to extend this to local users who have a power-level + sufficient to send an `m.room.canonical_alias` event in the room that the + alias currently points to. + + * [`PUT /_matrix/client/r0/directory/list/room/{roomId}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-directory-list-room-roomid) + and the corresponding unspecced `DELETE` api (both of which set the + visibility of a room in the public directory): currently Synapse restricts + their use to server admins and local users who have a PL sufficient to send + an `m.room.aliases` event in the room (ignoring the special auth + rules). This will be changed to check against the PL required to send an + `m.room.canonical_alias` event. + +It is envisaged that Matrix clients will then change their "Room Settings" user +interface to display the aliases from `m.room.canonical_alias` instead of those +in `m.room.aliases`, as well as giving moderators the ability to update that +list. Clients might also wish to use the new `GET +/_matrix/client/r0/rooms/{roomId}/aliases` endpoint to obtain and display the +currently-available local aliases, though given that this list may be subject +to abuse, it should probably not be shown by default. + +### Future work + +This work isn't considered part of this MSC, but rather a potential extension +for the future. + + * It may be useful to be able to query remote servers for their alias + list. This could be done by extending `GET + /_matrix/client/r0/rooms/{roomId}/aliases` to take a `server_name` + parameter, and defining an API in the server_server spec which will expose + the requested information, subject to the calling homeserver having at least + one user with a right to see it. + + * Similarly, room moderators may wish to be able to delete aliases on a remote + server for their room. We could envisage a fedaration API which allows such + a request to be made, subject to the calling homeserver having at least one + moderator in the room. + +## Potential issues + +The biggest problem with this proposal is that existing clients, which rely on +`m.room.aliases` in one way or another, will lose functionality. In particular, +they may not know about aliases that exist, or they may look at outdated +`m.room.aliases` events that list aliases that no longer exist. However, since +`m.room.aliases` is best-effort anyway, these are both problems that exist to +some extent today. + +## Alternatives + +We considered continuing to use `m.room.aliases` to advertise room aliases +instead of `m.room.canonical_alias`, but the significant changes in semantics +made that seem inappropriate. + +We also considered using separate state events for each advertised alias, +rather than listing them all in one event. This might increase the number of +aliases which can be advertised, and help to reduce races when editing the +list. However, the 64KB limit of an event still allows room for hundreds of +aliases of any sane length, and we don't expect the list to be changing +frequently enough for races to be a practical concern. Ultimately the added +complexity seemed redundant. + +A previous suggestion was +[MSC2260](https://github.com/matrix-org/matrix-doc/issues/2260), which proposed +keeping `m.room.aliases` largely as-is, but giving room moderators tools to +control who can send them via room power-levels. We dismissed it for the +reasons set out at +https://github.com/matrix-org/matrix-doc/pull/2260#issuecomment-584207073. + +## Security considerations + +None currently identified. + +## Unstable prefix + +TBD. From 95ff26679bf4f780509e73d2201cafe9ce40c111 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Tue, 11 Feb 2020 11:16:56 +0000 Subject: [PATCH 03/26] Apply suggestions from code review Co-Authored-By: Matthew Hodgson Co-Authored-By: Hubert Chathi --- proposals/2432-revised-alias-publishing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index 8ef08f7db53..0afdf195861 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -32,7 +32,7 @@ We propose that that room moderators should be able to manually curate a list of "official" aliases for their room, instead of matrix servers automatically publishing lists of all room aliases into the room state. No particular guarantees are offered that this alias list is entirely accurate: it becomes -room moderators' responsibilty to keep it so. +room moderators' responsibility to keep it so. Meanwhile, the aliases that map to a given room on a given server become the ultimate responsibility of the administrators of that server. We give them @@ -182,7 +182,7 @@ for the future. one user with a right to see it. * Similarly, room moderators may wish to be able to delete aliases on a remote - server for their room. We could envisage a fedaration API which allows such + server for their room. We could envisage a federation API which allows such a request to be made, subject to the calling homeserver having at least one moderator in the room. From 786772f7646f8767c008872abc6fc41b9fe7b809 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Tue, 18 Feb 2020 16:24:46 +0000 Subject: [PATCH 04/26] Update proposals/2432-revised-alias-publishing.md Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> --- proposals/2432-revised-alias-publishing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index 0afdf195861..a68872640e9 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -81,7 +81,7 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and empty. This means that no alias has been picked out as the 'main' alias. (Note: although the spec currently claims that `alias` is mandatory, Synapse - generates `m.room.canonical` alias events with no `alias` property when the + generates `m.room.canonical_alias` events with no `alias` property when the main alias is deleted. This change would legitimise that behaviour.) (For clarity: it is not proposed that the `alt_aliases` be considered when From 645dbcc0912624a32d070b2c7ae30d936f1e2f7b Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 19 Feb 2020 07:25:34 +0000 Subject: [PATCH 05/26] make room alias lists peekable --- proposals/2432-revised-alias-publishing.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index a68872640e9..4a5d95adfbe 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -128,11 +128,8 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and ``` This API can be called by any current member of the room (calls from other - users result in `M_FORBIDDEN`). - - TODO: should this be tied in with `history_visibilty` to allow peeking from - non-members? On the one hand that feels like pointless clutter; on the other - it feels like it makes it more consistent with peekable rooms. + users result in `M_FORBIDDEN`). For rooms with `history_visibility` set to + `world_readable`, it can also be called by users outside the room. Various APIs are currently subject to implementation-defined access restrictions. No change to the specification is changed in this regard From 30d762cc72ad179ceb612dea046418770546714e Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 19 Feb 2020 07:25:49 +0000 Subject: [PATCH 06/26] document unstable prefixes/feature flags --- proposals/2432-revised-alias-publishing.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index 4a5d95adfbe..81d59e71a3e 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -219,4 +219,11 @@ None currently identified. ## Unstable prefix -TBD. +While this feature is in development, the following names will be in use: + +| Proposed final name | Name while in development | +| `GET /_matrix/client/r0/rooms/{roomId}/aliases` | `GET /_matrix/client/unstable/org.matrix.msc2432/rooms/{roomId}/aliases` | + +Servers will indicate support for the new endpoint via a non-empty value for feature flag +`org.matrix.msc2432` in `unstable_features` in the response to `GET +/_matrix/client/versions`. From 98a6cd0f45426beca4eb1e0334573a1ea3748642 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Wed, 19 Feb 2020 07:29:55 +0000 Subject: [PATCH 07/26] fix table --- proposals/2432-revised-alias-publishing.md | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index 81d59e71a3e..c527a14ed6c 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -222,6 +222,7 @@ None currently identified. While this feature is in development, the following names will be in use: | Proposed final name | Name while in development | +| --- | --- | | `GET /_matrix/client/r0/rooms/{roomId}/aliases` | `GET /_matrix/client/unstable/org.matrix.msc2432/rooms/{roomId}/aliases` | Servers will indicate support for the new endpoint via a non-empty value for feature flag From 8b9ea10e11bd0a460211e1826543fe17f2667e19 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 19 Feb 2020 07:31:57 +0000 Subject: [PATCH 08/26] server admins can list aliases --- proposals/2432-revised-alias-publishing.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index c527a14ed6c..433ce0f66b4 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -131,6 +131,9 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and users result in `M_FORBIDDEN`). For rooms with `history_visibility` set to `world_readable`, it can also be called by users outside the room. + Servers might also choose to allow access to other users such as server + administrators. + Various APIs are currently subject to implementation-defined access restrictions. No change to the specification is changed in this regard (implementations will continue to be free to impose their own From 4e123ca12113bd0587ac641503f0e8da9f6af4f0 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Sat, 29 Feb 2020 23:29:33 +0000 Subject: [PATCH 09/26] Update proposals/2432-revised-alias-publishing.md Co-Authored-By: Kitsune Ral --- proposals/2432-revised-alias-publishing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index 433ce0f66b4..dff72df5ae8 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -135,7 +135,7 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and administrators. Various APIs are currently subject to implementation-defined access -restrictions. No change to the specification is changed in this regard +restrictions. No change to the specification is introduced in this regard (implementations will continue to be free to impose their own restrictions). Nevertheless as part of this MSC it is useful to consider some proposed changes to Synapse's implementation: From 420180a69ddd25d44b1c7c048d809b05683978f4 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 3 Mar 2020 12:30:19 -0500 Subject: [PATCH 10/26] MSC: Remove query_auth federation endpoint. --- .gitignore | 1 + ...x-remove-query_auth-federation-endpoint.md | 31 +++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 proposals/xxxx-remove-query_auth-federation-endpoint.md diff --git a/.gitignore b/.gitignore index 800be2fa8a9..9cc27b85582 100644 --- a/.gitignore +++ b/.gitignore @@ -12,3 +12,4 @@ *.swp _rendered.rst /.vscode/ +/.idea/ diff --git a/proposals/xxxx-remove-query_auth-federation-endpoint.md b/proposals/xxxx-remove-query_auth-federation-endpoint.md new file mode 100644 index 00000000000..7930c5f8346 --- /dev/null +++ b/proposals/xxxx-remove-query_auth-federation-endpoint.md @@ -0,0 +1,31 @@ +# MSCxxxx: Remove the `query_auth` federation endpoint + +The `query_auth` federation endpoint is unused by Synapse and should be removed. +The current implementation in Synapse is broken and will return a 500 error in +some situations. + +## Proposal + +Remove: + +* [POST `/_matrix/federation/v1/query_auth/{roomId}/{eventId}`](https://matrix.org/docs/spec/server_server/r0.1.3#post-matrix-federation-v1-query-auth-roomid-eventid) + +## Potential issues + +Removing this endpoint impacts backwards compatibility. + +In practice, removing this endpoint should have minimal impact. Since 1.5.0rc1 +of Synapse this endpoint is not called (see [#6214](https://github.com/matrix-org/synapse/pull/6214)). +During removal it was noted that the code to call this endpoint was already +unreachable. + +Note that it seems like this was initially supported in Synapse v0.7.0. It is +not clear at what point it became unused. + +## Alternatives + +The endpoint could be deprecated in removed in a future version of the specification. + +## Security considerations + +None. From c3420770ad3a559217ee5ae7a5998b1c78960055 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 3 Mar 2020 13:15:32 -0500 Subject: [PATCH 11/26] Clarify history of endpoint. --- ...x-remove-query_auth-federation-endpoint.md | 33 +++++++++++++------ 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/proposals/xxxx-remove-query_auth-federation-endpoint.md b/proposals/xxxx-remove-query_auth-federation-endpoint.md index 7930c5f8346..387f2efa50b 100644 --- a/proposals/xxxx-remove-query_auth-federation-endpoint.md +++ b/proposals/xxxx-remove-query_auth-federation-endpoint.md @@ -1,26 +1,39 @@ # MSCxxxx: Remove the `query_auth` federation endpoint The `query_auth` federation endpoint is unused by Synapse and should be removed. -The current implementation in Synapse is broken and will return a 500 error in -some situations. +The current implementation in Synapse is not robust and will return a 500 error +in some situations. ## Proposal -Remove: +Remove the following endpoint: * [POST `/_matrix/federation/v1/query_auth/{roomId}/{eventId}`](https://matrix.org/docs/spec/server_server/r0.1.3#post-matrix-federation-v1-query-auth-roomid-eventid) ## Potential issues -Removing this endpoint impacts backwards compatibility. +Removing this endpoint impacts backwards compatibility, in practice removing +this endpoint should have minimal impact as it was an unused error path in +Synapse. The federation client code to call this endpoint was removed in Synapse +v1.5.0rc1. -In practice, removing this endpoint should have minimal impact. Since 1.5.0rc1 -of Synapse this endpoint is not called (see [#6214](https://github.com/matrix-org/synapse/pull/6214)). -During removal it was noted that the code to call this endpoint was already -unreachable. +Note that dendrite has never implemented this federation endpoint. + +### History + +This endpoint (and the federation client code) to call it was initially +added in Synapse v0.7.0 (see [#43](https://github.com/matrix-org/synapse/pull/43)). +The federation client code was heavily modified for v1.0.0rc1 (see +[#5227](https://github.com/matrix-org/synapse/pull/5227/)), -Note that it seems like this was initially supported in Synapse v0.7.0. It is -not clear at what point it became unused. +The federation client code to call this endpoint was removed in v1.5.0rc1 of +Synapse (see [#6214](https://github.com/matrix-org/synapse/pull/6214). After +that point this endpoint is not called). + +During removal it was noted that the code to call this endpoint was already +unreachable. It seems that this code was never reachable and was meant for an +error situation which was never built out (see `git log -S NOT_ANCESTOR`, the +error condition is never assigned). ## Alternatives From 6754d5ba5f4e98ed67c5771a7176cd7d3ecba582 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 3 Mar 2020 16:18:59 -0500 Subject: [PATCH 12/26] Move filename based on MSC #. --- ...ndpoint.md => 2451-remove-query_auth-federation-endpoint.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{xxxx-remove-query_auth-federation-endpoint.md => 2451-remove-query_auth-federation-endpoint.md} (96%) diff --git a/proposals/xxxx-remove-query_auth-federation-endpoint.md b/proposals/2451-remove-query_auth-federation-endpoint.md similarity index 96% rename from proposals/xxxx-remove-query_auth-federation-endpoint.md rename to proposals/2451-remove-query_auth-federation-endpoint.md index 387f2efa50b..d5c2af4ddfa 100644 --- a/proposals/xxxx-remove-query_auth-federation-endpoint.md +++ b/proposals/2451-remove-query_auth-federation-endpoint.md @@ -1,4 +1,4 @@ -# MSCxxxx: Remove the `query_auth` federation endpoint +# MSC2451: Remove the `query_auth` federation endpoint The `query_auth` federation endpoint is unused by Synapse and should be removed. The current implementation in Synapse is not robust and will return a 500 error From 68357a7d23420b069308cfbe99244168307230d6 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 4 Mar 2020 07:31:38 -0500 Subject: [PATCH 13/26] Fix a typo in -> and. Co-Authored-By: Matthew Hodgson --- proposals/2451-remove-query_auth-federation-endpoint.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2451-remove-query_auth-federation-endpoint.md b/proposals/2451-remove-query_auth-federation-endpoint.md index d5c2af4ddfa..0d84069e490 100644 --- a/proposals/2451-remove-query_auth-federation-endpoint.md +++ b/proposals/2451-remove-query_auth-federation-endpoint.md @@ -37,7 +37,7 @@ error condition is never assigned). ## Alternatives -The endpoint could be deprecated in removed in a future version of the specification. +The endpoint could be deprecated and removed in a future version of the specification. ## Security considerations From 61715f6452bfda06b273d1fc8a94b9412f4910b6 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 4 Mar 2020 08:07:05 -0500 Subject: [PATCH 14/26] Update and expand the proposal based on feedback and additional info. --- ...1-remove-query_auth-federation-endpoint.md | 20 +++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/proposals/2451-remove-query_auth-federation-endpoint.md b/proposals/2451-remove-query_auth-federation-endpoint.md index 0d84069e490..b2d8bc9fd1a 100644 --- a/proposals/2451-remove-query_auth-federation-endpoint.md +++ b/proposals/2451-remove-query_auth-federation-endpoint.md @@ -1,8 +1,19 @@ # MSC2451: Remove the `query_auth` federation endpoint -The `query_auth` federation endpoint is unused by Synapse and should be removed. -The current implementation in Synapse is not robust and will return a 500 error -in some situations. +This API was added without sufficient thought nor testing. The endpoint isn't +used in any known implementations, and we do not believe it to be necessary +for federation to work. The only known implementation (in Synapse) was not fully +fleshed out and is broken. + +For background, the idea behind this endpoint was that two homeservers would be +able to share state events with the hope of filling in missing state from one +of homeservers allowing state resolution to complete. This was to protect +against a joining server not providing the full (or providing stale) state. + +In addition to the ideas above not coming to fruition, it is unclear whether the +current design of this endpoint would be sufficient. If this state negotiation +feature is needed in the future it should be redesigned from scratch via the MSC +proposal process. ## Proposal @@ -17,7 +28,8 @@ this endpoint should have minimal impact as it was an unused error path in Synapse. The federation client code to call this endpoint was removed in Synapse v1.5.0rc1. -Note that dendrite has never implemented this federation endpoint. +There is no evidence of other homeserver implementations having implemented this +endpoint. ### History From 438ff8fc1d19f89cbf77583b95a3dbe55d4c6b96 Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Thu, 5 Mar 2020 21:02:09 +0000 Subject: [PATCH 15/26] Update proposals/2422-allow-color-attribute-on-font-tag.md Co-Authored-By: Travis Ralston --- proposals/2422-allow-color-attribute-on-font-tag.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md index 4287a696b27..7a87f143f3d 100644 --- a/proposals/2422-allow-color-attribute-on-font-tag.md +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -1,6 +1,6 @@ # MSC2422: Allow `color` as attribute for `` in messages -Currently the spec requires you to use `data-mx-color` instead of the standard +Currently the spec recommends that you to use `data-mx-color` instead of the standard `color` html attribute for the `` tag. This is probably done to make it consistent with ``, where you may not want to allow a generic style tag for. @@ -35,4 +35,3 @@ Add the `color` attribute to the allowed attributes of `` in section - Add a section to tell the clients to prefer `color` over `mx-data-color` - Spec an entirely different format for messages (that would probably not make this proposal obsolete) - From 6b2752c4c2c0fd183224f22ed339226362ddddfd Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Thu, 5 Mar 2020 21:02:23 +0000 Subject: [PATCH 16/26] Update proposals/2422-allow-color-attribute-on-font-tag.md Co-Authored-By: Travis Ralston --- proposals/2422-allow-color-attribute-on-font-tag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md index 7a87f143f3d..9e4b1645829 100644 --- a/proposals/2422-allow-color-attribute-on-font-tag.md +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -15,7 +15,7 @@ It would probably be for the best to allow or even prefer `color` on the ## Proposal Add the `color` attribute to the allowed attributes of `` in section -13.2.1.7. Allow only hexcodes as allowed value for this attribute for now. +13.2.1.7. No changes to the allowable values from the HTML spec are made here. ## Potential issues From b760ec2d747281294634bec051064191d4fd3357 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Sat, 7 Mar 2020 14:57:32 +0100 Subject: [PATCH 17/26] Add comments why alternatives to MSC2422 weren't chosen --- .../2422-allow-color-attribute-on-font-tag.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md index 9e4b1645829..3fb03aa5df2 100644 --- a/proposals/2422-allow-color-attribute-on-font-tag.md +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -29,9 +29,11 @@ Add the `color` attribute to the allowed attributes of `` in section ## Alternatives -- fix the clients -- remove the `data-mx-color` and `data-mx-bg-color` attributes entirely, leaving - us just with `color` for `` -- Add a section to tell the clients to prefer `color` over `mx-data-color` -- Spec an entirely different format for messages (that would probably not make - this proposal obsolete) +- fix the clients + -> This currently seems not feasible. Multiple clients started using color first (i.e. RiotX, Gomuks) and if it isn't spelled out explicitly in the spec, this will probably continue. +- remove the `data-mx-color` and `data-mx-bg-color` attributes entirely, leaving us just with `color` for `` + -> This would break old messages and can be done independently of this proposal at a later date, if it is deemed useful. +- Add a section to tell the clients to prefer `color` over `mx-data-color` + -> I don't really know, why mx-data-* was chosen, but I assume there was a reason, so I don't want to change that. +- Spec an entirely different format for messages (that would probably not make this proposal obsolete) + -> This wouldn't fix the issue, where some client may choose to remove the color tag, since it is dicouraged in the spec. Migration would probably also take a while, so this proposal is a quick solution, that doesn't prevent other solutions at a later date. From 2d85422a2ff500cb79fcf88c82fa5c73fc4f4b1a Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Sat, 7 Mar 2020 18:34:07 +0000 Subject: [PATCH 18/26] Update proposals/2422-allow-color-attribute-on-font-tag.md Co-Authored-By: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/2422-allow-color-attribute-on-font-tag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md index 3fb03aa5df2..11f06bffaf1 100644 --- a/proposals/2422-allow-color-attribute-on-font-tag.md +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -19,7 +19,7 @@ Add the `color` attribute to the allowed attributes of `` in section ## Potential issues -- We now have a redundant attribute in the spec. While it matches, what the +- We now have a redundant attribute in the spec. While it matches what the clients currently do, it may be better to fix each client instead. - Clients may not sanitize the color attribute and will let other color values through, increasing compatibility issues again. From 7917d087f3874f07cfaf0750ed493ded95bc77ac Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Thu, 19 Mar 2020 15:21:50 +0000 Subject: [PATCH 19/26] clarifications --- proposals/2432-revised-alias-publishing.md | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index dff72df5ae8..4c2f010f13b 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -96,8 +96,16 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and (Note: Synapse currently implements this check on the main alias, though this is unspecced.) - (TODO: what error code should be returned if the alias is invalid, or if it - points to the wrong room?) + The following error codes are specified: + + * HTTP 400, with `errcode: M_INVALID_PARAMETER` if an attempt is made to add + an entry which is not a well-formed alias (examples: too long, doesn't + start with `#`, doesn't contain a `:`). + + * HTTP 400, with `errcode: M_BAD_ALIAS` if an added alias does not point at + the given room (either because the alias doesn't exist, because it can't + be resolved due to an unreachable server, or because the alias points at a + different room). * Currently, [`PUT /_matrix/client/r0/directory/room/{roomAlias}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-directory-room-roomalias) attempts to send updated `m.room.aliases` events on the caller's @@ -110,8 +118,14 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and deleted. (Again, this is implemented in Synapse but does not appear to be explicitly specced.) The `m.room.aliases` functionality should be removed, and the `m.room.canonical_alias` functionality should be extended to cover - `alt_aliases`. As today, no error occurs if the caller does not have - permission to send such an event. + `alt_aliases`. + + The behaviour if the calling user has permission to delete the alias but + does not have permission to send `m.room.canonical_alias` events in the room + (for example, by virtue of being a "server administrator", or by being the + user that created the alias) is implementation-defined. It is *recommended* + that in this case, the alias is deleted anyway, and a successful response is + returned to the client. * A new api endpoint, `GET /_matrix/client/r0/rooms/{roomId}/aliases` is added, which returns the list of aliases currently defined on the local From 2b71234f3c8cd39da78ae63553d1c97f9d9aed6e Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Thu, 19 Mar 2020 14:39:54 -0400 Subject: [PATCH 20/26] clarify first run of iterative auth checks --- specification/rooms/v2.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specification/rooms/v2.rst b/specification/rooms/v2.rst index 4e8365bfc83..afc114f8f59 100644 --- a/specification/rooms/v2.rst +++ b/specification/rooms/v2.rst @@ -148,8 +148,8 @@ The *resolution* of a set of states is obtained as follows: 1. Take all *power events* and any events in their auth chains, recursively, that appear in the *full conflicted set* and order them by the *reverse topological power ordering*. -2. Apply the *iterative auth checks algorithm* on the *unconflicted state map* - and the list of events from the previous step to get a partially resolved +2. Apply the *iterative auth checks algorithm*, starting from the *unconflicted state map*, + to the list of events from the previous step to get a partially resolved state. 3. Take all remaining events that weren't picked in step 1 and order them by the mainline ordering based on the power level in the partially resolved From 28dc6a05153437c76156ea022c7d2a7efe58be04 Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Fri, 20 Mar 2020 20:29:44 +0000 Subject: [PATCH 21/26] Update proposals/2422-allow-color-attribute-on-font-tag.md Apply typo fix as suggested. Co-Authored-By: David Vo --- proposals/2422-allow-color-attribute-on-font-tag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md index 11f06bffaf1..4e6a9ced19b 100644 --- a/proposals/2422-allow-color-attribute-on-font-tag.md +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -36,4 +36,4 @@ Add the `color` attribute to the allowed attributes of `` in section - Add a section to tell the clients to prefer `color` over `mx-data-color` -> I don't really know, why mx-data-* was chosen, but I assume there was a reason, so I don't want to change that. - Spec an entirely different format for messages (that would probably not make this proposal obsolete) - -> This wouldn't fix the issue, where some client may choose to remove the color tag, since it is dicouraged in the spec. Migration would probably also take a while, so this proposal is a quick solution, that doesn't prevent other solutions at a later date. + -> This wouldn't fix the issue, where some client may choose to remove the color tag, since it is discouraged in the spec. Migration would probably also take a while, so this proposal is a quick solution, that doesn't prevent other solutions at a later date. From 4d808762da4968594c63068351598dbae7245784 Mon Sep 17 00:00:00 2001 From: Aaron Axvig Date: Mon, 23 Mar 2020 12:11:18 -0400 Subject: [PATCH 22/26] Change formatting from italics to code --- api/client-server/redaction.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/api/client-server/redaction.yaml b/api/client-server/redaction.yaml index 58141049275..907b1d16ae4 100644 --- a/api/client-server/redaction.yaml +++ b/api/client-server/redaction.yaml @@ -37,7 +37,7 @@ paths: This cannot be undone. Users may redact their own events, and any user with a power level - greater than or equal to the `redact` power level of the room may + greater than or equal to the ``redact`` power level of the room may redact events there. operationId: redactEvent security: From fc03f7faa6e1d47ccc8470837beef1f43287929b Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 24 Mar 2020 12:42:15 -0400 Subject: [PATCH 23/26] Remove query_auth from the specification per MSC2451. --- api/server-server/event_auth.yaml | 134 ---------------------------- specification/server_server_api.rst | 1 - 2 files changed, 135 deletions(-) diff --git a/api/server-server/event_auth.yaml b/api/server-server/event_auth.yaml index 0db0d401549..8f545e1d8a3 100644 --- a/api/server-server/event_auth.yaml +++ b/api/server-server/event_auth.yaml @@ -72,137 +72,3 @@ paths: example: $ref: "examples/minimal_pdu.json" required: ['auth_chain'] - "/query_auth/{roomId}/{eventId}": - post: - summary: Compare auth chains with the receiving server - description: |- - Compares the auth chain provided with what the receiving server has for the - room ID and event ID combination. - - The auth difference can be calculated in two parts, where the "remote auth" - is the auth chain provided by the sending server and the "local auth" is the - auth chain the receiving server has. With those lists, the algorithm works - bottom-up after sorting each chain by depth then by event ID. The differences - are then discovered and returned as the response to this API call. - operationId: compareEventAuth - security: - - signedRequest: [] - parameters: - - in: path - name: roomId - type: string - description: The room ID to compare the auth chain in. - required: true - x-example: "!abc123:matrix.org" - - in: path - name: eventId - type: string - description: The event ID to compare the auth chain of. - required: true - x-example: "$helloworld:example.org" - - in: body - name: body - schema: - type: object - properties: - auth_chain: - type: array - description: |- - The auth chain (the "remote auth"). Note that events have a different - format depending on the room version - check the `room version specification`_ - for precise event formats. - items: - type: object - title: PDU - description: |- - The `PDUs <#pdus>`_ contained in the auth chain. The event format - varies depending on the room version - check the `room version specification`_ - for precise event formats. - properties: [] - example: - $ref: "examples/minimal_pdu.json" - missing: - type: array - description: |- - A list of event IDs that the sender thinks the receiver is missing. - items: - type: string - example: [] - rejects: - type: object - description: |- - The set of events that the sending server has rejected from the provided - auth chain. - - The ``string`` key is the event ID that was rejected. - additionalProperties: - type: object - title: Rejection Reason - properties: - reason: - type: enum - enum: ['auth_error', 'replaced', 'not_ancestor'] - description: |- - The reason for the event being rejected. - required: ['reason'] - example: { - "$some_event:example.org": { - "reason": "auth_error" - } - } - required: ['auth_chain'] - responses: - 200: - description: The auth chain differences, as determined by the receiver. - schema: - type: object - properties: - auth_chain: - type: array - description: |- - The auth chain the receiver has, and used to determine the auth - chain differences (the "local auth"). Note that events have a different - format depending on the room version - check the `room version specification`_ - for precise event formats. - items: - type: object - title: PDU - description: |- - The `PDUs <#pdus>`_ contained in the auth chain. The event format - varies depending on the room version - check the `room version specification`_ - for precise event formats. - properties: [] - example: - $ref: "examples/minimal_pdu.json" - missing: - type: array - description: |- - The list of event IDs that the receiver believes it is missing, - after comparing the "remote auth" and "local auth" chains. - items: - type: string - example: ["$a_missing_event:example.org"] - rejects: - type: object - description: |- - The set of events that the receiving server has rejected from the - auth chain, not including events that the sending server is missing - as determined from the difference algorithm. - - The ``string`` key is the event ID that was rejected. - additionalProperties: - type: object - title: Rejection Reason - properties: - reason: - type: enum - enum: ['auth_error', 'replaced', 'not_ancestor'] - description: |- - The reason for the event being rejected. - required: ['reason'] - example: { - "$some_event:example.org": { - "reason": "auth_error" - } - } - required: ['auth_chain', 'missing', 'rejects'] diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index a3a57dbfe6b..f0a9a5639cb 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -1077,7 +1077,6 @@ The following endpoint prefixes MUST be protected: * ``/_matrix/federation/v1/state_ids`` * ``/_matrix/federation/v1/backfill`` * ``/_matrix/federation/v1/event_auth`` -* ``/_matrix/federation/v1/query_auth`` * ``/_matrix/federation/v1/get_missing_events`` From 9944decacfe58c0a635b34bd30bdf8f3e4a73329 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 24 Mar 2020 13:17:22 -0400 Subject: [PATCH 24/26] Add changelog entry. --- changelogs/server_server/newsfragments/2470.removal | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/server_server/newsfragments/2470.removal diff --git a/changelogs/server_server/newsfragments/2470.removal b/changelogs/server_server/newsfragments/2470.removal new file mode 100644 index 00000000000..3221f5bf317 --- /dev/null +++ b/changelogs/server_server/newsfragments/2470.removal @@ -0,0 +1 @@ +Remove the unused ``query_auth`` API per [MSC2451](https://github.com/matrix-org/matrix-doc/pull/2451). From 4f0ac741a2350a46231d320cf310718339d14a2d Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 24 Mar 2020 11:22:05 -0600 Subject: [PATCH 25/26] Update changelogs/server_server/newsfragments/2470.removal --- changelogs/server_server/newsfragments/2470.removal | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/changelogs/server_server/newsfragments/2470.removal b/changelogs/server_server/newsfragments/2470.removal index 3221f5bf317..51cdadd46d0 100644 --- a/changelogs/server_server/newsfragments/2470.removal +++ b/changelogs/server_server/newsfragments/2470.removal @@ -1 +1 @@ -Remove the unused ``query_auth`` API per [MSC2451](https://github.com/matrix-org/matrix-doc/pull/2451). +Remove the unused ``query_auth`` API per `MSC2451 `_. From f7ce75d36c2dc09b24cba7c6c8fcdd419992e659 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 24 Mar 2020 11:29:00 -0600 Subject: [PATCH 26/26] Support a 'removed endpoints' changelog type --- changelogs/README.md | 19 ++++++++++++------- changelogs/application_service/pyproject.toml | 15 ++++++++++----- changelogs/client_server/pyproject.toml | 15 ++++++++++----- changelogs/identity_service/pyproject.toml | 5 +++++ changelogs/push_gateway/pyproject.toml | 15 ++++++++++----- changelogs/server_server/pyproject.toml | 15 ++++++++++----- 6 files changed, 57 insertions(+), 27 deletions(-) diff --git a/changelogs/README.md b/changelogs/README.md index a5fb1fb7d3e..5a5b6271b22 100644 --- a/changelogs/README.md +++ b/changelogs/README.md @@ -2,14 +2,14 @@ # Changelogs -[Towncrier](https://github.com/hawkowl/towncrier) is used to manage the changelog and +[Towncrier](https://github.com/hawkowl/towncrier) is used to manage the changelog and keep it up to date. Because of this, updating a changelog is really easy. ## How to update a changelog when releasing an API 1. Ensure you're in your Python 3 virtual environment 2. `cd` your way to the API you're releasing (eg: `cd changelogs/client_server`) -3. Run `towncrier --version "r0.4.0" --name "client-server" --yes` substituting the +3. Run `towncrier --version "r0.4.0" --name "client-server" --yes` substituting the variables as approprite. Note that `--name` is required although the value is ignored. 4. Commit the changes and finish the release process. @@ -26,27 +26,32 @@ For this example, we're going to pretend that the `server_server` API doesn't ex directory = "newsfragments" issue_format = "`#{issue} `_" title_format = "{version}" - + [[tool.towncrier.type]] directory = "breaking" name = "Breaking Changes" showcontent = true - + [[tool.towncrier.type]] directory = "deprecation" name = "Deprecations" showcontent = true - + [[tool.towncrier.type]] directory = "new" name = "New Endpoints" showcontent = true - + + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" showcontent = true - + [[tool.towncrier.type]] directory = "clarification" name = "Spec Clarifications" diff --git a/changelogs/application_service/pyproject.toml b/changelogs/application_service/pyproject.toml index 44d430e8ff2..278def7859b 100644 --- a/changelogs/application_service/pyproject.toml +++ b/changelogs/application_service/pyproject.toml @@ -3,27 +3,32 @@ directory = "newsfragments" issue_format = "`#{issue} `_" title_format = "{version}" - + [[tool.towncrier.type]] directory = "breaking" name = "Breaking Changes" showcontent = true - + [[tool.towncrier.type]] directory = "deprecation" name = "Deprecations" showcontent = true - + [[tool.towncrier.type]] directory = "new" name = "New Endpoints" showcontent = true - + + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" showcontent = true - + [[tool.towncrier.type]] directory = "clarification" name = "Spec Clarifications" diff --git a/changelogs/client_server/pyproject.toml b/changelogs/client_server/pyproject.toml index 8fa3f6b5abe..eb9e7b4eb4d 100644 --- a/changelogs/client_server/pyproject.toml +++ b/changelogs/client_server/pyproject.toml @@ -3,27 +3,32 @@ directory = "newsfragments" issue_format = "`#{issue} `_" title_format = "{version}" - + [[tool.towncrier.type]] directory = "breaking" name = "Breaking Changes" showcontent = true - + [[tool.towncrier.type]] directory = "deprecation" name = "Deprecations" showcontent = true - + [[tool.towncrier.type]] directory = "new" name = "New Endpoints" showcontent = true - + + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" showcontent = true - + [[tool.towncrier.type]] directory = "clarification" name = "Spec Clarifications" diff --git a/changelogs/identity_service/pyproject.toml b/changelogs/identity_service/pyproject.toml index a7fe582d562..2e50b9dfdec 100644 --- a/changelogs/identity_service/pyproject.toml +++ b/changelogs/identity_service/pyproject.toml @@ -19,6 +19,11 @@ name = "New Endpoints" showcontent = true + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" diff --git a/changelogs/push_gateway/pyproject.toml b/changelogs/push_gateway/pyproject.toml index dad1bc04bc9..9f2595c9c7b 100644 --- a/changelogs/push_gateway/pyproject.toml +++ b/changelogs/push_gateway/pyproject.toml @@ -3,27 +3,32 @@ directory = "newsfragments" issue_format = "`#{issue} `_" title_format = "{version}" - + [[tool.towncrier.type]] directory = "breaking" name = "Breaking Changes" showcontent = true - + [[tool.towncrier.type]] directory = "deprecation" name = "Deprecations" showcontent = true - + [[tool.towncrier.type]] directory = "new" name = "New Endpoints" showcontent = true - + + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" showcontent = true - + [[tool.towncrier.type]] directory = "clarification" name = "Spec Clarifications" diff --git a/changelogs/server_server/pyproject.toml b/changelogs/server_server/pyproject.toml index 98478527334..6a9dca1df3a 100644 --- a/changelogs/server_server/pyproject.toml +++ b/changelogs/server_server/pyproject.toml @@ -3,27 +3,32 @@ directory = "newsfragments" issue_format = "`#{issue} `_" title_format = "{version}" - + [[tool.towncrier.type]] directory = "breaking" name = "Breaking Changes" showcontent = true - + [[tool.towncrier.type]] directory = "deprecation" name = "Deprecations" showcontent = true - + [[tool.towncrier.type]] directory = "new" name = "New Endpoints" showcontent = true - + + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" showcontent = true - + [[tool.towncrier.type]] directory = "clarification" name = "Spec Clarifications"