-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ILAG apparently confusing #4724
Comments
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. |
I've heard about it from around 5 over the course of a fortnight |
Thanks - that's useful. I'll talk to M&A about prioritising this. |
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
changed the settings in the riot-room and selected "Anyone who knows the room's link, including guests":
i created with matrix.to a link to my public room: Joined the rooms as "guest1", signed out and joined as "guest2" basically it works. as expected The problems which i now encounter: IMHO: registered_USER != guest_user What i have expected: What is mileading me here and confuses me: also the "> WHO CAN ACCESS THIS ROOM?" is misleading here for me. because there are no guest in riot-web. only fully registered users. 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.
|
it was never non-persistent access, thats just the nature of matrix. Even guests persisted... |
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:
|
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>
.
|
@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. |
i guess he still get's emailed for direct mentions. |
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? |
The bigger drawback is if that user gave another their MXID, the other person later reaching out and finding someone else at that MXID |
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 |
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. |
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 |
I mean just for guests it could @<uuid>:<HS>, without any prefix.
Le 22 août 2017 12:49, "Matthew Hodgson" <notifications@github.com> 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>
.
|
@erdnaxeli |
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. |
@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. |
There are guests in matrix and synapse. Simply riot does not make use of them. |
hasn't ilag gone away? can we close this? |
we're holding it open as a way to remember how awful it was when/if we get around to re-implementing it. |
We can hold onto it whilst still putting it in the grave |
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
The text was updated successfully, but these errors were encountered: