[Feature request] Add account switcher

[VityaSchel]

fuck it, close this if you want, but at least it will be saved in issues history.

Please add account switcher to app. Preferably with unlimited accounts, or at least not three as in telegram official client.

It would help user to protect its identity and be more anonymous when using separate accounts.

Technically, I don't see any problem here with moving private/pub keys to separate dirs for each account and global app settings to shared dir. I haven't looked at the android client code yet, so tell me if there is anything that prevents this feature from implementation other than code refactoring :)

Concepts: Here are some concepts of ux that you could use.

1. User taps on profile picture, goes to settings screen. But there is a scroll view where pfp currently is. Like a roulette. you can scroll profile pictures horizontally and switch between accounts by doing this. This concept is taken from Yandex.mail mobile app. Last element is always plus sign (or any other icon) that indicates login initial screen where you get when you open app first time, like create new account or recover with phrase.
2. User can tap on profile picture and open settings. Or it can hold profile picture and see list of available accounts with profile pictures and usernames. It can switch account by tapping on any item or tap on last list item to add new account.
3. Or you can straight up steal UI from Telegram and move settings button to burger menu (left nav bar, I forgot how it's called in mobile dev :p). By tapping on profile picture, user opens this menu. In this menu user can see all accounts and some options like settings, about app, sign out.

I wish I could help by writing some code, but I don't know Jaba vaba so I hope dev team will be able to implement this feature without pr

[hjubb]

Thanks for the issue @VityaSchel, this one is definitely on the roadmap. As it stands it's probably a bit of a technical overhaul to support multiple accounts, but probably not impossible in the future. If you're looking for an immediate workaround I've seen people talking about applications that can sandbox multiple instances of the app under different profiles that have worked flawlessly. Though I can't remember them off the top of my head as I only saw them briefly mentioned a long time ago in the Session open group.

Your UX ideas will be helpful in planning multiple accounts in the future, as we don't track users to get feedback, will pass those ideas along and as a feature will probably get bumped as a priority since people are requesting it :+1:

[hjubb]

I think off the top of my head the biggest issues just from an implementation perspective is migrating to support multiple keys for user accounts, and making sure that all the associated data is isolated enough apart from each other, and that it gets removed if people delete multiple accounts off their device. There's probably also a slight UX issue as you highlighted just in terms of making sure it isn't confusing and it's easy enough to navigate different profiles. The harder issues might be making sure that the network is separated enough that it would still try to maximise the anonymity so that different accounts aren't easily linkable by re-using the same routes etc but I think those are just design considerations not really an impossibility.

[2011]

I wonder if you could have (a la certain cryptocurrencies) a master account that could (optionally) create additional accounts as needed (from the master account). That would certainly make it easier to restore multiple accounts (from one recovery phrase instead of several). I like the idea of using different accounts in different contexts, and if session ever becomes popular enough where people frequently give their accounts publicly (or perhaps even to web sites as a contact mode), having the ability to manage multiple accounts in a very systematic manner seems like an advantage.

[VityaSchel]

I wonder if you could have (a la certain cryptocurrencies) a master account that could (optionally) create additional accounts as needed (from the master account). That would certainly make it easier to restore multiple accounts (from one recovery phrase instead of several). I like the idea of using different accounts in different contexts, and if session ever becomes popular enough where people frequently give their accounts publicly (or perhaps even to web sites as a contact mode), having the ability to manage multiple accounts in a very systematic manner seems like an advantage.

doesn't seem like it's possible with the current implementation of e2ee (or what is this thing with public and private keys called)

I would rather find any simple online tool for encryption, put all phrases there together with nicknames to recognize which one is who and then encrypt it all with another key or password. What I just described is basically any modern password manager so you might as well use an existing solution to keep mnemonic phrases.

[2011]

doesn't seem like it's possible with the current implementation of e2ee (or what is this thing with public and private keys called)

I don't understand why not. A "master public key" generates additional public keys (identities). It has little relationship with transport encryption.

I would rather find any simple online tool for encryption, put all phrases there together with nicknames to recognize which one is who and then encrypt it all with another key or password. What I just described is basically any modern password manager so you might as well use an existing solution to keep mnemonic phrases.

You might prefer this (and I never suggested that Session should require deterministic identities - just offer them as an option), but (as an example), at this moment, my password manager has 424 entries. If my number of unique Session contacts grew to that size, and I needed to add a new device, it would require a significant amount of effort to set that device up, while the implementation of deterministic identities would eliminate much of that work.

[KeeJef]

Useful discussion but closing as duplicate of https://github.com/oxen-io/session-android-temp/issues/740