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

MSC3419: Allow guests to send more event types #3419

Merged
merged 7 commits into from
Dec 8, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions proposals/3419-guest-state-events.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
# Guest State Events

## Problem

Currently guest users are not allowed to create arbitrary state events. This is
a problem for [MSC3401](https://github.com/matrix-org/matrix-doc/pull/3401),
where it would be useful for guests to be able to create `m.call.member` events
in order to participate in a call.

## Proposal

Let guests send arbitrary state events much like a normal user. Servers may rate
limit state events from guests much more aggressively to mitigate abuse.

We also relax the existing requirement that guests are only allowed to send
`m.room.message` events, instead allowing them to send any kind of event
allowed by the room's power level configuration as if they were a normal user.

## Security considerations

The only reason that guests are denied from performing certain operations is to
avoid malicious unauthorised users consuming resources and causing a DoS. In
this instance, sending state events can be quite resource intensive, so if we
didn't have a good use case that needed them it'd be right to veto them.

Also, by default, users (guest or otherwise) can't send state events, which
further reduces the risk of abuse. Instead, a room intended for guest-capable
voice/video rooms as per MSC3401 would explicitly set a powerlevel to let users
send `m.call.member` events. This MSC would simply make it then permissible
for guests to send as well as non-guests, subject to the powerlevels.

## Alternatives

Rather than using guest access, apps could use shared secret registration to
work around this limitation. However, that feels like a different MSC.