MSC3759: Leave event metadata for deactivated users #3759
Conversation
Half-Shot
added
proposal
erikjohnston
added this to Needs idea feedback / initial review
in Spec Core Team Backlog
via automation
|
Author would like this reviewed for concept before going much further. |
| [MSC3720](https://github.com/matrix-org/matrix-spec-proposals/pull/3720) would help in solving this problem, | ||
| as services could lookup the status of a user when a leave event comes in and determine the deactivated | ||
| status. However this comes with two notable drawbacks: |
There was a problem hiding this comment.
I don't think MSC3720 is necessarily an alternative, this MSC could help end(s) be notified when such a thing has happened, while MSC3720 could be useful to query if such a thing has happened (for, say, clients which want to initiate a new DM with such a user).
To use words, I think this MSC synergises with MSC3720.
There was a problem hiding this comment.
This is more stating you could use MSC3720 without this MSC and still have the ability to detect deactivations, it would just be very unreliable.
| from their datastores. | ||
|
|
||
| It should be noted, like anything else in a Matrix event, that the key could be sent manually by a user | ||
| to "fake their own death". Services MUST not trust this key for actions where identifying the |
There was a problem hiding this comment.
Maybe MSC3720 could help with checking if this is absolutely the case.
However, the mention of "faking your own death" brings into question if this should be called m.deactivated at all, or if it should maybe have another name, if only to discern leaving "noisily" with leaving "quietly".
So as an alternative, maybe the key could be called m.quiet?
(It could open up a lot of other uses beyond account deactivation, for example if someone wants to leave the room "non-explicitly", or "quietly")
There was a problem hiding this comment.
Ultimately this MSC is intended to express the wishes of the user's action. I.e. I am deactivating my account, please delete all data about me.
I worry m.quiet doesn't express that intent as neatly as m.deactivate would.
However, the mention of "faking your own death" brings into question if this should be called m.deactivated at all, or if it should maybe have another name, if only to discern leaving "noisily" with leaving "quietly".
After thinking about it, maybe this is conceptually wrong. The sender isn't actually stating whether or not their account is deactivated, but how they would like recipients of the leave to act. "I would like you to delete data about me because I have told you via this metadata key".
There was a problem hiding this comment.
I'd like some clarity on how exactly this would benefit application services (and potentially homeservers/other users). It looks like it has parallels to MSC2438.
| Bridges are usually designed to interpret leave event from a user as a specific instruction to leave | ||
| a remote room. For instance, a user leaving a room bridged to WhatsApp is usually interpreted as the | ||
| user wanting to leave the remote side. However when the user **deactivates** their account, services | ||
| aren't able to distinguish the intent of the leave as an automated account cleanup actions, rather than |
There was a problem hiding this comment.
| aren't able to distinguish the intent of the leave as an automated account cleanup actions, rather than | |
| aren't able to distinguish the intent of the leave as an automated account cleanup action, rather than |
| a request to leave all remote bridged rooms. This lack of clarity leads to users finding themselves | ||
| completely parted from all their remote contacts, which is certainly not great. |
There was a problem hiding this comment.
I'm confused though... surely a user is parted from all of their contacts anyways if their account is deactivated?
I think it might help to provide a concrete example of where this feature would help.
| Adding a metadata key to leave events means that all users who shared a room with this user would be able | ||
| to tell that the user requested a deactivation, rather than just leaving a room. While this does give | ||
| away more information about the user, it would also allow any connected service as well as clients to remove | ||
| any information. This means that by virtue of including this key, more services can perform erase of a user |
There was a problem hiding this comment.
| any information. This means that by virtue of including this key, more services can perform erase of a user | |
| any information. This means that by virtue of including this key, more services can perform erasure of a user |
|
|
||
| It should be noted, like anything else in a Matrix event, that the key could be sent manually by a user | ||
| to "fake their own death". Services MUST not trust this key for actions where identifying the | ||
| deactivated status of a user is critical, but where it may only inconvience the user (such as deleting some |
There was a problem hiding this comment.
| deactivated status of a user is critical, but where it may only inconvience the user (such as deleting some | |
| deactivated status of a user is critical, but where it may only inconvenience the user (such as deleting some |
| status. However this comes with two notable drawbacks: | ||
|
|
||
| 1. The service would have to poll this endpoint upon *every* leave, which would likely cause more load | ||
| on the homeserver and the service requesting the information. This could be made event worse if the |
There was a problem hiding this comment.
| on the homeserver and the service requesting the information. This could be made event worse if the | |
| on the homeserver and the service requesting the information. This could be made even worse if the |
| // N.B this assumes that displayname and avatar_url are removed for privacy reasons during a | ||
| // deactivation | ||
| "membership": "leave", | ||
| "m.deactivated": true, |
There was a problem hiding this comment.
I could see this eventually becoming a stack of bools. Might it be better to have a:
"leave_type": "m.deactivated",or similar, which allows for further types in the future?
Also keep in mind that in Synapse we have the (unspecced) "erase" boolean parameter, which indicates whether you would like your personal data to be erased as much as is possible. That could potentially constitute two different leave types: m.deactivated, m.deactivated_erasure.
There was a problem hiding this comment.
This sounds like an interesting idea, could it possibly be combined together with MSC3217, to simplify its kick-type? (And make it mutually exclusive with this)
anoadragon453
removed this from Needs idea feedback / initial review
in Spec Core Team Backlog
I suppose this is in some ways an alternative to that, where this MSC wishes to put the information in the room timeline rather than developing specific handler endpoints. I'll find some time to lay out the pros and cons in the proposal. |
Rendered
Implementation (Synapse)