Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invisible crypto: Put a marker in the timeline that shows when a user's identity changed #2493

Open
Tracked by #2491
richvdh opened this issue Aug 2, 2024 · 4 comments

Comments

@richvdh
Copy link
Member

richvdh commented Aug 2, 2024

Part of #2491, itself part of Invisible crypto.

We would like to show, in the timeline, when a user's cryptographic identity changes.

We want different wording depending on whether or not the user was verified.


Questions

  • Should identity changes for invited (ie, not-yet-joined) members be shown? I think so, if the room config allows history visibility to invited users (in which case we will encrypt for them). What if the room config has changed since the identity change?
  • Where should the "Learn more" links go? I think the intention is to link to something on https://element.io/help? We'll need to make sure the website is updated before we implement this, so that we have something to link to. Who will take this on?

Figma designs (from https://www.figma.com/design/0oUTCbYhROEDprSp7bdWhx/Reset-Crypto-Identity-(temp)):

Web (verified user):

image

Web (unverfied user):

image

Mobile (verified user):

image

Mobile (unverified user):

image

@richvdh
Copy link
Member Author

richvdh commented Aug 2, 2024

I can't really remember how we decided to implement this. Possibly we could make use of the SenderData attached to the megolm sessions used by the events in the timeline? But that only really works if there are messages from the affected user both before and after their identity change, within the timeline. So do we need a separate store of the history of identity changes that we've seen? (That might help with #2494 anyway)

@richvdh
Copy link
Member Author

richvdh commented Aug 8, 2024

I can't really remember how we decided to implement this.

After discussion: we will need to keep a table in the CryptoStore which records all observed identity changes, for each user, with a timestamp.

Still TBD: how do we actually extract the information from that table in a form that is useful for display in the timeline? It could be thousands of users to look up, for a big room. The Web and EX implementations are likely to look quite different.

@richvdh
Copy link
Member Author

richvdh commented Aug 21, 2024

@americanrefugee has shared designs for this at #2492 (comment)

@richvdh
Copy link
Member Author

richvdh commented Aug 22, 2024

Some thoughts on implementing this:

Within the crypto crate, we can maintain a list of identity changes, indexed by user and timestamp. This would be updated on the result of a /keys/query. This should be simple matter of programming, modulo an annoying amount of boilerplate for updating the store implementations.

We then need to expose this to the UI. For element-web, I think this would look something like:

  • We give TimelineWindow a new property which maintains a list of identity changes.
  • When TimelineWindow is first load()ed for an encrypted room (ie, when a room is opened), we fire off a background process which will:
    1. Load the room members, if we don't already have them
    2. Walk all the events in the the loaded timelineset to make sure we have all the relevant users, and establish the earliest event in the timelineset
    3. Send a request to the crypto layer to get all the identity changes for all the users, in the relevant time frame.
    4. Emit a signal to tell the UI components to re-render
  • When rendering the timeline, the UI component does its best to mix together the events with the identity changes based on timestamp. It attempts to filter identities to be shown based on the user's membership at the time of the identity change.
  • Whenever the TimelineWindow paginates, it makes another request to the crypto layer to get more updates.
  • The TimelineWindow also registers a hook with the crypto layer, to receive updates to identities, and adds them to the list of changes.

General theme is that the list of identity changes can be lazily populated in the background, to avoid slowing down room changes.

TODO: figure out how this would look in EX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant