Onboarding: Improve Landing as Guest in Riot Web

[lampholder]

Github Project
Design Document

We want to make some changes to how Guest Access works in Riot Web, to make the experience smoother and less confusing. Specifically we want to provide a more complete Riot experience more quickly, and to avoid the awkward transition from guest account to full user.

This change does not impact the Matrix spec.

Riot Web will replace the current guest access with two categories of user:

• Read-Only Users (ROU): People who have clicked a permalink and want to read the contents of a room.
• Passwordless Users (PWLU): People who have accepted an invite/navigated to https://riot.im/app and want to get started before completing registration

Known Caveats

PWLUs will be in a risky position until they've completed registration - the mxid they've chosen will be lost forever if they don't complete registration by providing a password.

Tasks to support PWLUs

• Make Matrix support username availability check Make Synapse support username availability check element-web#3605

• Make Riot/Matrix able to handle PWLUs Implement a mechanism for Riot to generate and cache a user password element-web#3600

• Replace 'choose a displayname' dialogue with MXID picker Replace 'Choose a displayname' dialogue with a dialogue to choose a MXID element-web#3604

• Make Riot nag PWLUs to complete registration Nag-bar and dialog for Passwordless Users to provide password element-web#3602

• Provide mechanism to complete registration Improve Landing as Guest: Provide mechanism to complete registration element-web#3603

• Modify the user settings pane so that it doesn't reference a password the user doesn't know Don't prompt PWLUs for the password they don't know element-web#3748

• Evaluate CAPTCHA options Evaluate CAPTCHA options element-web#3606

• Integrate the chosen CAPTCHA Switch to the new CAPTCHA. element-web#3607

• For ROU make any interactive action trigger transition to PWLU For Read-Only Users, redirect any attempt at an interactive action to the prompt to choose a username. element-web#3608

• Make the left panel look sensible for ROU Make the left panel look sensible for Read-Only Users element-web#3609

User Flow

Unregistered user clicks a permalink

1. Assuming room permissions allow, the user is shown the full contents of the room as a Read-Only User
2. User can scroll backwards and forwards through history
3. If the user attempts any other interactive action, they are directed to transition to PWLU
   N.B. This will be implemented using the existing Guest access experience, so anything that works there currently (do RMs work?, etc.) should continue to work.

Unregistered user clicks link invitation to room

1. User is presented with a MXID picker: "Welcome to Riot - please choose a username"
2. User chooses a new username
3. Displayname defaults to username for now
4. User enters the invited room and can participate as a full user, albeit with a nag bar at the top letting them know they need to complete registration to use this username again in future

Unregistered user navigates to https://riot.im/app

Same as when clicking a link invitation to a room, but user experiences the standard app welcome

Unregistered user tries to perform an action

Same as when clicking a link invitation to a room, but user is returned to the room they were reading before

PWLU loves Riot and clicks the link in the nag bar to complete registration

1. User is presented with the mechanism to complete their registration
2. User completes registration and is returned to wherever they were before they clicked the registration link

PWLU loves Riot but forgets to complete registration

1. User picks a new username and mourns the permanent loss of the old one :( There is no way we would ever be able to recover or recycle the old MXID.

[freelock]

Hi,

Just reading up on the plans here... question: what if we have registration turned off on our homeserver?

We're starting to use guest accounts to invite clients to chat. The idea of a password-less user to get them started sounds great -- but we don't want to allow anyone to register on our server, without someone on our side taking action.

I was thinking of hooking up our own authentication system -- we would love to do something along the lines of what's being discussed in matrix-org/matrix-react-sdk#796, to automatically log in users based on being logged into another system.

For "anonymous" users, though, the PWLU approach sounds great -- if there's some admin user story for promoting the account to a full user. Perhaps the ability for an admin to either register the PWLU directly in Synapse and send a password, or the ability to "claim" the PWLU from an account generated by a 3rd party system that provides an integrated login. In our case, a PWLU would not be able to register on our server, though we could send them off to matrix.org or elsewhere...

[tessgadwa]

This is very well written and documented in detail. With that said, it may be a moot point but I do not see the utility of a PWLU. Why not simply have a prompt requesting the user set a password at the time they comment or otherwise interact with content? Also, it seems like permitting lots of temporary accounts could lead to problems with spam and abuse.

[lampholder]

@tessgadwa We have considered prompting for a password at this stage, but our focus is on reducing the barrier to new users' usefully engaging through the app as much as possible (whilst balancing against exposing ourselves to abuse, hence the captcha).

It might be that requesting a password at the same time as requesting a username has no impact on conversion, and that might be something we experiment with in the future, but for now we've decided to leave supplying a password to a subsequent step :)

[tessgadwa]

Totally cool. I'm just glad you're taking as much time as you are to think through these process flows.

[lampholder]

@freelock I need to think about this usecase some more :) (We are thinking about it - not ignoring you 😄 )

[lampholder]

@freelock how far off would I be characterising your usecase as:

We are Examplecorp and we want our clients to visit our own Riot instance at riot.examplecorp.com to chat with us on our Riot instance's default homeserver matrix.examplecorp.com.

We don't want our clients necessarily using matrix.examplecorp.com as their homeserver generally, though, since it:

• implies an 'internal' relationship between that client and Examplecorp through the :examplecorp.com domain part of their mxid
• incurs an ongoing maintenance/support burden

If the above is along the right lines, what are your thoughts on your clients' being registered with matrix.org instead of examplecorp.com? If the default homeserver for your riot instance were set to matrix.org (or indeed any homeserver accepting registrations) then your clients could have the user experience described here.

Of course if we just reconfigure the default homeserver on your riot instance then you and your colleagues would have to change the homeserver from the default every time you logged in (you could patch your login page to fix this, or we could find another solution).

What are your thoughts?

@ara4n @AmandineLP it think it's worth your having a look at this too :)

[jcgruenhage]

Just to be sure, loosing the MXID requires the browser to loose it's local storage, or the user to intentionally log out, right? The session should be kept open even if the user closed the tab, right?

Also, isn't it possible to create a dialog when a user closes a tab? Loosing MXIDs like that seems rather avoidable in the most cases.

[mxnemu]

Hello, I wanted to use riot as an iframed chat for a video streaming site and noticed the following landing related problems riot still has.

1. The site is unreadable in narrow views. ILAG: Landing on Riot with a narrow screen gives no hints as to how to continue element-web#4729
2. ROUs don't receive new events.
3. After becoming a PWLU in a channel you are redirected to the startpage instead of staying in the same room.

here is an example of the use of riot I had in mind:

[poVoq]

This got actually remarkably worse with the recent redesign of riot.im :(
Any chance there is a way to re-enable the previous portal welcome page with easy access to channels open to read only guests?

[jryans]

Any chance there is a way to re-enable the previous portal welcome page with easy access to channels open to read only guests?

Please file a new issue describing your use case so we can better understand the issue. This particular issue is more of a task list for an old project.