I think UI is the least of their worries. They’ve not even decided what to migrate yet.
It really needs to be everything - posts, comments, subscriptions, upvotes/downvotes, blocks, and mod status. It needs to be such that signing in to your account on the new instance is the same as signing into on the old one. It should be so seamless that you can just switch instances just to try out a new one and switch back again if it isn’t for you.
It won’t be anything even close.
Indexes are unique to each instance. Post ID, Comment ID, Vote ID. There’s no way to correlate this information between two instances other than to do a full text match, post by post, comment by comment, vote by vote, to determine if what is being imported already exists on the new instance or is “new”.
Even if you go that route, then there’s the quandaries that follow… if you import what is effectively a “new” post to your new instance, do the comments (which aren’t yours) come along, or do you simply end up importing your post with no interaction history.
Then there is identity. You most likely have a non-local identity on your new server, as a result of federation, how does the new instance know that you are who you say you are, givimg you ownership of any of that existing content as it binds it to your, now, local identity?
That’s just off the top of my head.
If you’re lucky you’ll get to keep your cake day.
I kinda just want to keep my cake day. I signed up on my first account on my IRL birthday, but then I created my own instance some time later and created an account on that one. I just thought it was fun to have it on my birthday. :(
This is a perfect example of how engineers/developers can fret over all sorts of technical challenges and compromises while completely missing the one thing a user wants most because it’s simple and sentimental and “human” which also turns out to be comparatively trivial to implement.
Indexes are unique to each instance. Post ID, Comment ID, Vote ID. There’s no way to correlate this information between two instances other than to do a full text match, post by post, comment by comment
I hope there will be a solution for this. It’s so unpractical. The only sane way to link to posts on other instances seems to be to cross-post them.
If you just share a link to a specific post or comment … people can see it, but unless they happen to have an account on that instance, they cannot interact with it. To do so, you have to search for it, and the search is not reliable.
Why can’t post or comment IDs be generated hashes, and each instance uses the same algorithm?
Someone else did bring up the point that the canonical URL is stored, so that does make correlation a bit easier.
Doesn’t solve the concerns you’ve brought forth. For example, the “I don’t have an account here”. A local instance can correlate a local post to a remote post, being able to provide a “open on original instance” link but it can’t be done the opposite direction, which would relieve this problem.
As for hashing, it too certain what that would gain but at some point there was obviously a decision not to correlate by the message UUID (which would accomplish the same thing). Since I wasn’t in the room can’t say why.
Posts and comments have a canonical URL (i.e. the original submission’s URL that’s linked to via the Fediverse pentagram), so that can be used as a foreign key when comparing.
I think identify claiming would need to have been designed into the original spec with something like a public/private key for account ownership to allow moving of related data in a safe way, or e.g. editing a post from a different instance than originally posted it.
Like I said, I was just running of the top of my head.
While it’s true they have canonical URLs, there still remains that there’s no apparent method for integrity checks. No way to validate a correlation between the “new user” and the post or comment that can prevent abuse.
Yeah, I wasn’t arguing, just thinking out loud too. I think the whole decentralised aspect of the fediverse means that ownership has to have a cryptographic answer because there’s no central source of truth that everyone can agree on.
I think moving accounts is a little easier than you think, apart from who gets to say that something should move. It’d be better to have a “pull” than something like the “push” solution that currently exists on Mastodon - there you can forward an account to a new place, as long as the old instance exists and cooperates (big ifs).
I’m mostly thinking about moving accounts (+ communities) in the case of when an instance suddenly vanishes.
Agreed. It really comes down to what is enough to satisfy most people. Exporting subscriptions is an easy implementation. Saved/favorited posts, slightly less easy but very achievable. Each of these could be safely done as a user initiated export/import.
Once you start getting into any type of ownership type work, votes, comments, etc. then it’s starts getting hairy due to integrity concerns. How do we trust that this activity actually belongs to the person claiming it.
As long as they’re using UUIDs where they should be the possibility of a collision is literally so low as to be impossible, but that relies on all the pieces of software using good principles.
Message activity contains a UUID but the activity table is considered disposable and is purged regularly. Once the message is broken down into its parts and stored the universal identifier is lost. All correlation is local.
Sounds like using GUID instead of id’s would help, but that is not something you just switch, and there’s probably a bit more glue needed for it to be feasible.
It’s not that on mastodon and it shouldn’t be that here either. There needs to be some consequence to switching instance.
No there shouldn’t be a consequence. However, most of this is related to server-load.
no offense
Backend dev vs. frontend dev
A UI designer’s dream is a backend engineer’s nightmare
Mastodon has account migration, though it’s not exactly great. Your old toots refer to your new account but if your old server goes down or deletes your old account, the old content disappears. Followers/subscriptions/lists can be migrated, though.
In theory this can work fine with ActivityPub. What you’d need to do for a migration is to notify every server that has received any of your notes/comments/upvotes of your account’s new location. This can he done by the Move activity, moving your posts to another ActivityPub collection, possibly in conjunction with an Update activity.
You’ll also need to implement some method for every reaction to your post to be associated with the new post, but I think that should work out of the box if you keep your IDs straight.
An account moving between servers in a network of 100 servers, with 400 comments and 2000 upvotes/downvotes, should generate about 240000 requests, 480000 if you require an update to synchronize the new post location (it depends on the ActivityPub implementation I think). At about 1KB of JSON per request, that’s 480 megabytes of network traffic (or 3840 megabits of traffic, or about $0.36 in traffic costs at Amazon’s rates).
I think a straight up account migration may be too much for most Lemmy servers to handle. You’ll probably get rate limited in the process, and the migration will take days or weeks. That means the process needs to be non-standard, probably Lemmy specific, with a Mastodon style redirect fix as a fallback. That would break editing old posts or retracting old votes, though.
Without knowing much about Lemmy I would guess that a bit more info is needed, along with some human interaction on both servers to validate the move.
When I signed up i wrote a bit about why I chose that server, I think that as a minimum would also be required.
Edit: I would also only allow moving between servers at the 1st of each month, just to cut down on work for the admins.
There’s three big problems with this.
A. You’re now allowing people to hop, and even name change. Let’s say they’ll allow that. But I think both of those are things that will have to be agreed upon if it’s done at all.
B. You’re missing the password. Every instance should have a unique salt, passwords should NEVER be reversible, and never be stored insecurely (AKA before salting the hash for instance). I use a different password for every site, but I’ve had sites tell me “Your password is X” … holy shit that’s a HUGE security flaw for multiple reasons.
So if I’m migrating and don’t need to set a new password, that’d be questionable.
C. This can be done unscrupulously. If I get control of someone’s account, I can migrate it and essentially steal all their accounts and posts. For 99 percent of us who cares, but let’s say there’s a post from “Justin Bieber” and I get his account, migrate it, use a new password, and now make his posts say “I don’t suck cocks”…
It’s probably more important when it’s a big game studio who posts update and such to Lemmy somewhere but the point is accounts will have a huge value eventually, letting you migrate it with a click might be dangerous.
A. If you want to hop you can already just create a new account. What’s the issue with taking ownership of your posts with you?
B. Just migrate the salt, too. A server can have per-user salts, which may be migrated together with the hash.
C. If you already have control over someone else’s account, what additional benefit does migrating serve?
A server can have per-user salts, which may be migrated together with the hash.
They better have per-user salt. Otherwise that would defeat the entire purpose of salt, which is to make sure that it isn’t obvious if two users have the same password.
What’s the issue with taking ownership of your posts with you?
I think the question is will they allow it. Though I’m sure there’s weird edge cases. I’m not an expert on the Ferdiverse, but let’s say you hope from Lemmy.world to Threads or something like that. But Lemmy.ca banned threads, now your posts have moved. It kind of creates a weird migration.
Though the counter argument also exists “Why do you need to take ownership of posts?” I don’t know if that’s as valuable to go through the hassle. If anything moderator positions is what would matter more and can be done through a process rather than migration. (promote B, remove A)
But like I said, I’m not an expert so I’m still learning.
B. Just migrate the salt, too. A server can have per-user salts, which may be migrated together with the hash.
If ever server has per-user salts, great. But that’s again a question for implementation. You’re making a huge assumption that’s how it works, and there’s no server dependent values. I mean even the hashing algorithm should be able to be proprietary be different between servers (At least that’s how I’d do it).
C. If you already have control over someone else’s account, what additional benefit does migrating serve?
Because control can be reverted, or limited. I mean if I can step to Bieber’s laptop when he’s in the bathroom, that’s not the same as having his login in and password… If lemmy.world sees someone has broken in and locks the account, or Bieber changes his password, your access is lost, where as if you migrate it, can lemmy.world revoke the migration? And if that’s the case, doesn’t that create some strange problems?
I’m not saying this is a bad idea, but I think you have to think more about the edge cases. Though this does have me now thinking about what’s the value of this migration?
They might just go Masto-style migration and just but a banner on your profile linking to your new account, and give you a list of communities to import.
@cheerjoy I think in the long-run of the Fediverse it would be better if we can fully export all of our data to a new instance sure maybe still have a redirect account on the original instance you where using but it would be good for not only people that want to move instance to another popular instance but also if someone creates there own allowing you to try out the Fediverse before spending the time running your own instance as apart of it.
I discovered this a couple of days ago: https://github.com/CMahaff/lasim. It just transfers your subscriptions to your new account in another instance. I don’t really mind not being able to transfer comments for now, but this has been very very helpful when I moved my subscriptions from one of my lemmy.world accounts to another instance because of the recent downtimes.
Yea this is what should be aimed for in the middle term. Anything bigger involves a number of technical chalenges.
But being able to migrate your “setup” to another instance is the middle ground that will actually doable in the short term and a rather significant improvement in the user experience.
“Setup” would include subscriptions, and any further details about subscriptions that may come along like user defined multi-subscriptions etc, settings, cakeday (suggested elsewhere in the comments and a wonderfully human suggestion), blocks etc.
I think migration should just do all of the non-public stuff, like subscribed+blocked communities and saved posts
An alternative idea to allow a user to be apart of multiple instances simultaneously: https://github.com/LemmyNet/lemmy/issues/3416
This needs more work. Specifically, it needs a CAPTCHA on the server on the other end, and it needs to deal with cases where signups need to be approved manually.
What would perhaps work for that use case is to require you to sign up on the other server, generate a special token, and then use that in the migration screen.
I don’t think Lemmy migrations work, though. The Fediverse is not set up for full account migrations with data portability and locking users out of editing capabilities for their old posts (as well as having their old name plastered around everywhere) would lead to confusion. This needs a warning detailing what users can and cannot expect from account portability, and to write that you’ll need to work out the backend mechanism first.
This is how the transphobic people get into Beehaw.
please do it
So would it delete the original account or copy ? I think this could be done with a client app
I’m not convinced that this is a problem that needs to be solved. The value of the federation is that your data is fleeting and not guaranteed. I’m not sure why anyone in the federation needs to guarantee the existence of your data long term.
Because people form attachments to their accounts, and allowing them to keep their info can promote federation (encourage people to use other instances, especially since most people start off on one of the big instances).
I get what you’re saying, but I think there is a practical purpose for allowing migration. That being said, I think working on the UI before thinking about how migration would work in practice might be putting the cart before the horse
Oh idk, maybe people actually like to use online services without interruptions? I’ve already had to recreate my lemmy account twice! (vlemmy.net and lemmy.fmhy.ml both went down)
