Atoki/discussion
4
5
Fork 1
Code Issues 32 Pull requests 2 Projects Wiki Activity

Removing profile changes from the event graph #18

New issue
Open
opened 2023-08-01 18:35:22 +02:00 by iliana · 7 comments
iliana commented 2023-08-01 18:35:22 +02:00
Copy link

(Standard disclaimer I'll put on all my issues: I have hardly ever looked at the Matrix spec, and all my understanding of it is from observing its implementations. There will be incorrect information; for my sake please only provide technical corrections if they are relevant to the issue at hand.)

When a user changes their display name or profile picture, a m.room.member event is added to the event graph of every room they are a member of. This has a number of problems (probably more than what's on this list):

  1. Efficiency. A user in hundreds of rooms will need to wait for their Matrix client to update every single room.
  2. Moderation/abuse. If someone changes their name or picture to something offensive, this is logged and displayed in every room, multiplying moderation workload. Element informs users trying to redact a m.room.member event that doing so may cause various consistency issues (imo at no point should moderating a room result in consistency issues if at all possible).
  3. Names/pictures on older messages do not change. This behavior reflects IRC nick changes, but not e.g. Discord/Slack where display name / picture updates apply retroactively.

My suggestion would be to maintain profile data separately from the event graph. However given that this is a federated protocol there needs to be some way for the user's homeserver to notify other homeservers that a profile update has occurred. This could possibly be done outside the event graph, or a "please re-fetch profile data" message intended to be invisble to end users could be injected in the event graph.

Fully removing profile changes from the event graph would remove the potential ability to end-to-end encrypt profile information and have per-room profile information. The latter is technically possible in some Matrix clients today (I think? I've seen it before) but most clients will ignore if you've done this and override all rooms if you change any profile data.

(Standard disclaimer I'll put on all my issues: I have hardly ever looked at the Matrix spec, and all my understanding of it is from observing its implementations. There will be incorrect information; for my sake please only provide technical corrections if they are relevant to the issue at hand.) When a user changes their display name or profile picture, a `m.room.member` event is added to the event graph of every room they are a member of. This has a number of problems (probably more than what's on this list): 1. **Efficiency.** A user in hundreds of rooms will need to wait for their Matrix client to update every single room. 1. **Moderation/abuse.** If someone changes their name or picture to something offensive, this is logged and displayed in every room, multiplying moderation workload. Element informs users trying to redact a `m.room.member` event that doing so may cause various consistency issues (imo at no point should moderating a room result in consistency issues if at all possible). 1. **Names/pictures on older messages do not change.** This behavior reflects IRC nick changes, but not e.g. Discord/Slack where display name / picture updates apply retroactively. My suggestion would be to maintain profile data separately from the event graph. However given that this is a federated protocol there needs to be some way for the user's homeserver to notify other homeservers that a profile update has occurred. This could possibly be done outside the event graph, or a "please re-fetch profile data" message intended to be invisble to end users could be injected in the event graph. Fully removing profile changes from the event graph would remove the potential ability to end-to-end encrypt profile information and have per-room profile information. The latter is technically possible in some Matrix clients today (I think? I've seen it before) but most clients will ignore if you've done this and override all rooms if you change any profile data.
artemis_everfree commented 2023-08-01 21:58:00 +02:00
Copy link

per-room profile information is important to maintain I think, for the same reasons that discord allows setting per-guild display names / profile pictures: different social contexts may require different presentations.

I think if we were to also pursue #14, it would be possible to support per-room profile data by the same means: users could create an identity and tell their client to set that as the default identity to use within a given room (or heck, even a given space).

per-room profile information is important to maintain I think, for the same reasons that discord allows setting per-guild display names / profile pictures: different social contexts may require different presentations. I think if we were to also pursue https://git.atoki.org/Atoki/discussion/issues/14, it would be possible to support per-room profile data by the same means: users could create an identity and tell their client to set that as the default identity to use within a given room (or heck, even a given space).
👍 1
zocker.net commented 2023-08-02 10:42:13 +02:00
Copy link

I think decoupling the room profile from the event type "m.room.member" is a huge improvement already, as (so you, the author, gets to know the technical background better) these are currently state events, which, as of now, cannot be deleted at all as they are required to calculate the state of the room (e.g. was someone then a member). So it’s not only filling up your local timeline, but also the servers as well. If they get decoupled, which should not require that many changes for now, the events making up a profile could become normal events, which servers or clients can just ignore or delete, if there are old enough. (I’m proposing this solution in the case that fully reimplementing profiles takes too much time (A better solution now is still helps more now than a perfect solution in a few decades)).

However, if the profiles get fully decoupled from rooms at all, which could take more work but IMO should be better in the long term, a "please re-fetch profile data" hint could even become an ephemeral event so these don’t get added to the persistent event graph However, then we would need another solution for recording profile changes in history.

I think decoupling the room profile from the event type "m.room.member" is a huge improvement already, as (so you, the author, gets to know the technical background better) these are currently state events, which, as of now, cannot be deleted at all as they are required to calculate the state of the room (e.g. was someone then a member). So it’s not only filling up your local timeline, but also the servers as well. If they get decoupled, which should not require that many changes for now, the events making up a profile could become normal events, which servers or clients can just ignore or delete, if there are old enough. (I’m proposing this solution in the case that fully reimplementing profiles takes too much time (A better solution now is still helps more now than a perfect solution in a few decades)). However, if the profiles get fully decoupled from rooms at all, which could take more work but IMO should be better in the long term, a "please re-fetch profile data" hint could even become an ephemeral event so these don’t get added to the persistent event graph However, then we would need another solution for recording profile changes in history.
👍 1
rory.gay commented 2023-08-06 18:44:07 +02:00
Copy link

I feel like these should remain in the event graph, especially in context of your third point.
This kind of stuff starts to matter a lot for eg. plural creatures using a single account. Discord requires PluralKit for this since discord does retroactively update them.

I feel like these should remain in the event graph, especially in context of your third point. This kind of stuff starts to matter a lot for eg. plural creatures using a single account. Discord requires PluralKit for this since discord does retroactively update them.
iliana commented 2023-08-06 19:42:14 +02:00
Author
Copy link

I think users should have full control over whether old messages/mentions/etc reference their display name and avatar at the time they sent it or retroactively changing it. I personally find a chat protocol that does not retroactively update my profile information to be completely unusable to me for various emotional reasons, but I accept that we should make it possible to avoid retroactive profile changes. I hope this can be done in a way that doesn't involve the room graph and its significant efficiency/usability disadvantages.

Tangentially, something my partner reminded me of after reading this: they attempted to use Matrix and a tool they wrote to update their display name/avatar as they switched, but found it completely jumbled the recency order of all of your rooms because of the room events.

I think users should have full control over whether old messages/mentions/etc reference their display name and avatar at the time they sent it or retroactively changing it. I personally find a chat protocol that does not retroactively update my profile information to be completely unusable to me for various emotional reasons, but I accept that we should make it possible to avoid retroactive profile changes. I hope this can be done in a way that doesn't involve the room graph and its significant efficiency/usability disadvantages. Tangentially, something my partner reminded me of after reading this: they attempted to use Matrix and a tool they wrote to update their display name/avatar as they switched, but found it completely jumbled the recency order of all of your rooms because of the room events.
zocker.net commented 2023-08-08 11:44:22 +02:00
Copy link

I have an idea how to take care of both concerns. I ask for feedback, be it more social or technical considerations. However, such implementation as I propose here would require an external store for the profiles (e.g. new APIs or profile room).

  • Given any external profile store.
  • Each profile must have an unique ID in that store.
  • Profiles must be encrypted.
  • When using the profile, along the user id, the profile id & its key must be attached to a message.
  • The content of profiles must be immutable. However they may be redacted.
  • If a profile should be changed, a new must be created & used in the future.
  • If a profile should be not used for historic messages, it may be redacted by the user.
    • This redaction must point to a successor profile (with id&key) to use for historic messages.
    • Redactions (or at least the key of the new profile) must be encrypted with the key of the old profile.
    • A profile may be redacted multiple times.
    • Only the latest redaction is the one to follow for now.
  • One exception to the encryption: There is one public profile.
    • It must not be encrypted OR if required, it must be encrypted with a world-known key (username, 00…0, …)
    • It’s id must be publicly known.
    • It is used when no other profile is associated (e.g. outside of a room, no message sent yet, …)
  • (optional) Clients may track where which profiles were used (for the user & to improve sending the redaction hints).
  • (optional) Profile redactions may be hinted to all rooms (where that profile was used).
  • (optional) Clients may track all known profiles of other users to allow recipients connecting those profiles easier.

(optional here means what I consider optional in reference of this proposal.)

Open questions to discuss:

  • Should a user be allowed to only use one profile per room?
    • to avoid random impersonations
    • to avoid confusion among room members
  • Should a profile (with key) be sent when joining?
    • Otherwise newly joined users may not be indentified until they send their first message with the intended profile
Considerations

Considerations

(mostly from me now, I may add/ref points from others here)

Identifiers

  • If the external profile store is a Matrix room, the profile identifier might be the event id of the profile’s event.

Immutable (vs. Mutable) Profiles

Advantages (of Immutable)

  • They allow for a clean history where no one can hide, that he had used different settings back then. (However, mind that this proposal allows redacting older profiles).
  • Aside of checking regularly for a potential redaction, immutable profiles can just be cached.

Disadvantages (of Immutable)

  • Users which often change their profiles might end up with a lot of chunk they can/should not delete. Clients may still hide that through.
    • To avoid long profile redirections, when a profile gets redacted, which is the sucessor of an older profile, the older one should be redacted again to point to the new successor directly.

Access Control

  • Profiles may contain sensitive data. If a user uses a single profile in only one unecrypted, but non-public room, they expect their profile to be „secret“.
  • If a user redacts a message, access to the used profile is redacted as well (as always, given all servers & clients follow that redaction).
  • Implementing a new access control scheme to allow non-encrypted profiles is more work. That’s why all should be encrypted.
  • Leveraging the encryption for a profile room has following problems (due to being in a room):
    • For encrpytion to work in a room, the receiver needs to be a member of that room.
    • In a room, it is expected that all members can read all messages (since they were allowed to). Encrypting to just a few users is possible, but not feasible.
    • Having a room where all recipients of all messages of a single user are members sounds like a really bad idea.
  • Encrypting profiles should be possible & secure with symmetric keys.
  • Redactions must be encrypted as well to ensure confidentialty of the successor profile.

For Profile Rooms

If profile rooms may be used, this proposal has following advantages there:

  • Profile rooms may be peakable by all users as no access control or membership is required.
    • however, other data in that room (e.g. usage tracking) must not be public
I have an idea how to take care of both concerns. I ask for feedback, be it more social or technical considerations. However, such implementation as I propose here would require an external store for the profiles (e.g. new APIs or profile room). - Given any external profile store. - Each profile must have an unique ID in that store. - Profiles must be encrypted. - When using the profile, along the user id, the profile id & its key must be attached to a message. - The content of profiles must be immutable. However they may be redacted. - If a profile should be changed, a new must be created & used in the future. - If a profile should be not used for historic messages, it may be redacted by the user. - This redaction must point to a successor profile (with id&key) to use for historic messages. - Redactions (or at least the key of the new profile) must be encrypted with the key of the old profile. - A profile may be redacted multiple times. - Only the latest redaction is the one to follow for now. - One exception to the encryption: There is one public profile. - It must not be encrypted OR if required, it must be encrypted with a world-known key (username, 00…0, …) - It’s id must be publicly known. - It is used when no other profile is associated (e.g. outside of a room, no message sent yet, …) - (optional) Clients may track where which profiles were used (for the user & to improve sending the redaction hints). - (optional) Profile redactions may be hinted to all rooms (where that profile was used). - (optional) Clients may track all known profiles of other users to allow recipients connecting those profiles easier. (optional here means what I consider optional in reference of this proposal.) Open questions to discuss: - Should a user be allowed to only use one profile per room? - to avoid random impersonations - to avoid confusion among room members - Should a profile (with key) be sent when joining? - Otherwise newly joined users may not be indentified until they send their first message with the intended profile <details> <summary>Considerations</summary> ## Considerations (mostly from me now, I may add/ref points from others here) ### Identifiers - If the external profile store is a Matrix room, the profile identifier might be the event id of the profile’s event. ### Immutable (vs. Mutable) Profiles #### Advantages (of Immutable) - They allow for a clean history where no one can hide, that he had used different settings back then. (However, mind that this proposal allows redacting older profiles). - Aside of checking regularly for a potential redaction, immutable profiles can just be cached. #### Disadvantages (of Immutable) - Users which often change their profiles might end up with a lot of chunk they can/should not delete. Clients may still hide that through. - To avoid long profile redirections, when a profile gets redacted, which is the sucessor of an older profile, the older one should be redacted again to point to the new successor directly. ### Access Control - Profiles may contain sensitive data. If a user uses a single profile in only one unecrypted, but non-public room, they expect their profile to be „secret“. - If a user redacts a message, access to the used profile is redacted as well (as always, given all servers & clients follow that redaction). - Implementing a new access control scheme to allow non-encrypted profiles is more work. That’s why all should be encrypted. - Leveraging the encryption for a profile room has following problems (due to being in a room): - For encrpytion to work in a room, the receiver needs to be a member of that room. - In a room, it is expected that all members can read all messages (since they were allowed to). Encrypting to just a few users is possible, but not feasible. - Having a room where all recipients of all messages of a single user are members sounds like a really bad idea. - Encrypting profiles should be possible & secure with symmetric keys. - Redactions must be encrypted as well to ensure confidentialty of the successor profile. ### For Profile Rooms If profile rooms may be used, this proposal has following advantages there: - Profile rooms may be peakable by all users as no access control or membership is required. - however, other data in that room (e.g. usage tracking) must not be public </details>
rory.gay commented 2025-01-16 22:57:23 +01:00
Copy link

How do you plan to make encrypted profiles work with SDKs or clients that dont support encryption (for technical reasons, such as not having a single f*ing clue how encryption works)?
Should i not be able to render a profile at all?

How do you plan to make encrypted profiles work with SDKs or clients that dont support encryption (for technical reasons, such as not having a single f\*ing clue how encryption works)? Should i not be able to render a profile at all?
SunoAwen commented 2025-01-18 01:49:33 +01:00
Copy link

How do you plan to make encrypted profiles work with SDKs or clients that dont support encryption (for technical reasons, such as not having a single f*ing clue how encryption works)?
Should i not be able to render a profile at all?

There is a lot going on here, so let us answer as best we can.

Encryption can be difficult, yeah, that's why it's best to use pre-existing libraries etc and don't necessarily try to do the cryptography on you&r own.

I would suggest that if you& can't figure out how to do a client that can do encryption then either ask for help from others or perhaps it might not be a good idea to make one especially since Matrix/Atoki relies on end-to-end encryption to some degree, so you& will always run into that problem.

> How do you plan to make encrypted profiles work with SDKs or clients that dont support encryption (for technical reasons, such as not having a single f\*ing clue how encryption works)? > Should i not be able to render a profile at all? There is a lot going on here, so let us answer as best we can. Encryption can be difficult, yeah, that's why it's best to use pre-existing libraries etc and don't necessarily try to do the cryptography on you&r own. I would suggest that if you& can't figure out how to do a client that can do encryption then either ask for help from others or perhaps it might not be a good idea to make one especially since Matrix/Atoki relies on end-to-end encryption to some degree, so you& will always run into that problem.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Atoki/discussion#18
No description provided.