Multiple account

[ptman]

Your use case

What would you like to do?

Login to multiple accounts from the same Element app.

Why would you like to do it?

To access multiple accounts simultaneously.

How would you like to achieve it?

Ideally I would be able to switch between seeing a mix of rooms from all accounts and restricting the view to one account.

Have you considered any alternatives?

I've been using multiple different clients on my phone for years, but different clients have different featuresets.

Additional context

Because of the rewrite this would be the perfect time to at least make sure nothing in the infrastructure assumes a single account. If that assumption is held from the start then it will be harder to allow multiple accounts later.

element-hq/element-meta#1831

Are you willing to provide a PR?

No

[anoadragon453]

After asking in #matrix-rusk-sdk:matrix.org, @poljar mentioned that one should:tm: only need to create more instances of the Rust SDK with separate store paths in order to support receiving and sending events for multiple accounts at once.

To save battery life: perhaps when switching between accounts on a client that supports push notifications, only the active account will run a /sync loop, whereas the non-active accounts will simply continue to listen for push notifications, but not actively sync. This could allow a mobile client to have potentially hundreds of accounts loaded onto the same client (if one really wanted to).

[anoadragon453]

In fact, GNOME's Fractal matrix client makes use of the Rust SDK and already supports multi-account! https://gitlab.gnome.org/GNOME/fractal/-/tree/main/src/account_switcher

One would need to check whether the appropriate methods are exposed in the Kotlin bindings for the matrix-rust-sdk, but it's only a matter of exposing them if they aren't.

[laszlovl]

Note that support for multiple accounts is by far the most upvoted issue in the history of element-android: https://github.com/vector-im/element-android/issues?q=is%3Aissue+sort%3Areactions-%2B1-desc+ as well as in riot-android: https://github.com/vector-im/riot-android/issues?q=is%3Aissue+sort%3Areactions-%2B1-desc+

[DraconicNEO]

The multiple accounts issue in my opinion is given a lower priority than it otherwise should have. If this were a centralized service like say Discord this wouldn't be much of an issue but because this is a decentralized network where it is likely people will have different accounts on different servers it's much more important for people to be able to access all of their accounts from the same client without using hacked together workarounds. Another thing that makes this all the more important is the Fact that Matrix has end-to-end encryption and that logging out on all instances can break that causing you to lose access to prior message history this makes having proper multi-login support all the more important as you can't just log out to login to your other account without causing issues.

I really hope this gets looked into and maybe moved up in priority since it is a big major limiting factor of Matrix/Element Adoption.

[manuroe]

ElementX will have multi-account support. We can even considered we already started working on it. The code architecture is ready at every level. We have a good visibility on how we want to design the UX. It is really a matter of capacity and priorities. The project is only 3 months old. We cannot have everything available now.

From a user perpective, there are things we want to address before like being able to create rooms, receive notifications, send media, authenticate using OIDC (which will allow to create accounts), show room and member details screens. Then, we should attack it. This is our current plan.
If you follow the TWIM, you know most of those tasks are already in progress. We are parallelising a lot. So, multi-account could happen really soon™️ but we really need the foundation to be solid first.

we already started working on it

Another example of that is notifications we are currently working on. It will be implemented in a way that it will support multi-account from the start. We think we found a technical solution to manage push coming from different accounts. We are allocating time to make experimentations.

[alexdatur]

ElementX will have multi-account support. We can even considered we already started working on it. The code architecture is ready at every level. We have a good visibility on how we want to design the UX. It is really a matter of capacity and priorities. The project is only 3 months old. We cannot have everything available now.

From a user perpective, there are things we want to address before like being able to create rooms, receive notifications, send media, authenticate using OIDC (which will allow to create accounts), show room and member details screens. Then, we should attack it. This is our current plan. If you follow the TWIM, you know most of those tasks are already in progress. We are parallelising a lot. So, multi-account could happen really soon™️ but we really need the foundation to be solid first.

we already started working on it

Another example of that is notifications we are currently working on. It will be implemented in a way that it will support multi-account from the start. We think we found a technical solution to manage push coming from different accounts. We are allocating time to make experimentations.

We are very, very looking forward to using multi-accounting. Thank you for your hard work!

[shadow-identity]

I'm really glad to know that the work is moving in this direction. Thanks for your guys job, it's amazing! Just wondering if there would be ability to hide some accounts from the client's account list.

The use case is that in some countries this is happens that police stops people and asks / force them to unlock the phone and show the list of subscriptions. They are looking mostly for opposition rooms / chats. It may result in 7 years of imprisonment in Belarus just for subscription to an opposition chat or channel, but this is not the only country with this kind of disrespect to privacy and presumption of innocence.

Hiding an account with dangerous content will safe someone's freedom. For example, the biggest opposition channel in Belarus has more than million subscribers, it's more than 10% of population of the country.

Example of similar functionality can be observed in SimpleX chat client. There you need to input your secret password into Searching field, after it the hidden account appears in the list, otherwise there is no traces of having anything hidden.

[anoadragon453]

@shadow-identity That is a very worthwhile feature to consider; for the reasons you described and countless more. Can you put it as a new issue so it can track it separately, mentioning that it depends on element-hq/element-x-ios#190?

Therefore it won't get lost when basic multi-account support is implemented (and this issue in particular will be closed).

[kittykat]

Hi, I'm going to close this issue as it's a duplicate of element-hq/element-meta#1832 - please continue the discussion over there! 👍

[RokeJulianLockhart]

@kittykat, I don't think that that's a good idea. The discussion is useful for disucssing this topic perhaps, but I'm only subscribed to issue closure, specifically so that I'm notified when the issue is implemented. I can't get that feature from a discussion.

[ShadowJonathan]

Why is this feature delegated to a discussion anyways? This is a feature, not a pigeonhole.

[michaelblyons]

Closed the most up-voted issue as a duplicate. 🤦‍♂️

[DraconicNEO]

Closed the most up-voted issue as a duplicate. 🤦‍♂️

Unfortunately shows where their priorities are at. I mean they put multi-count support so far down the road map when it should have been much higher priority, element isn't like other services where you can log out and log back in, if you log out it desyncs your keys and if you're not logged in at least one place you'll lose your e2e message keys.

The issue should be opened so it's obvious when the feature is implemented, then it'll be closed as completed just like @RokeJulianLockhart said.

[kittykat]

Hi folk, this is not a platform specific enhancement request and it doesn't make sense to keep the discussion duplicated in multiple places because everything you're contributing applies equally to both mobile apps. Spreading content over many locations increases the likelihood that your individual input may be missed and not taken into consideration. Keeping the discussion in one place where we track feature requests will ensure that your contribution is considered.

This is also not an actionable issue in its current state so this issue will not be tracked and development will not happen against it.

There is a "Subscribe" button on the right hand side of the discussion where you can subscribe for updates so you are informed when the work starts and finishes:

Please continue the conversation in that discussion topic.