Well “logging in” means in these architectures pbkdf [1] based (and similar) and “password never leaving computer” but the pbkdf result (and more misc tech details) simply pointing to your “master record” and thus credentials on the already existing and persistent network, does mean you can “log in” a.k.a. access this piece of essential primary data. Accessing doesnt have limits or means limited to certain number of sessions or times. Access limits imposed could maybe implemented via higher level means but do not come as a fundamental property of such networks.
[1] compare PBKDF2 - Wikipedia
The moment your knowledge of these credential(s) (pbkdf and more, the stuff you type into the launcher) become shared, you have essentially lost your soley control to this initial boostrap piece of data that is the root objcect to your account.
This doesnt necessarily mean that you are completely hosed. In fact back in the old days, some of us still with wuala and trying to advocate for some implementation of neat features, there was the demand of a related situation. The wuala gui could save (for the lazy, but meaning strings attached) the credentials, and eventually there were quite a number of wuala users, who simply forgot their credentials.
As long as this wuala instance (and in fact some cookie and magic data and similar local stuff that had been saved to the locally wuala running machine) was still available and doing okay, the user could still access its wuala account. Wuala used pbkdf and similar as well, it never sent passwords across anywhere by design, one could always and every time “log in” aka access the account that was distributed amongst all wuala participating nodes and such. So well the users forgot their credentials, and it had been asked if wuala folks could not simply implement a function into the gui, that would recreate and rewrite this root object of the users account and be able to request a new protecting password from the user on the locally running gui. According to my understanding this would have been a possible implementation, but the wuala guys never approved of or never cared.
Another use case would be you forgetting your logged in account on some remote location, friends machine, library, work, relatives or wherever or you being paranoid and not sure about all the plenty places your stuff is in use, so you can simply override with that special recreate root object function, and all other active “sessions” would simply eventually fail to access this (now changed) object and fall or drop out again from accessing the users sub-tree as the top-level objects properties have changed.
This is of course not a means to prevent a evildoer who does have hold of your valid credentials, and then him being first to do this root-object change instead of you, and thus locking you out of your own stuff, so dont mistake it as a solution for that fundamental problem.
But re-securing a maybe shared account would be very much possible with a feature and implementation I guess.
Guess lessons learned about this for anyone implementing related stuff: Either never allow for a user to save their credentials and essential information into the depths of some gui and high level launcher app or similar, or offer such a re-set function when there is still access to the base object of an account for the user to regain full access to the re-created root object again in case of lost credentials. This is not a send me my password function.