When we deployed our Matrix instance for GNOME, we were really used to IRC. We did not think through all the ways people would use an account for, and left registrations too open. As a consequence, many people created an account on our instance because they like the GNOME Project, and started using it as a personal account.

Now that we are more experienced with the difference between an organisational account and a personal one, I would like to walk you through the differences between the two, why segregating activities can be useful, and finally how to migrate data from an account to another.

Who Owns Your Matrix Account?

Organisational accounts and personal ones don’t have technical differences. They are the same thing from a technical perspective, except one is offered to you by an organisation for a purpose, and the other is an account you get yourself for your own usage. Let’s see what to expect from both, and how the lines can sometimes be blurry.

The Organisation Owns It

When an organisation, such as the GNOME Foundation, provides you with an account, its name and reputation is bound to the account: whatever you do with this account is done in the name of this organisation.

Of course, the organisation providing the account has a policy, and most probably a code of conduct you must accept before using this account. If you break policy, the organisation can and probably will take the account back and leave you without a chance to retrieve your data. If you leave the organisation, the account can and should probably be taken back from you too. Those accounts can really be compared to work e-mail accounts: you should limit your activities with this account to what you do for the organisation who provides it, and can’t expect to keep it after you leave.

It’s a Personal Account

A personal account is, as incredible as it sounds, an account for your personal usage. You only represent yourself, and to a certain extent your provider. Before being granted access to your personal account you most probably accepted a policy or a code of conduct. Usually those are much looser than the organisations’ ones.

While your provider can take back your account if you really don’t respect its policy, this rarely happens. Providers are incentivised to provide a quality service their customers can rely on (it’s their business!). They only take accounts back as a last resort.

You are way more in control of this account: you can use it for your personal activities which can include your activities for some organisations if they allow it. Here again, it works a bit like e-mail: some organisations will allow you to work with a personal e-mail, others won’t because they want to have more control over it. The same applies to Matrix accounts.

Segregating Activities

One of the strenghts of the Matrix protocol is interoperability. Yet, it can sometimes trick users into thinking they should have a single account for everything. As we saw earlier, just because the protocol allows you to do everything from a single account, it doesnt necessarily mean you should, for the same reasons as we segregate personal and work e-mail.

Segregating accounts makes sense from the organisation perspective because it can be more in control of the conversations happening around its activities, but it also makes a lot of sense as a person to compartmentalise activities.

From an end-user perspective, multi-account has several benefits too. It allows you to:

• Decide to enable/disable notifications only for the account relevant to what you are doing right now, and compartmentalise your brain time to a single activity at once.
• Switch off easily and take real time off! Mental health is important, you really don’t want to burn out.
• Make it more obvious that you are doing some things on behalf of an organisation.

Having multiple accounts does make sense, but the ergonomics of it are still a little wonky, especially on mobile.

The company Element develops the Element clients. While they are among the most advanced clients so far, they do not support multi-account. A popular workaround on desktop is to use Element Web and to open a tab per account.

For native clients on desktop, there’s a bright future ahead: KDE’s Matrix client NeoChat already supports multi-account, GNOME’s Matrix client Fractal has a GSoC intern working on it and Nheko wants to support it eventually.

On the mobile end of things, Element doesn’t support multi-account (but might eventually in a distant future) and Fluffy chat considers it out of scope for their focus. Yet, multi-account clients on mobile are on the critical path to make multi-account convenient and more widely adopted!

Migrating From an Org-Owned to a Personal Account

There are two main strategies when it comes to migrating conversations from an account to another, but those two have the same high-level steps: find a suitable provider, create an account there, and migrate (some) data from one account to another.

Finding a Provider

This is probably the most demanding step of all: finding a place where you can feel at home. The two main questions to consider when looking for a provider are:

• Can they be trusted? Indeed, E2EE helps you to protect privacy, but server administrator privileges can still allow them to do nasty things with your account if they were not trustworthy.
• Are they sustainable? This is difficult to estimate from an external perspective, but some good questions to ask include For how long have they been around?, Are they sustainable financially?, and How many people need to get sick or to quit for the service to stop running?

A popular choice is to get an account on matrix.org. It seems like a no-brainer because it’s free, and it works fairly well. And registrations are open, so after all why not? The Matrix Foundation offers this homeserver to lower the friction of joining the Matrix universe by making it as easy as filling a simple form. But when joining this homeserver you strengthen centralisation around the Matrix Foundation and rely on a non-profit’s resources for your personal activities. Registering an account on matrix.org is a good idea to give it a try, but you probably want to use another provider in the longer run.

Another quite popular alternative is self-hosting. If you are a professional very used to hosting applications and you know exactly what you are doing, it can make sense to self-host an instance for your individual account. It’s fun, and you learn a lot along the way! But in most cases I would not recommend doing it: it’s fairly easy to get something working, but it’s also very easy to neglect it, misconfigure it without realising it, leaving vulnerabilities. Having a secure and properly monitored infrastructure is a very advanced task. It almost always requires several people to be organised together to do it correctly.

If you can afford it, a paid provider is probably the best option in terms of quality of service, security, and sustainability of the ecosystem. The best established options in my personal opinion seem to be Element Home for individual users, and EMS Nickel for individual users who would want their own domain. Zero Carbon Matrix is a nice alternative that has been around for a while now.

An intermediary solution between self-hosting and Matrix as a Service can be to rely on a third-party to handle Matrix as a managed service. This means the infrastructure is yours (you own the server), but the administration of the service itself is performed by a third-party. More information about those on the hosting section of the Matrix Foundation.

Alternatively and as a last resort, you can pick a server from this list of free homeservers, without any guarantee of service.

Once you have picked a provider and created an account, it’s time to get started on the actual migration!

The Firehose Strategy

The firehose strategy is simple: move all the things!! When using this strategy, you use an external tool. You provide it your former account and your new account credentials. Then the tool:

1. Renames your old account with (Old) at the end.
2. Uses your former account to invite your new account in all the rooms where it currently is in.
3. Uses your new account to accept the invites.
4. Grants your new account the same PL as your former account in the room.
5. Does NOT make the history available to your new account.
6. Optionally make your former account leave if you enable the option (which I do not recommend since the history of the room is not necessarily transfered to your new account).

To proceed with the actual migration, you can use Element’s migration tool. A few warnings before you do so:

• You still need to export your E2EE keys from your former account, and import it to your new account, manually. How to do it depends on the client you use.
• You will lose conversation history if you don’t change manually the options of the room.
• Your DM will be turned into regular rooms, and the migration tool won’t automatically make it back to DM.

This strategy has limits: using it does not allow to discriminate what should stay on your former account or not. It migrates everything. Most of the time, some conversations should stay on the organisational account and this tool doesn’t allow such precision.

This tool has its own set of risks (such as losing history) and is better suited for when you want to migrate everything from one provider to another and have a lot to migrate. When moving personal data out of an organisational account, I recommend the surgeon strategy.

The Surgeon Strategy

The surgeon strategy is a much more precise and controlled approach. It consists of handpicking what should be migrated form your organisational account to your personal account.

The process is very similar to the previous one, except you do everything manually. You need to go through each and every room in your former account to run the following from Element:

1. /invite @newaccount:provider.org from your former account, to invite your new account.
2. Accept the invite on your new account.
3. /op @newaccount:provider.org 100 from your former account, and assuming your PL was 100, to grant your new account the same PL as your former one.
4. Change the room settings to share history with every member, so your new account can retrieve history. You can toggle it back later.
5. /part to leave the room with your former account.

The final step is to export your keys from your former account, and import them to your new account or your E2EE history might not be displayed at all, event if it was retrieved from the room.

This method is better suited for when you know what you want to migrate, and when you want to segregate your activities (which you probably should do anyway).

What’s up next

We have seen that multi-accounts are quite needed given how Matrix works today, how to pick a provider, and how to migrate our data. But the future may hold some surprises for us.

There is working going on to extend the Matrix specification to make Portable Identities a thing. Instead of having a Matrix account strictly bound to a homeserver, people would have a “domain-agnostic” account. It would be possible to bind one or several domains to that account.

This may make the need for multi-account less prominent, but it can also come with its own set of problems: how to manage properly permissions of accounts? What if they had been given important privileges on your rooms and you want to take it back? Can privileges in a room be bound to a domain and not to the domain-agnostic account? There are still open points to sort out.