Give us back ILAG guest login, please!

[r4dh4l]

Description

I already mentioned this in https://github.com/vector-im/riot-web/issues/8808#issuecomment-465797492 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 vector-im/element-web#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

[r4dh4l]

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

Good point but this could be done by adjusting the naming convention of guest accounts. Given, the guest account expiration is 24h (home server settings) the a guest account created on 2019-10-11 13-42-46 would expire on 2019-10-12 13-42-46 and the MXID of a guest account would indicate this as @guest_expiring2019-10-12_13-42-46_r4dh4l:matrix.org.

Would this solve the problem?

...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

Yes, sry, you are right but my suggestion was pointing on how it should look like after the guest account creation would have beed adjusted according to my suggestion.

[r4dh4l]

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.

Thx, didn't know that but since riot-web unde riot.im is currently the best working client for the most use cases other clients are no solution for inviting people who have never used a [matrix] client before.

[zigurana]

Just want to chime in and reiterate that the throw-away nature of guest accounts is actually a feature, not a bug.

To consider the lack of a proper upgrade path for such users more important than an easy and hassle-free first experience with matrix/riot is putting the cart before the horse, imho.

I can't even recall a website that even offers an upgrade path for explicit guest-accounts, so why is it such an important aspect here?

[r4dh4l]

I can't even recall a website that even offers an upgrade path for explicit guest-accounts, so why is it such an important aspect here?

Sry, what do you mean with "upgrade path"?

[zigurana]

Not my term, @t3chguy used it to explain why guest accounts might be problematic for users who decide to stick around, and want to retain the 'history' they have amassed until then. If guest-accounts are truly temporary, that wouldn't be possible, or at least technically difficult.

My point is that there is no expectation of such a feature. Even if there was, it would be of secondary importance compared to the first experience of newcomers (imho).

[sam1919]

I can confirm that I was able to read and write to a chat room with some friends of mine on riot.im in early January 2019. Account registration was not necessary. Later that year I retried and registration was necessary. So obviously this feature was disabled.

I think this should be re-enabled. Why not make the best solution possible, even it is "technically difficult"? IRC does this since ages. Let's focus on the core features not the shiny blinking illusionary ones.

[martindale]

Guest users is one of our primary use-cases, operating a public shoutbox that we're planning on replacing with a Matrix-backed chat. Without guests having the ability to chat, we're unable to move forward with these plans.

Further, our next feature is direct 1-on-1 IM with site visitors to assist them with account setup, which also requires the same feature. Would be nice to see this issue get some love soon. :pray:

[r4dh4l]

Not my term, @t3chguy used it to explain why guest accounts might be problematic for users who decide to stick around, and want to retain the 'history' they have amassed until then. If guest-accounts are truly temporary, that wouldn't be possible, or at least technically difficult. My point is that there is no expectation of such a feature. Even if there was, it would be of secondary importance compared to the first experience of newcomers (imho).

As explained in https://github.com/vector-im/riot-web/issues/9264#issuecomment-541030546 this is just a question of how riot "emphasizes" guest mode. If someone uses riot in guest mode and the look&feel is so similar to registered mode that the user forgets the guest status so that he*she would be disappointed loosing a chat history than the the guest mode is not implemented in the right way. Deducing from a possible disapponting user experience that a feature is not wanted or needed in any way is a little bit exaggerated, isn't it?

[zigurana]

Fully agreed!

[MurzNN]

So, maybe implement "WhatsApp" mode, when user enter only phone number (or email) for quickly start talking (without filling password and make full registration process)? And later he will can restore access to this account via phone/email.

[motey]

So, maybe implement "WhatsApp" mode, when user enter only phone number (or email) for quickly start talking (without filling password and make full registration process)? And later he will can restore access to this account via phone/email.

That would be against principles of data economy. Why should every guest forced leaving his email/phone. A guest mode should be "click the link, start talking and maybe if you want you can register later" only. I like @r4dh4l idea of making it very clear in the UI that you are just an anonymous guest.

[tgr]

Agreed that no-authentication guest accounts are an important feature when transitioning from IRC which is often used for support forums which try to minimize friction, and that not having a transition path from such a guest to a real account is OK. Also agreed that the guest-ness should be clear to the user (e.g. via a permanent banner) and to others (username should start with guest- or something like that).

[Evidlo]

Situations that warrant Guest accounts are usually one-off meetings (e.g. advisor meeting, project meeting video conference). These individuals are likely not interested in becoming regular Matrix users and are not willing to go through any sign up process. Account persistence is really not an issue when one is looking for "disposable chat".

As a recent example, I am a TA for a course at my university where I meet with several groups of students weekly. Because of coronavirus, the university has moved classes online and this meetings will occur remotely for the next few weeks.

Since Guest access is disabled, Matrix is off the table and the class is likely to use some proprietary Cisco solution instead.

[martindale]

Dropping users straight into the chat (like in the RPG Shoutbox) is a huge boost to our conversions, since users can see the ongoing conversation without the registration wall. Really hoping this receives some attention soon or we're going to have to move on as well.

[MurzNN]

Discord have good implementation of guest accounts long time, Riot can implement same UI for them.

[r4dh4l]

As a recent example, I am a TA for a course at my university where I meet with several groups of students weekly. Because of coronavirus, the university has moved classes online and this meetings will occur remotely for the next few weeks.

Thx @Evidlo - this can't be emphasized enough. Just today I got a mail of my university that the IT there evaluates new services to improve digital teaching in the coming weeks. It is a perfect time to propose matrix (I just did) as collaboration messenger - with a working Guest login the chances would be much better to convince persons in charge!

[r4dh4l]

Dropping users straight into the chat (like in the RPG Shoutbox) is a huge boost to our conversions, ...

@martindale this is possible (if I understood you right): https://riot.im/app/#/room/#example:matrix.org - but now there is the registration wall. Before Riot version 1.0 you could directly join the chat.

[martindale]

Dropping users straight into the chat (like in the RPG Shoutbox) is a huge boost to our conversions, ...

@martindale this is possible (if I understood you right): https://riot.im/app/#/room/#example:matrix.org - but now there is the registration wall. Before Riot version 1.0 you could directly join the chat.

Yep. The link https://chat.roleplaygateway.com/#/room/#shoutbox:roleplaygateway.com now leads to a registration wall, decreasing our conversions by > 70%.

[JLTastet]

As a recent example, I am a TA for a course at my university where I meet with several groups of students weekly. Because of coronavirus, the university has moved classes online and this meetings will occur remotely for the next few weeks.

Thx @Evidlo - this can't be emphasized enough. Just today I got a mail of my university that the IT there evaluates new services to improve digital teaching in the coming weeks. It is a perfect time to propose matrix (I just did) as collaboration messenger - with a working Guest login the chances would be much better to convince persons in charge!

I am also considering proposing Riot (w/ Jitsi integration) for remote collaboration & meetings during the lockdown. Having some way of allowing guests to quickly join through the web interface using a link would be incredibly useful, although I fully agree that we should make it clear that guest accounts will quickly expire.

From my user point of view, I could think of the following UI. When opening the link, I would be greeted by the same dialog box as now, but with a second option "Join the conversation as guest" where I can set my displayed name and connect (like e.g. Vidyo does). There you can put a big warning sign saying something along the lines of "Guest accounts are temporary. See what it means for you." with either a link to a FAQ or a clickable (?) symbol displaying additional information. This information can be replicated in the permanent banner proposed by @tgr.

Just adding my two cents :)

[geckolinux]

This is absolutely necessary, I'm afraid. When some proprietary message solution fails in the middle of a meeting, I need to be able to send everyone a quick message saying: Try Riot/Matrix with this link. If it "just works" it creates a very positive impression, and significantly lowers the bar of entry for non-technical users.

[svoop]

Also, the time is now!

A lot of people are foced to switch to online communication for private and professional use due to corona related "curfews". Transient guest access is a tiny problem. The much bigger one are users choosing privacy-ignoring alternatives with guest access instead... and then sticking to them because, you know, the human being is lazy.

[martindale]

I remember seeing some work being done on automatic removal of idle accounts, or something like that, is there any way to quickly combine the two initiatives and get ILAG back?

[GHNW]

Just wanted to add some anecdotal support for this. I've had queries from 3 groups suddenly needing to work remotely due to the virus. Not knowing this feature was disabled I sold Riot to them as an easy solution on the basis that 'you can just send someone a link and they can join the conversation'.

Not a complaint - hasn't affected me beyond needing to work out why I couldn't do this anymore - but @martindale, @svoop, @geckolinux etc. are right that this being re-enabled would be a big boost to adoption at the perfect time. As it is, one of my queries has decided to use Microsoft Teams, one Skype, and the other is just using the phone. Opportunity lost to get them on board but if this can be done quickly it could still enable a major influx of new users.

[martindale]

After much searching, I found the commit which theoretically could be reversed to re-enable ILAG: 31ae35771dcf019f3a304c7e04b2f3bc6b3b9b55 (accompanying PR vector-im/element-web#2536)

I'll give this a shot and report back within the week.

[hillbicks]

Also, the time is now!

A lot of people are foced to switch to online communication for private and professional use due to corona related "curfews". Transient guest access is a tiny problem. The much bigger one are users choosing privacy-ignoring alternatives with guest access instead... and then sticking to them because, you know, the human being is lazy.

I agree 100%. There never was bigger demand for (private) video conferencing software than now and adoption greatly depends on ease of access. I can explain to my customers and friends and family that they will loose their history and most of them won't care. But they will care if they have to register for the service when they only want to use it once or twice.

Someone already said it, having a guest login is more important in the current situation than being able to transfer history from guest to user account. But that's just my 2 cents. :)

[almereyda]

What about the current workaround to invite users by email?

Could we eventually imagone to generate invite links that allow a semi-open access for 'known' guests?

This could also be interesting for invitations that don't follow the email route.

Some links might allow multiple sign ups, others could be one time tokens.

Increasing the adoption rate might not be the core motivation here, but rather at least providing a user journey that redirects a newly registered user to the room they intended to join the conversation.

Right now after the first login, right after confirming the Sydent token (with email registration, not counting LDAP or SAML), the user is redirected to the start page. There won't be any sign of the room they wished to enter. If they are lucky, the room is published to the directory, they find that through 'Explore' and scroll or search enough to finish off where they started.

hillbicks notifications@github.com schrieb am Di., 24. März 2020, 15:57:

Also, the time is now!

A lot of people are foced to switch to online communication for private and professional use due to corona related "curfews". Transient guest access is a tiny problem. The much bigger one are users choosing privacy-ignoring alternatives with guest access instead... and then sticking to them because, you know, the human being is lazy.

I agree 100%. There never was bigger demand for (private) video conferencing software than now and adoption greatly depends on ease of access. I can explain to my customers and friends and family that they will loose their history and most of them won't care. But they will care if they have to register for the service when they only want to use it once or twice.

Someone already said it, having a guest login is more important in the current situation than being able to transfer history from guest to user account. But that's just my 2 cents. :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vector-im/riot-web/issues/9264#issuecomment-603288305, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMRV7BMKHABRK6IXJ7OYJLRJDC7LANCNFSM4HAUW56A .

[danielweck]

I fully support the (re)introduction of guest users, i.e. inviting people via shareable links so they can join chat rooms without having to set up an account beforehand. This is in high demand due to older demographics being very reluctant to having to remember additional username+passwords, web URL, etc., or just because of temporary / sporadic use of the messaging facility which does not justify trusting a web service provider with personal information (even if only the initial email address that confirms the account registration).

[ara4n]

Hi folks - I was discussing this with @nadonomy today, and we were trying to get to the bottom of what folks are really asking for here. Please vote with emoji reactions:

Vote 🚀 if you want the ability for a guest user to start viewing a public room read only, and then register an account if they want to speak, and be transported back to the right room having created an account.

Vote 🎉if you want the ability for a guest user to start viewing a public room read only, and then specify a username and create an account if they want to speak, and then later specify a password if they want to keep that account for the future?

🚀 is in theory what we have today, but in practice can be clunky and unreliable. 🎉 is what ILAG used to be, before we removed it when implementing GDPR. Our concern is that 🎉simply doesn't work well given the complexities of setting up a new account these days - you have to explicitly accept GDPR, and you have to explicitly set up E2EE in order to backup your keys or get ready to cross-sign. It's worth noting that even Discord, which inspired ILAG in the first place, no longer does it. So, we're wondering whether folks are more complaining here that 🚀 doesn't work, or really pining for 🎉.

[KopfKrieg]

Maybe I missed that, but what about invitation links to private rooms for guests? Or is this already covered by the whole process and a guest only needs to pick a username and that's it? (In the future, I know it's not implemented yet)