Give us back ILAG guest login, please!

[r4dh4l]

Description

I already mentioned this in #8808 (comment) but maybe the issue topic is not emphasizing my point:

Before Riot 1.0 it was possible to join a room without creating an account. Yes, choosing a user name was actually technically creating an account on the according home server but in perspective of the user it was a way to join a conversation without the registration procedure.
This feature is very essential in my opinion because you could invite users on project pages to a project room without bothering them to create an account in the first place.

Steps to reproduce

1. Join a room with allows guest access via Riot web app.
2. Press "Click here to join the discussion!" and you will get an info box for "Registration Required". Before Riot 1.0 you could just choose a username and join the room.

Describe how what happens differs from what you expected.

After "Click here to join the discussion!" I would like to see a button "Join as guest" next to "Cancel", "Register" (and maybe "Join with existing Account").
Edit:
After "Join as guest" there should be an input field with pre-generated username like @guest_expiring2019-10-12_13-42-46_<CustomPart>:matrix.org while only <CustomPart> can be edited. This would mean:

• that the guest account expiration is 24h (this could be a home server setting/default)
• the a guest account was created on 2019-10-11 13:42:46
• the guest account will expire on 2019-10-12 13:42:46.

This way a guest account would clearly indicate that

• it is a guest account
• it is not possible to contact such an account after 2019-10-12 13:42:46

• Platform: web

For the web app:

• Browser: Firefox
• OS: GNU/Linux Debian
• URL: riot.im/app

[t3chguy]

The issue is creating an account is irreversible, so the usernames become burned when someone stops using the "guest" account as matrix doesn't support account deletion for various privacy/access permissions reasons.
A lot of people complained they logged out and didn't set an email so can no longer use their usernames

[ara4n]

hang on though - Riot 1.0 hasn't deliberately removed any guest access. The change @t3chguy describes happened ages ago (Riot 0.11 or something).

You should still be able to view a guest-accessible room without having to create an account.

[t3chguy]

Didn't ILAG get disabled for 1.0? The magical thing which created an account with password in the background with a username of your choosing

[ara4n]

oh, i see - yes, ILAG got disabled, mainly because we didn't have time to adopt it for the new login flows. So the problem isn't that guest login is missing (it's there as much as ever), but registering-real-accounts-for-guests-in-the-background is missing.

[r4dh4l]

thx @t3chguy for your reply.

The issue is creating an account is irreversible, so the usernames become burned when someone stops using the "guest" account as matrix doesn't support account deletion for various privacy/access permissions reasons.

I understand but a pre-generated guest name like guest885e24fa1c wouldn't "burn" anything someone would like to use later AND indicate that the currently used account is a guest account. ;)

A lot of people complained they logged out and didn't set an email so can no longer use their usernames

Well, a "join as guest" button with an according warning would be enough to avoid complaining users (at least those who are willing to read and think before clicking a button).

Thx @ara4n for your reply as well.

So the problem isn't that guest login is missing (it's there as much as ever), but registering-real-accounts-for-guests-in-the-background is missing.

So should I rename the issue title to "Registering real accounts for guests in the background is missing"?

Edit: Just noticed the title was already renamed. Don't know what "ILAG" means but it seems okay for you devs. ;)

[t3chguy]

But then he issue is that an account with a username like guestXXXXX is undesirable and account migration is not a feature of the protocol at this time so users might end up stuck with a crappy username

[r4dh4l]

There is no need for an account migration in my opinion.

Related to the case of "undesirable usernames": Let's take a look on the possibilties a user without a Matrix ID has when invited to a room and has the choice between

• "Cancel"
• "Register"
• "Join with existing account"
• "Join as guest"

Let's assume the user chooses "join as guest" and gets the username guest885e24fa1c with an explicit info like

Guest accounts are intended to provide users room access for public rooms without forcing them to register an account and for just a single session. If you want to use a more personalized account and want to participate in long-term you should register a standard account (giving you the possibility to choose a user name of your choice).

If the user is not happy with the username guest885e24fa1c the user would obviously choose to go back and register a personal account.

At the moment the situation is like this: Because Matrix offered to access rooms as guest I promoted this feature on quite a lot of pages with "feel free to join our matrix channel (guest account/without registration possible)". Now theses users end up on a page forcing them to register an account. The "I don't care where I create an account"-faction won't have a problem to do this, but the "we actually don't like to create an account just to participate in a short conversation"-faction will not (the latter is the one I try to address with a federated, free messenger system like Matrix).

[jtagcat]

Merged issue from #9316 I'd suggest to Change the title to just "Better signup flow" @r4dh4l

Issue

Currently, when you open a link like this, you are required to sign up. With Matrix.org/Riot.im being so small, it is a real obstacle on getting new users to even try it.
I direct people at my riot link, they come back and say:

• It required an a account
• Wasn't fast enough
• ew login page, I'm not giving my details away
  Remember, new people probably do not know, that Riot.im can let you Communicate the way you want - a universal secure chat app entirely under your control and just want to chat.
  Also the Register button as seen below unconsciously means give me your email and password please, to people who don't know riot.

Current flow:

1. The page loads for 10s long, you need to press register
2. after 5-10s Register form loads, oh no they need my details! I think of an username for 10s, gonna reuse my unsecure password! +5s
3. Captcha (on chrome +5-20s, on firefox +15-50s). If you decide to enter an email you get punished by also needing to confirm the email (let an account be for few days, without confirming email please) +60s notice: if you use email you will also not get the start chatting button in the tab the email opened in! or if you choose to not use email, you will get a prompt to use an email +5s for click
4. You finally solve the captcha and maybe had to go to your inbox, the page loads for 5sec, you get a sound notification, the riot-bot wants your attention! (stop it for users registered via a link to chat with somebody), you get the start chatting button, you press it, you wait 10sec and chat.

The flow is pretty bad and has many clicks and annoyances. I did it faster at 2 minutes, a normal user will take even more. At this point you have probably forgotten, why are you even in riot, especially when opening my link and using email verification the start chat disappears to the original tab. (note in the gif I use keyboard shortcut to switch back to the original tab, to show the start chat, peek didn't capture my tabs)
I have tried not comparing to Di***rd, but there you are in with 10s + choosing an username 10s The faster, the better, I'd call below 40s good for Riot.

video, converted for faster viewing

Instead:

After clicking a link to initiate chat, automatically create the user a temporary account, what can be only be logged on to with cookies, the account expires say after a week:
a) have the account on matrix.org
b) if it is an issue for the public servers, make this feature exclusive to custom domain users, for example if my account is @jtagcat:domain.tld, clicking my link would make you an account @temp569:domain.tld or have the user choose only an username.
The account should be upgradable to a real account (to convert temp users to real users).
A new user does not have many rooms or people, I suggest using the dark purple area for a small introduction of riot and an enter password (and email) field.
If we can copy the few sent messages from @temp569:matrix.org (or change the username and/or server), give them the normal sign up form right there. It is important that the form is not hidden behind a link.

If I am unclear, please ask! I hope the flow gets fixed, tough I don't know any JS (yet) in order to help, I contribute via opencollective.

[tgr]

This would be very useful for using Riot as an IRC webchat interface. E.g. for Freenode people are currently using webchat.freenode.net, which is rather ugly and does not show past messages (so if you join, ask a question and leave, there is no way to see the answers you have got), Riot would be a great replacement for that, except casual users will abandon it rather than register.

[jtagcat]

@tgr I would just point out that https://kiwiirc.com/ is a good option for irc (though it doesn't hold the history).

[r4dh4l]

Watching the label of this issue changing from "fire" to "" to "bug": May I ask what is the problem to enable guest login again?

[t3chguy]

Guests led to a bad long-term experience, given there is no proper upgrade path, so if you start off on a guest account you need to register a proper account later on if you want to be able to access it long-term and then you need to get a new username, need to rejoin rooms etc

[r4dh4l]

Guests led to a bad long-term experience, given there is no proper upgrade path, so if you start off on a guest account you need to register a proper account later on if you want to be able to access it long-term and then you need to get a new username, need to rejoin rooms etc

Okay but the reason for this is just that the UI didn't explain well what guest accounts are about. What about my initial idea

After "Join as guest" there should be an input field with pre-generated username like tempuser<RandomGenerated40bitHexKey>_CustomPart (40bit Hex-Key or something) allowing the guest to adjust CustomPart (this would prevent guests to choose probably already existing user names).
The guest login process should end up with an info box that guest accounts will be deleted after X hours (defined by the home server settings).

?

Currently the "bad long-term experience" is that I've promoted [matrix] as communication network you don't need to register an account if you don't want to which made it very easy to invite external people to conversations (for an interview etc). A whole use case of [matrix] suddenly died by disabling the guest login.

[t3chguy]

Guests are notated by their usernames being just numbers, so that suggestion doesn't work. As for deletion of accounts, it can only cause confusion, what if I learn that my friend is @13214:matrix.org then X hours later it could be someone else and I may have told them some private information accidentally

[t3chguy]

A whole use case of [matrix] suddenly died by disabling the guest login.

[matrix] still supports it, just modern versions of riot-web does not, there are other clients which do/can support it.

[MurzNN]

But now, when I opening some room via link in private mode, eg https://riot.im/develop/#/room/#riot:matrix.org - I got a numeric login such @3452484:matrix.org, @3470601:matrix.org, etc. Isn't it the guest (readonly) mode?

[r4dh4l]

Guests are notated by their usernames being just numbers, so that suggestion doesn't work. As for deletion of accounts, it can only cause confusion, what if I learn that my friend is @13214:matrix.org then X hours later it could be someone else and I may have told them some private information accidentally

Okay, that's a point but this can be prevented if we say:

The guest login process should end up with an info box that guest accounts will be disabled after X hours (defined by the home server settings) to prevent that someone else could ever use this account again.

[t3chguy]

So this issue is actually really confusing,
ILAG and Guest access are two different things.

Riot-web currently supports guests in a read-only capacity, when in fact guests can actually join and interact with most public rooms, this was taken away in favour of ILAG.

Project ILAG (Improved Landing as a Guest) actually made you choose a username and behind the scenes generated a password and registered you as transparently as possible, prompting you to set a password later. This allowed transparent access but too many people lost access to their accounts as they never bothered to set an e-mail or password and did not realize they were registering a proper account because it was too seamless, this led to it too being scrapped.

[t3chguy]

Okay, that's a point but this can be prevented if we say:

The guest login process should end up with an info box that guest accounts will be disabled after X hours (defined by the home server settings) to prevent that someone else could ever use this account again.

it doesn't fix it for users on different homeservers. Lets say I'm on my own HS, with no guest accounts and talking to a matrix.org guest who expires after X hours, at the discretion and settings of matrix.org, how do I know when they registered and precisely when they expire so I know that they may have become a different user

[r4dh4l]

So this issue is actually really confusing,
ILAG and Guest access are two different things.

Maybe but I was told to rename the issue title this way.

Riot-web currently supports guests in a read-only capacity, when in fact guests can actually join and interact with most public rooms, this was taken away in favour of ILAG.

Project ILAG (Improved Landing as a Guest) actually made you choose a username and behind the scenes generated a password and registered you as transparently as possible, prompting you to set a password later. This allowed transparent access but too many people lost access to their accounts as they never bothered to set an e-mail or password and did not realize they were registering a proper account because it was too seamless, this led to it too being scrapped.

...which is, as I tried to explain, just a lack of explanation in the UI joining as guest and the way "guest MXIDs" were created (they should start with "temp" or "guest" indicating that this is a special, temporal account/MXID).

[t3chguy]

...which is, as I tried to explain, just a lack of explanation in the UI joining as guest and the way "guest MXIDs" were created (they should start with "temp" or "guest" indicating that this is a special, temporal account/MXID).

in ILAG the accounts which were made were real accounts

[hex-m]

Hi! Any updates on this? Or is there a different Issue for that?

The feature is currently on the roadmap in the "later" section under the name "Incremental Signup".

It was also mentioned in a blog post, that it may come in 2021.

Incremental Signup - Once upon a time, Element (Riot) had the ability to gradually sign-up without the user even really realising they’d signed up. We want to bring it back - perhaps this will be the year?

[tio-trom]

Ok I hope is what I was talking about (coming from another locked issue), like sharing such a room https://chat.trom.tf/#/room/#chat:matrix.trom.tf that is public, and be able to access it by anyone. On the web. No need to open in another app. We had that with NextCloud Talk https://www.drive.tromsite.com/call/j44iod3w and worked wonders and was super useful. That's what I was talking about at #18191

Will keep an eye on this issue then.

[hex-m]

Our friends from Guardian Project created a client called Convene which supports incremental sign-up. New accounts are created automatically and you can set a password if you plan to reuse it later. There is a demo.

Are there other (web-)clients that support this? FluffyChat currently doesn't.

Matthew mentioned in this years roundup blog-post that some new clients support it.

In practice, the only things from the list we haven’t got to [in 2021] are [...] and restoring incremental sign-up (although our new clients have it!).

[ShadowJonathan]

@hex-m does this create users which usernames are simply @guest1234... and such? Or did you (somehow) implement a stage where a user can choose their own username, somewhere along the way?

---

Also, IIRC, this feature was blocked exactly because of that problem, where users weren't able to change up their username down the line, and it creating a unpleasant situation. The solution feeling I got was simply to wait for seamless user migration capabilities (such as MSC1228) before going ahead with this, and that it stagnated on that blocker. (Though please correct me if I'm wrong)

[hex-m]

According to my tests you get a randomly generated user-id on their server. Those are technically not guest accounts - at least the rooms are not configured to "allow guest access".

---

To answer my own question: Cactus Comments is a web-client that supports guest access.

[probonopd]

That "solutiion" requires you to host a web application.
This functionality should be built natively into https://app.element.io/.

[geckolinux]

This would have been a really nice feature to have yesterday. When Slack went down a user asked me about alternatives for the team. I always recommend Matrix via Element, but getting the other team members to create a Matrix account and figure out the nomenclature and semantics of Matrix usernames and how to add them to a room for temporary usage during the time that Slack was down was a pain point.

[karolyi]

Quite honestly, this is the reason why I've installed my XMPP (Prosody) back after 10+ years, to set up anonymous/guest access.

As much as I like Matrix, it's not the end-all-be-all. I became active again on XMPP federated networks, and have seen that after 10+ years, Prosody have evolved a lot as well.

If you really need a self-hosted anonymous/guest room, I think XMPP is your best bet. There is even converse.js for it as a web client. See it in action on https://chat.prosody.im/

[geckolinux]

@karolyi Thanks for mentioning that alternative. The thing is, personally I need (and most non-technical users also need) a hosted solution, especially for the temporary usage scenario that I mentioned when a primary service goes down for a few hours, and there's no time or justification for setting up a self-hosted solution. (Of course I fully support self-hosted services and I don't understand why more companies and organizations don't have backup or even primary self-hosted open source communication platforms instead of being at the mercy of the mega commercial services.) In the case I mentioned yesterday, Element / Matrix just had too high of barrier to entry and the team didn't use it as far as I know. Back when guest users were allowed in Riot / Matrix it would have been a piece of cake to temporarily switch to it.

[karolyi]

@geckolinux I'm really unaffiliated, but if you need a hosted XMPP service: https://snikket.org/hosting/

[azmeuk]

Here is my usecase and why better guest users UX would help me:
My company offers a few services (mail, webdav, caldav, carddav, and synapse/element) for a small price. We use an OpenID Connect server to centralize all our users, so there is no "real" user on synapse. Our users are mainly non tech smartphone users. Our users can communicate with themselves, and this part is good. We would love to suggest them to replace whatsapp and other IM applications with element, so they can chat with their families, friends etc. For now this is way too complicated for us to generate usage on this front.

In an ideal world, only registered users would be able to create rooms, but anyone could join a room with an invitation link.
People would tell their folks to install element on their smartphone, then send invitation links by sms/mail/whatsapp.... A tap on the link this would automatically open the element application and join the room. If this is the first time the user launches the application, their name would be asked for.
Now the delicate part would probably be to upgrade the user. As we only use a SSO, that would mean redirect the user to our OIDC server registration page. So how would the newly created SSO account would match the old guest account? The only easy way I can think of would be to ask the guest users for an email or a phone number, or be sure the registration process redirects to the matrix app in the end.

We would be willing to pay a few hundred euros for this feature.

[turt2live]

While I don't have an update on full ILAG support, we are looking at ways to make the guest experience customisable. Stay tuned, and hopefully it'll cover some/all of the usecases here.

[Gredin67]

@turt2live Any news on this?

From my experience, guest users can only read rooms in which history is readable by anyone. In order to read/write in a room, this room should be listed in auto_join_rooms
If I'm right, at least the description "participate" of synapse config allow_guest_access is wrong.

# Allows users to register as guests without a password/email/etc, and
# participate in rooms hosted on this server which have been made
# accessible to anonymous users.
#
allow_guest_access: true

How can I set a room read/write by guest user without having this room auto-joined by all instance users? (auto_join_rooms empty)

[turt2live]

At the moment there's no real update on this - we're still going ahead with a module sort of setup for simple ILAG things, but at the moment Element Web doesn't formally support guests being able to write to rooms.

Getting support for certain features is best done in the support rooms. For synapse, that is #synapse:matrix.org on Matrix.

[almereyda]

For what it's worth, it appears the new P2P call.element.io does produce some kind of random matrix User Identifiers when logging in with a chosen Display Name, and does not require a password to join. Is this eventually related?

[turt2live]

it's a similar process to what ILAG would do, but it's a different project.

[almereyda]

What a pity. It exactly does what we expect here:

But good to know developers are aware of each other.

[almereyda]

And to continue from examples in the nearest neighbourhood of the ecosystem, https://github.com/vector-im/chatterbox also implements token-based "behind-the-scenes" registration/provisioning of (transient? / temporary?) user accounts for external visitors.

[kittykat]

Moving this issue to discussions in Element meta as we need to make a cross platform decision on how to proceed 👍

[almereyda]

Which is:

• Give us back ILAG guest login, please! element-meta#728

now.

[kittykat]

Hmm, looks like there's a bug with transferring issues right now. This URL should now automatically redirect to the discussion! I've reported the issue to GitHub.

Please follow the issue and continue any discussions at the link above

[almereyda]

Don't worry, it's not a bug. The redirect works perfectly for the originating issue 727 in meta, but not for this one in web.