ILAG apparently confusing

[t3chguy]

seems like people are not realising that when choosing their username this is going to mean that it will not be usable in the future, not similar to say IRC where the username can be used as soon as you stop using it in this instance, some wording/warning will be handy

[lampholder]

If it's working as designed then there is wording, but anecdotally it sounds like we're not shouting loud enough :(

How clear a picture do we have of how often this is happening? Have you heard about this from lots of people, or one or two?

FWIW I'm convinced this is an area that needs more attention - just trying to assess how we prioritise it against other stuff.

[t3chguy]

I've heard about it from around 5 over the course of a fortnight

[lampholder]

Thanks - that's useful. I'll talk to M&A about prioritising this.

[cavebeat]

hi,

i'm running homeserver on matrix.mydomain.tld and riot.mydomain.tld for the web-client

and want to have a link/landing_page to a single public listed room which is available for non-tech-savy users. similar to https://webchat.freenode.net/ preloaded with a roomname and with a username "anon-$nnn" or "guest-$nnn"

in my matrix/homeserver.yaml i enabled the allow_guest_access from False to True

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: False

changed the settings in the riot-room and selected "Anyone who knows the room's link, including guests":

WHO CAN ACCESS THIS ROOM?
Only people who have been invited
Anyone who knows the room's link, apart from guests
Anyone who knows the room's link, including guests

i created with matrix.to a link to my public room:
https://riot.mydomain.tld/app/#/room/#public_room:matrix.mydomain.tld

Joined the rooms as "guest1", signed out and joined as "guest2"

basically it works. as expected

The problems which i now encounter:
in riot-web there are no guest accounts.
@guest1:matrix.mydomain.tld and @guest2:matrix.mydomain.tld are registered users. a username is necessary to register, that's it. The usernames are now burned and not reuseable.

IMHO: registered_USER != guest_user
they are not what i expect as a guest user.
Both users are still in the room idle forever.
there is no purge idle users after hours/days/weeks/months/years/decades/centurys/milleniums...

What i have expected:
If a username is taken without password, it should be possible to sign-in without password unless a password is taken. if the user is logged-in, no other user can log in without passwd. if a passwd is set, login can only happen with password.
If a guest account is created, it should be a non-persisting user which is removed from the room after n minutes non-usage/non-connection.

What is mileading me here and confuses me:
the setting in matrix/homeserver.yaml is talking about: "anonymous users."
Logging in as a guest in riot-web is not anonymous, it's a fully registered user. It's not logging in, it's registering.

also the "> WHO CAN ACCESS THIS ROOM?" is misleading here for me. because there are no guest in riot-web. only fully registered users.
Only people who have been invited -> invite only is clear
Anyone who knows the room's link, apart from guests -> should be renamed to "Anyone who knows the room's link" without the part ", apart from guests" because there are no guests in riot-web.
Anyone who knows the room's link, including guests --> is rendered useless in riot-web.

thank's to the the folks in the chat which tried to explain me this a few times, i start to understand now. It still feels wrong for me to name "registering user without password" as "guest" and drop "non-persistent/anon-guest" access completely.

seems like people are not realising that when choosing their username this is going to mean that it will not be usable in the future, not similar to say IRC where the @username can be used as soon as you stop using it in this instance, some wording/warning will be handy

[t3chguy]

it was never non-persistent access, thats just the nature of matrix. Even guests persisted...

[uhoreg]

When you Riot prompts you to create an account, the only indication that it's a real account is the text "This will be your account name..." which is small (hence nobody will read), and doesn't directly say that it will create an actual account.

I think something like this would make things more clear:

To get started, please create an account

username: ____________
password: ____________ (optional)*
homeserver: https://matrix.org [switch homeserver]
* you may set a password later, but if you do not set a password, then your selected username will not be usable after you leave

If you already have a Matrix account you can _log in_ instead

[guest2]

Hello I have no clue what y'all are talking about please stop emailing me

…

On Aug 15, 2017 6:44 AM, "Hubert Chathi" ***@***.***> wrote: When you Riot prompts you to create an account, the only indication that it's a real account is the text "This will be your account name..." which is small (hence nobody will read), and doesn't directly say that it will create an actual account. [image: image] <https://user-images.githubusercontent.com/1012976/29315957-eb9878fa-8193-11e7-9d9f-091252b9c7eb.png> I think something like this would make things more clear: To get started, please create an account username: ____________ password: ____________ (optional)* homeserver: https://matrix.org [switch homeserver] * you may set a password later, but if you do not set a password, then your selected username will not be usable after you leave If you already have a Matrix account you can _log in_ instead — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4724 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGnfZwJ70Wpu2P-BJ8Z0aFzk8vcJxpO-ks5sYZK9gaJpZM4Op7Fl> .

[uhoreg]

@guest2, GitHub marked you as a participant in this issue because someone unintentionally mentioned your username in a comment. Unfortunately, it looks like you are the only one who can unsubscribe yourself, but it isn't hard to do. You just need to log into your GitHub account, go to this issue, and click on the "Unsubscribe" button on the right-hand side.

[cavebeat]

i guess he still get's emailed for direct mentions.

[erdnaxeli]

Idea : the non persistent notion could be implemented in synapse instead of the protocol. After some times of inactivity, synapse could emit a leave for the user in every room he has joined, then just remove the account from its database.

The only drawback I see is that if the user was invited in some room, the invitation would still be pending. Maybe the HS could also discard any invitation? Is that enough?

[t3chguy]

The bigger drawback is if that user gave another their MXID, the other person later reaching out and finding someone else at that MXID

[lampholder]

Yeah; we're basically 100% committed to not recycling mxids, because it would mean you could no longer rely on message history.

There are alternatives we could consider, though. I haven't thought it through in detail, but something along the lines of Battlenet's unique id suffix (potentially optional per homeserver) could work - you'd choose your mxid, but it would be suffixed with a unique id (a la tom.98743296:matrix.org) - the UX would only need to emphasise the unique component when needed for disambiguation.

[erdnaxeli]

Actually Matthew repeats in every presentation that the mxid should not be seen by the users, so the UI could generate a totally random one (like a UUID) and just set the display name.

[ara4n]

The intention that mxids are invisible is currently aspirational, given we use them to disambiguate users with the same displayname in the UI. and powerusers like them. so i don't think we can make them UUIDs unless we have a really good reason - eg decoupling them from DNS and making them public keys

[erdnaxeli]

I mean just for guests it could @<uuid>:<HS>, without any prefix. Le 22 août 2017 12:49, "Matthew Hodgson" <[email protected]> a écrit :

…

The intention that mxids are invisible is currently aspirational, given we use them to disambiguate users with the same displayname in the UI. and powerusers like them. so i don't think we can make them UUIDs unless we have a really good reason - eg decoupling them from DNS and making them public keys — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4724 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdQ0eV676q8-MpmV95yjrTGp_0mOG0jks5sarJKgaJpZM4Op7Fl> .

[t3chguy]

@erdnaxeli
That's what guests already does, but ILAG means riot doesn't use guests any more and instead forces you to register early on.

[gkiagia]

Oh wow, I just realized this the hard way... This ILAG (whatever it means) is totally misleading. I am a member of a team who needs a chat with guest access (it's a radio station chat where we want listeners to be able to join and send messages to the producer without making an account) and we chose matrix for this job because it seemed to have guest account support.... Now with this, we are just "burning" usernames from the matrix.org homeserver, I guess (we are temporarily hosted there), while filling our channel with dead nicknames and and pissing off users that can't join again with the same nickname.

[cavebeat]

@gkiagia yes, you are totally right. it's annoying and misleading, but there are no guest users in matrix/synapse. if you register at monday as a guest with a nickname, and do not set a password, you wont be able to reuse the account/nickname on tuesday again. it's already burned. AND you can never delete it again from your homeserver.
welcome to the club of enlightened non-guests. :(

[t3chguy]

There are guests in matrix and synapse. Simply riot does not make use of them.

[richvdh]

hasn't ilag gone away? can we close this?

[turt2live]

we're holding it open as a way to remember how awful it was when/if we get around to re-implementing it.

[t3chguy]

We can hold onto it whilst still putting it in the grave