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

MSC4165: Remove own power level on deactivation #4165

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Kladki
Copy link
Contributor

@Kladki Kladki commented Jul 6, 2024

…they are in

Signed-off-by: Matthias Ahouansou <matthias@ahouansou.cz>
@tulir tulir added proposal A matrix spec change proposal client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Jul 7, 2024
Copy link
Member

@tulir tulir Jul 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • Server

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

Copy link

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! 🎉

@tulir tulir removed the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Sep 30, 2024
- 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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants