MSC3419: Allow guests to send more event types (#3419)

* MSC3419 - Guest state events

Let guests send state events. Needed for guests to work with native
group voip in #3401

* typo

* Update 3419-guest-state-events.md

incorporate @clokep clarification

* also let guests send non-m.room.message events in general.

* Update proposals/3419-guest-state-events.md

Co-authored-by: Richard van der Hoff <[email protected]>

* Update proposals/3419-guest-state-events.md

Co-authored-by: Richard van der Hoff <[email protected]>

* wordwrap

Co-authored-by: Richard van der Hoff <[email protected]>

Author: ara4n

proposals/3419-guest-state-events.md

@@ -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.