From 5ba38d33108629a1b5ed9dd75df4b00b844da0c7 Mon Sep 17 00:00:00 2001 From: nexy7574 Date: Thu, 12 Jun 2025 22:49:51 +0100 Subject: [PATCH 1/5] placeholder --- proposals/xxxx-trusted-users.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 proposals/xxxx-trusted-users.md diff --git a/proposals/xxxx-trusted-users.md b/proposals/xxxx-trusted-users.md new file mode 100644 index 00000000000..e69de29bb2d From 97ee7921357c51f2893c6a3f708d65f537d12d21 Mon Sep 17 00:00:00 2001 From: nexy7574 Date: Thu, 12 Jun 2025 22:52:25 +0100 Subject: [PATCH 2/5] Add initial draft --- proposals/xxxx-trusted-users.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 proposals/xxxx-trusted-users.md diff --git a/proposals/xxxx-trusted-users.md b/proposals/xxxx-trusted-users.md deleted file mode 100644 index e69de29bb2d..00000000000 From 0ffae883bf59780c76f754135b15de05d79c97a5 Mon Sep 17 00:00:00 2001 From: nexy7574 Date: Thu, 12 Jun 2025 22:53:14 +0100 Subject: [PATCH 3/5] It'd help if I attached the actual proposal --- proposals/4299-trusted-users.md | 91 +++++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 proposals/4299-trusted-users.md diff --git a/proposals/4299-trusted-users.md b/proposals/4299-trusted-users.md new file mode 100644 index 00000000000..ec2c1fcf2e7 --- /dev/null +++ b/proposals/4299-trusted-users.md @@ -0,0 +1,91 @@ +# MS4299: Trusted Users + +Currently, Matrix has a way to assign specific users as "ignored", declaring to both your client and server that you +would not like to interact with a given user, and in some situations would not like them to interact with you. +However, there is no mechanism to do the inverse - assign specific users as "trusted", even more so define what +"trusted" even means. This proposal will aim to tackle both of these issues, while allowing for plenty of +expansion in the future as needs of the protocol change. + +## Proposal + +For clarity's sake, the following words are used with the associated context throughout this proposal: + +- Ignored: (users that are ignored OR blocked)[2] +- Non-trusted: users who are neither trusted nor ignored (the default state) +- Trusted: users who are explicitly added to the trusted users account data object + +While this proposal does not aim to tackle what to *do* with user trust (that's for followup MSCs to define), it lays +the foundations for defining that a user can be "trusted" at all. + +Currently, we already have [the ignored users list][1], which allows you to define which users you never want to see. +This proposal introduces a "trusted users list", which behaves semantically similarly to the ignored users list, +but the inverse. Clients and servers may wish to give "trusted" users special treatment, like they currently do +with ignored users. Examples include (but are not limited to) servers filtering invites to only allow trusted users to +send them, clients disabling media previews and only enabling them by default for trusted users, only allowing +users to initiate calls if the recipient trusts them, and preventing profile fields +(display name, avatar, custom fields) being sent to non-trusted users. + +Clients can create an account data entry with the type `m.trusted_users`, with the following format: + +```json +{ + "trusted_users": { + "@user1:example.com": {}, + "@user2:example.com": {} + } +} +``` + +This event's content should be an object, whose keys are fully qualified user IDs. +Note that here, the objects following the trusted user IDs (hereon referenced as the "trust configuration") are +empty objects - this is to allow for namespaced fields to be added by later MSCs to further extend the capabilities +of trust. + +An **example** of an extended trust configuration could be: + +```json +{ + "trusted_users": { + "@user1:example.com": { + "com.example.allow_custom_colours": true + }, + "@user2:example.com": {} + } +} +``` + +If a user does not trust any users, their account data would look like `{"trusted_users": {}}`. + +A user **must not** be ignored *and* trusted, they are mutually exclusive states. +In the event that there is a desynchronisation between the ignored users account data, and the trusted users +account data, the ignored users should take priority over trusted users. +Servers *should not* automatically remove trust from users when the client asks to ignore them, nor vice versa. +Clients *should*, consequently, attempt to atomically remove trust before attempting to ignore + +## Potential issues + +As this MSC aims to target functionality both in clients and in servers, there are likely to be inconsistencies in +the implementations. Hopefully, by not defining any actual uses for trust in this MSC, and instead relying on them +being proposed in followup proposals, servers will be able to advertise support for their individual functionalities, +and clients will be able to feature-gate appropriately. + +This proposal also has potentially overlapping behaviour with other proposals, see the alternatives section below. + +Due to ignores and trusts being mutually exclusive, there is the risk that they will become desynchronised, and +have overlapping entries. As defined above, ignores should take priority over trusts. + + +## Alternatives + +- [MSC4155](4155) implements invite filtering by defining allowed/ignored/blocked users & servers. The allow function + of that proposal has potentially overlapping functionality and semantics with this one, although lacks the future + extensibility that this one aims to provide. Contrarily, 4155 could be used to build on top of this one. +- Doing away with ignores, and instead only using trusts, and adding the ability to mark a trust as an ignore/untrust, + or some other semantically similar meaning. This would be complicated and just generally expensive + + +## Unstable prefix + +Until this proposal is accepted, implementations should make use of the account data event type +`uk.timedout.msc4299.trusted_users`, instead of `m.trusted_users`. + From 8da9fcfa7a754989e5c7262e96b3f70d31ef8cee Mon Sep 17 00:00:00 2001 From: nexy7574 Date: Thu, 12 Jun 2025 22:56:03 +0100 Subject: [PATCH 4/5] Fixup markdown errors --- proposals/4299-trusted-users.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/proposals/4299-trusted-users.md b/proposals/4299-trusted-users.md index ec2c1fcf2e7..9c00252d8e0 100644 --- a/proposals/4299-trusted-users.md +++ b/proposals/4299-trusted-users.md @@ -10,7 +10,7 @@ expansion in the future as needs of the protocol change. For clarity's sake, the following words are used with the associated context throughout this proposal: -- Ignored: (users that are ignored OR blocked)[2] +- Ignored: [users that are ignored OR blocked][4283] - Non-trusted: users who are neither trusted nor ignored (the default state) - Trusted: users who are explicitly added to the trusted users account data object @@ -74,18 +74,19 @@ This proposal also has potentially overlapping behaviour with other proposals, s Due to ignores and trusts being mutually exclusive, there is the risk that they will become desynchronised, and have overlapping entries. As defined above, ignores should take priority over trusts. - ## Alternatives -- [MSC4155](4155) implements invite filtering by defining allowed/ignored/blocked users & servers. The allow function +- [MSC4155][4155] implements invite filtering by defining allowed/ignored/blocked users & servers. The allow function of that proposal has potentially overlapping functionality and semantics with this one, although lacks the future extensibility that this one aims to provide. Contrarily, 4155 could be used to build on top of this one. - Doing away with ignores, and instead only using trusts, and adding the ability to mark a trust as an ignore/untrust, or some other semantically similar meaning. This would be complicated and just generally expensive - ## Unstable prefix Until this proposal is accepted, implementations should make use of the account data event type `uk.timedout.msc4299.trusted_users`, instead of `m.trusted_users`. +[1]: https://spec.matrix.org/unstable/client-server-api/#mignored_user_list +[4283]: https://github.com/matrix-org/matrix-spec-proposals/pull/4283 +[4155]: https://github.com/matrix-org/matrix-spec-proposals/pull/4155 From 77040dec36c1f17b06179c3c1378d7ebd176947c Mon Sep 17 00:00:00 2001 From: nexy7574 Date: Fri, 13 Jun 2025 13:31:55 +0100 Subject: [PATCH 5/5] Rephrase, clarify, and add security considerations & dependencies --- proposals/4299-trusted-users.md | 48 ++++++++++++++++++++++++--------- 1 file changed, 35 insertions(+), 13 deletions(-) diff --git a/proposals/4299-trusted-users.md b/proposals/4299-trusted-users.md index 9c00252d8e0..ef38e57f8fb 100644 --- a/proposals/4299-trusted-users.md +++ b/proposals/4299-trusted-users.md @@ -1,5 +1,7 @@ # MS4299: Trusted Users +> TODO: *trusted* is misleading and conflicting + Currently, Matrix has a way to assign specific users as "ignored", declaring to both your client and server that you would not like to interact with a given user, and in some situations would not like them to interact with you. However, there is no mechanism to do the inverse - assign specific users as "trusted", even more so define what @@ -10,36 +12,44 @@ expansion in the future as needs of the protocol change. For clarity's sake, the following words are used with the associated context throughout this proposal: -- Ignored: [users that are ignored OR blocked][4283] -- Non-trusted: users who are neither trusted nor ignored (the default state) -- Trusted: users who are explicitly added to the trusted users account data object +- Entity/Entities: something that matches an entity that can be trusted (i.e. user ID, room ID, server name, glob pattern) +- Ignored: [entities that are ignored OR blocked][4283] +- Non-trusted: entities who are neither trusted nor ignored (the default state) +- Trusted: entities who are explicitly added to the trusted users account data object + +> TODO: users -> entities While this proposal does not aim to tackle what to *do* with user trust (that's for followup MSCs to define), it lays -the foundations for defining that a user can be "trusted" at all. +the foundations for defining that an entity can be "trusted" at all. Currently, we already have [the ignored users list][1], which allows you to define which users you never want to see. This proposal introduces a "trusted users list", which behaves semantically similarly to the ignored users list, but the inverse. Clients and servers may wish to give "trusted" users special treatment, like they currently do with ignored users. Examples include (but are not limited to) servers filtering invites to only allow trusted users to send them, clients disabling media previews and only enabling them by default for trusted users, only allowing -users to initiate calls if the recipient trusts them, and preventing profile fields -(display name, avatar, custom fields) being sent to non-trusted users. +users to initiate calls that reach the recipient if the recipient trusts them, and preventing profile fields +(display name, avatar, custom fields) being sent to non-trusted users. However, these capabilities are not defined in +this proposal itself. Clients can create an account data entry with the type `m.trusted_users`, with the following format: -```json +```json5 { "trusted_users": { - "@user1:example.com": {}, - "@user2:example.com": {} + "@user1:example.com": {}, // specific user + "@*:example.com": {}, // all users matching the glob pattern + "example.com": {}, // all users on the homeserver example.com + "!roomid:example.com": {}, // all members of the specified room } } ``` -This event's content should be an object, whose keys are fully qualified user IDs. -Note that here, the objects following the trusted user IDs (hereon referenced as the "trust configuration") are +> TODO: restrict globs to server names (i.e. wildcard domains) and user IDs? + +This event's content should be an object, whose keys are generic strings that are intended to represent an entity. +Note that here, the objects following the trusted entities (hereon referenced as the "trust configuration") are empty objects - this is to allow for namespaced fields to be added by later MSCs to further extend the capabilities -of trust. +of trust (such as aforementioned examples). An **example** of an extended trust configuration could be: @@ -49,7 +59,7 @@ An **example** of an extended trust configuration could be: "@user1:example.com": { "com.example.allow_custom_colours": true }, - "@user2:example.com": {} + "@*:example.com": {} } } ``` @@ -81,6 +91,13 @@ have overlapping entries. As defined above, ignores should take priority over tr extensibility that this one aims to provide. Contrarily, 4155 could be used to build on top of this one. - Doing away with ignores, and instead only using trusts, and adding the ability to mark a trust as an ignore/untrust, or some other semantically similar meaning. This would be complicated and just generally expensive + +## Security Considerations + +- Server-side manipulation: a homeserver's administrators are able to modify account data without notice, which could + be used to cause unexpected client/server behaviour. The aforementioned URL preview example + [was already a CVE in matrix-react-sdk][CVE-2024-42347], so additional care must be taken when considering followup + capabilities. ## Unstable prefix @@ -90,3 +107,8 @@ Until this proposal is accepted, implementations should make use of the account [1]: https://spec.matrix.org/unstable/client-server-api/#mignored_user_list [4283]: https://github.com/matrix-org/matrix-spec-proposals/pull/4283 [4155]: https://github.com/matrix-org/matrix-spec-proposals/pull/4155 +[CVE-2024-42347]: https://github.com/matrix-org/matrix-react-sdk/security/advisories/GHSA-f83w-wqhc-cfp4 + +## Dependencies + +None.