MSC2783: Homeserver Migration Data Format

[ShadowJonathan]

Rendered

Related to matrix-org/matrix-spec-proposals#2760

Signed-off-by: Jonathan de Jong <[email protected]>

[ara4n]

ooh, interesting - thanks for starting this. heads up though that the chances are high that the core team ends up sinking time into decentralised accounts (#915, as unlocked by MSC matrix-org/matrix-spec-proposals#1228), which then solves the migration problem (at least on a per-user basis, but could obviously be automated for a serverwise migration), and which in turn is required for P2P, and also solves server scalability, vhosting, HA and geo-HA requirements...

[ShadowJonathan]

@ara4n, I seriously want to emphasise that i see decentralized user accounts as a non-solution for the problem this MSC is trying to solve; backing up, and easy sysadmin migration, and safekeeping of homeserver state, while also avoiding potential lock-in. This is about lateral movement on a software/admin-level, not lateral movement on a user-level.

This sentiment is outlined in the Values of the foundation, which i plan to adhere to, and so i think its important that this problem is solved before it ever comes up.

I understand the priorities the core team has, but I wanted to repeat my views on matrix-org/matrix-spec#246, as I saw this proposal being dismissed in favour of it, which I dont see as helpful.

(Note: i currently cant participate in #matrix-spec:matrix.org because of https://github.com/matrix-org/synapse/issues/8340, this issue is still a WIP until then, and until i've gotten good feedback)

[ara4n]

Judging by the strength of your reaction I may be missing something :)

In an MSC1228 world: any server which hosts the private part of your user_key can participate in a room on behalf of that user. So if you were a server admin migrating from synapse to dendrite or whatever, you would copy all your user_keys over to the new server, and it would participate in the rooms as that user (and replicate over account_data somehow - probably by representing it as a room). The details are a bit fuzzy given they haven't been fleshed out yet, but it's the same mechanism by which a P2P user would log into two instances as the same user. To complete the migration, the old server would then be turned off. In other words: the migration is simplified to just copying keys, and then Matrix replicates the rest of the data over... via Matrix, obviating the need to specify and maintain a new interchange format in addition to core Matrix itself.

That said, there have been some concerns voiced about giving servers freestyle responsibility for the user_key - in an E2EE-by-default world you could argue the user should look after their user_key themselves and sign which servers are allowed to host their account. If this came to pass, then sysadmins would not be able to force-migrate their users (which would be a pain both for this use case, as well for vhosting & HA purposes), and an interchange format would be more important.

Surely you agree that if we can solve both use cases with one solution, we should do so to avoid the spec getting too sprawling?

[ShadowJonathan]

Judging by the strength of your reaction I may be missing something :)

Sorry for the strong wording, I simply wanted to make something clear up-front

Surely you agree that if we can solve both use cases with one solution, we should do so to avoid the spec getting too sprawling?

I do agree on the spec sprawling if this would be included, but I think this counters some other key problems: domain hot-potato, consistent backup format, atomic and reversible migration

I don't see these problems being solved if 2 servers exchange data via p2p upon the live migration, both servers would need different domains (though if the server part is a pubkey, it's essentially the same problem, because clients or links could be keyed to that server, which doesn't exist then anymore, unless some other spec abstracts away serverparts even more to provide an interface for selection and redirection), and a latent need for a backup format (instead of just backing up application data) still isn't fulfilled. There is also the possibility of "dead links" in the form of room aliases currently not being resolvable because the old server is down, and the new server living on an unknown subdomain.

I'm just saying this to counter some of your arguments, I agree that the spec should be reduced as possible, but I don't think a p2p framework overlaying this will fix most things.

Please correct me if I make assumptions that are just plain wrong, though. I have yet to completely drill down to the core of the p2p ideas presented from matrix.org over the years, so I might be missing a crucial piece that indeed makes this much more possible.

[ara4n]

I think part of the problem here is that we don't have a full proposal for decentralised accounts yet. It is not at all p2p specific though: the intention is to find a solution that lets both server admins and end-users pick a set of servers to host the users' accounts, rather than just being stuck with one server per account. The user's account would then be replicated between the servers via normal Matrix (nothing P2P-specific at all).

Concretely, one strawman approach (which I sketched out a few months ago but haven't put into a proper MSC yet, given MSC1228 is on the critical path first) would be:

• A user's account can exist on any server which has that user's private key
• Each user instance connecting from a different server is modelled as a separate room member
• Room members with the same user_key are merged together in the CS API and shown as a single logical user.
• (This conveniently kills off "device lists" as a concept from the spec, as each device in the room gets its own member)
• Auth rules are extended to ensure that the same user on different servers can see the same events in all places.
• The user's account data is replicated by the users by storing it as room state in a room specific to that user.
• Users auth themselves by cryptographic proof, by proving they own the private half of the key whose private half is in account_data (as SSSS). In other words, we use today's recovery key/passphrase to login rather than having the separate confusing account password.

...at which point I think you have decentralised accounts, without any P2P voodoo beyond switching mxids to be pubkeys (MSC1228), using normal Matrix to replicate the data around. This could be used as equally for migrating between servers on the same domain, as for balancing users within servers on the same domain, as for users migrating between domains, or indeed balancing themselves between domains.

Now, it'd be easy to write this all off as scifi, but we have a really urgent need for it for P2P to work, as well as to support synapse->dendrite migrations etc, where we are not planning to spend any time on speccing interchange formats, but instead charge off and try to get the nirvana of decentralised accounts working.

That said, that's just the current proposed direction for the core team, and very very happy to sanity-check it and consider alternatives :)

[ShadowJonathan]

Looking at that strawman approach, i think i would need to dive a little deeper before i could have an argument on that, and also would need to get some more details, but i see how that could indeed transparently migrate stuff (and effectively make servers temporary valets for users' account authority). I dont want to clutter this MSC with response to that, is there any channel which i can join to follow this development? I have some vague concerns, but i think i need some extra information before i could voice them correctly. (Particularly, administrative complexity, and "what is happening"-obscurity to the user, and how to communicate it simply, effectively, and correctly.)

[ShadowJonathan]

I'm going to try to spend time unlocking this issue, transitioning it from draft status to full status, and then i'll probably see to making PoCs for synapse to reliably (per major version) extract data from the database to the format described here.

[ShadowJonathan]

There are still a few problems with this, and i think i havent yet enumerated everything, but i consider this solid enough for now.

I'll be trying to find time to make a PoC exporter/importer for Synapse 1.29.0 to this format, updating the format with my findings and challenges as i go along.

There are some points left where i'm explicitly asking for feedback with XXX, before to give a comment if you have one.

[ShadowJonathan]

I recognise this is a gargantuan effort, and that some parts of it aren't even clear if they should exist in the spec at all, so for now I'm making this a draft while I work on this independently from the Matrix Spec.

I'll take the ideas in here and put them into a personal repository with which I'll experiment and research further efforts, I'll get a good tested PoC going for some major matrix homeservers, while also thinking about which parts of this should be applicable to the spec, if any at all.

For now, I'll say that I'm suspending this MSC until I've decided what should go into it, thanks for some of the feedback I've gotten that made me realise this, I'll take it into consideration.

Edit: I made a room for this, you can discuss it on #mhmf:matrix.org

[erkinalp]

If this came to pass, then sysadmins would not be able to force-migrate their users

That is a data protection feature, as there is no in-band way of knowing that a server would not change operators during a migration.

[nyabinary]

This still seems extremely useful (and necessary) current day.