-
Notifications
You must be signed in to change notification settings - Fork 8
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
Add Multi Account Support #756
Comments
+1 for multiple accounts. Very important feature for any messaging app and is lacking in many messaging apps. Only good messaging app with multiple accounts is Jami. |
This feature would be highly useful! Are there any plans on implementing multiple accounts? |
Yes, its something we plan to do in the future |
I was going to open a new thread, but fortunately driven by curiosity I searched. I also would like having multi account management. It is useful to differentiate the intended use. For example a Session ID for work, one for family, one for friends and one for social networks and public life. If it will be developed I also would like having the possibility to activate/deactivate (on/off) every single account through a dedicated switch. In short, the switch interrupts the incoming communication for the specific Session ID. It would also be useful to match a local label (30 characters max) for each Session ID in order to remember the intended use. |
Definitely +1 for Multi Account. I currently have 2 IDs which I would need to have on my mobile. A temporary workaround would be to publish 2 apk files with different APP ID, so one can install session 2 times on the mobile. Thank you for your great work. |
There's no reason not to implement this right now other than various nefarious purposes of user tracking across chats and groups. If Session is claiming to be a messenger concerned with privacy, every new chat (private or group) should automatically have a new key generated and we should be given the option to change user profile immediately before joining chat to not leak meta data to listeners across multiple channels. Please make this a priority or let us know where in the code to look to hack together a fork that respects metadata privacy. Otherwise Session doesn't pass OpSec for anonymous operation. Here metadata refers to public key and profile data collected by a recipient tracking keys across multiple channels, not by the swarm. |
please make this priority! so difficult to do anonymous operations without this :( |
@vsatmydynipnet you can install the one in the fdroid repo that session host, and also one in official fdroid repo :) and plus work profile. makes four of them for you in total |
SimpleX finally has the right idea. Perhaps SimpleX over Lokinet is the way forward. |
@qm3ster Yes, I agree. But connecting multiple devices is so easy on Session that's why I still use :( |
Instead of manually managing multiple accounts (each with their own seed), would it be possible to have sub-addresses? Same seed, but when I share my public address I can select/label a sub-address in which all of them get routed to me when polling a node. Maybe going as far as Stealth Addresses, automatic unique sub-address for each contact you chat with. |
Is it still a feature that is being worked on? Please, it will be very helpful. Here we are multiple people in a public place with the same device so it is a must. Otherwise, is there a workaround in the meanwhile? Thanks! |
I found a workaround until it is implemented... There are apps to clone application. I tried "Multiple Accounts - Dual Space" and it worked to clone once without paying Session and have two accounts at the same time. On Desktop, it is possible to create a shortcut and launch it specially for it to work, see the instructions in the similar issue about Multiple Account in the Github of Session/desktop. |
Still a planned feature, but we aren't working on this one right now, focusing on app reliability and groups/closed groups currently |
Since the other person (to whom friend requests is sent) can see who the user is, it is obvious (as you also stated in the whitepaper) that a person should be able to use more than one accounts (i.e. Session ID). But the app only supports a single account.
The text was updated successfully, but these errors were encountered: