MSC4165: Remove own power level on deactivation #4165
Conversation
…they are in Signed-off-by: Matthias Ahouansou <[email protected]>
tulir
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Server
There was a problem hiding this comment.
conduwuit implementation: x86pup/conduwuit@e9e5fe2
There was a problem hiding this comment.
I've tested the conduwuit implementation working - I was able to deactivate my account on fost.re when migrating to tomfos.tr and it correctly dropped its own powerlevels in all rooms it was able to do so. This is a great feature to have, and saved a lot of manual changes! Thanks so much! 🎉
tulir
removed
the
needs-implementation
| - If the auth rules for the room allow doing so, send a new `m.room.power_levels` event identical to the | ||
| current state, with the exception of the field for the current user inside `users` removed. | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
I'm not sure how much of a problem it is in practice, but currently the MSC leaves it open to design that user DMs will also drop power levels.
I didn't consider this factor in the conduwuit implementation until after real-world usage of it on transfem.dev, and because conduwuit is very fast it's not really a problem. But I'm not sure if anyone has any input on whether we should be filtering out DMs or not.
The only situation I can think of where it could be relevant is if the account gets reactivated, and instead of making a new DM the other side invites the reactivated account to the same room. But even then power level 100 isn't required for a DM to function normally.
Either way, just something I noticed after implementing and using this. Maybe it would make Synapse slightly happier (load-wise) if it filters out DMs.
5 participants
Rendered