From 0ffae883bf59780c76f754135b15de05d79c97a5 Mon Sep 17 00:00:00 2001 From: nexy7574 Date: Thu, 12 Jun 2025 22:53:14 +0100 Subject: [PATCH] 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 000000000..ec2c1fcf2 --- /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`. +