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

[WIP] MSC3842: Placeholder for power levels & extensible events #3842

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

turt2live
Copy link
Member

@turt2live turt2live added proposal A matrix spec change proposal client-server Client-Server API kind:core MSC which is critical to the protocol's success labels Jul 2, 2022
@turt2live turt2live self-assigned this Jul 2, 2022
@@ -0,0 +1,40 @@
# MSC3842: Power levels on message (extensible) events
Copy link
Member Author

Choose a reason for hiding this comment

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

Thought: when a client decrypts a message, it will need to determine if that event still meets the power levels, but with extensible events it's trivial to bypass "you can't send images" (for example) because you can just create a custom event type with m.image fallback.

If we solve the problem by making power levels apply to content blocks, we're potentially causing problems because an m.poll.start might be legal for senders, but m.image is ignored. Some clients would render the event while others wouldn't.

A potential solution might be dual consideration? If the event type is specifically listed in the power levels, assign that required PL to the event. If the event type isn't in the power levels, instead try to look for the implied events for fallback representations. If those implied event types are further not specifically listed, then the event is presumed allowed.

This would allow a room to support m.poll.start, for example, but prevent a malicious user from inventing an event type to spam images. There's still potential risk that a client doesn't support polls and therefore ends up picking the m.image representation, but presumably we can further have clients verify that the implied fallback representation's event type is also allowed, with m.text always being allowed for fallback.

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:core MSC which is critical to the protocol's success proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant