Incremental registration.

[ara4n]

Recording the conclusions of how guests should work, based on discussion with Robert & Jake:

• Users start off as Matrix guest users. These are numeric users which are not allowed to create rooms, invite users, etc. As of MSC3419: Allow guests to send more event types matrix-org/matrix-spec-proposals#3419, they are allowed to set state events, but this hasn't made it into synapse yet as the MSC hasn't been FCP'd (although we should). However, this doesn't matter that much if the default homeserver we run against the default instance lets guests set state events, and we can make it a requirement for the server used by other deployments to support guests setting state events, until it gets merged into mainline synapse & spec.
• As a guest:
  • you can join rooms if you know their URL, but you are required to create a real account before you can join any rooms in the public rooms list on the server (for accountability, and anti-spam). One way to enforce this serverside would be to disable guest access at the Matrix level on the publicly advertised rooms.
  • you can't create rooms
• If you try to do something as a guest which you need a real account to do, you are prompted to set a username. This is used to create a "named guest" account - what we've called PWLU (passwordless user) in the past. In practice, this is just calling /register for the given username with a randomly generated password which isn't shown to the user. This might involve exposing reCAPTCHA or other registration flows that the homeserver might have. You can then use the app as normal.
• As a PWLU, you get a nag banner across the top saying "If you want to use this username in future, please create an account!"
  • This prompts you to set a password, which applied to the PWLU user account and you now have a proper reusable Matrix account.

[robertlong]

This is now pushed to staging