-
Notifications
You must be signed in to change notification settings - Fork 383
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
MSC4165: Remove own power level on deactivation #4165
base: main
Are you sure you want to change the base?
MSC4165: Remove own power level on deactivation #4165
Conversation
…they are in Signed-off-by: Matthias Ahouansou <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation requirements:
- Server
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conduwuit implementation: girlbossceo/conduwuit@e9e5fe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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! 🎉
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Rendered