To the best of my knowledge they have always taken account migration seriously. But it's a hard problem, and there are many, many issues to be sorted. As a result it has been and is being discussed in detail in the background while other features have been implemented and rolled out.
Some of those other issues were contentious exactly because there was insufficient prior discussion, so the question of account migration is taking its time. As I say, it's hard, so it won't be happening in the immediate future.
Account migration still depends on the server you are moving from being online and not blocking the migration. It is only a partial solution to the problems that people look to identity migration to solve.
There is currently limited support for account migration in Mastodon, and ongoing discussions about how to improve it. It's not at the level that it's at in Hubzilla, but it's not a lost cause, either.
I interpreted some comments on that ticket as dismissing account migration as almost frivolous. But maybe that's because it's an old and difficult challenge, and I didn't have the context to understand the comments.
We have done a couple of cross-region and cross-account migrations in recent months. It's the same technology but with a different business model. Happy to chat with you about it if you're curious.
Surely there must be a way to automatically migrate users upon login, but that still doesn't help the people who don't sign in - 2 weeks is not much time
> I wish the author had expanded on migration from one instance to another and what it entails (similar to the questions and responses here).
Account migration is not a thing yet, and conceptually requires a new namespace for referencing accounts (such as public keys). There is a multi-year-long actively-discussed open issue thread about this problem.
It's pretty easy to migrate your account from one instance to another. So if you don't like the policies of your current instance, there isn't anything keeping you there.
1. have a naive implementation where users can configure their accounts to replicate between sets of servers, and clients have primary and fallback servers they can talk to if the primary isn't available.
2. switch to a p2p model where each device has its own server, and so account data is automatically replicated across multiple devices. This has a host of other advantages too (e.g. you can own your data without running your own server; you can adopt metadata-protecting federation transports; you can still use all the existing apps today as the client-server API remains the same; you can still bridge with the Matrix network of today).
#2 is obviously way more work, and is effectively rewriting the federation side of Matrix. However, Matrix is designed to evolve and we're not ruling this out from happening at some point. Meanwhile #1 is more likely to land in the nearer future. We haven't got it scheduled in yet, but it's very much on our minds!
reply