@davidmorley are you interested about it?
So, I am now adding the code from Upload migration files from profile settings and start processing by tclaus · Pull Request #8461 · diaspora/diaspora · GitHub to diaspora-fr.org so that users from diasp.org, or others from framasphere or joindiaspora or any other pod who kept their archive, can migrate. I know it’s not fully tested, and I plan to make very clear in the message I will post that I won’t provide any guarantee (if it does not work, or only half, I won’t go one-by-one and debug). I was always reluctant to integrate code in diaspora-fr which is not merged in develop, but diaspora* is disappearing for good now, so it looks like it can’t do more harm than to do nothing.
I informed @davidmorley diaspora-fr - Sign in but he basically answered that it is too late now.
So, would you agree to reshare my message with the diaspora HQ account to hopefully reach more people before April the 1st? Here is what I plan to post:
Hello everyone,
More and more pods are shutting down and even if the code to allow an account to migrate from one pod to another is not officially merged yet (see the merge request), I didn’t want to stay without doing anything. So, I enabled it on my pod, https://diaspora-fr.org, which means that you can now move there, keeping with you your previous messages, photos and contacts.I provide this feature with no guarantee, if your content is not properly migrated or anything else is not working, I won’t fix it. But it seemed to me that because pods are closing, we had nothing to lose anyway.
I also want to say that the import can’t be undone and can’t be retried later in the future. If you want to wait for it to be more tested, export your archive and try it later, not now.
If you want to try this, follow those steps:
- From the settings, export your data and your photos in two backups from your actual pod
- Log in to https://diaspora-fr.org (if you don’t have an account on that pod yet, create a new one)
- From the settings, click on the import button and upload the two archives in the dialog.
- Be patient while the account is being migrated
If your pod is already offline (framasphere, joindiaspora, poddery…) but you downloaded your archives before it switched off, you can skip step 1 and migrate anyway.
I hope this is useful to some people.
Remember, diaspora* is what we are making out of it, it can stay alive if we want to. We just have to get involved.
Thanks.
PS @denschub @supertux88 if you could still have a very quick look to the PR just to see if something alarming is in it that would reassure me 
The migration is not ready for production yet, and for good reasons. I saw the emails for your and Thorstens work (thank you!), but it’s not something that can just be merged and then we can act like the migration it’s done. There are a few very big pieces that just aren’t considered yet.
For example, there absolutely needs to be a pref for podmins to block incoming migrations and to set file upload limits. With the current implementation in the PR, I could easily upload an archive bomb that just imports the same picture 10000 times and bring down most pods. Or, as a spammer, I could use the importer to import thousands of spam-accounts that would be very annoying and time-consuming to deal with. Diaspora is already not-great when it comes to offering podmins the tools to deal with spam, but we don’t have to make this worse.
I’m also not aware off the top of my head if the logic that rewrites photo URLs also dispatches federation updates to all known remotes, because if we didn’t, users on other pods that have diasp.org contacts would just see broken images everywhere. It might be that this works just fine, it might not, but that’s the kind of stuff that makes it impossible for me to just have a “very quick look” at the PR and then call it ready. I can spend some time on a review tonight, but it will not by any means be even close to comprehensive.
However, I understand your motivation here. I’m not totally opposed to you posting something from the diaspora-fr podmin account and then resharing that from the HQ account. What I think, tho, is that it might be more impactful if you reach out to the podmins in question and have them post something for their users, maybe even send them a mass DM or a mass email. This probably has a better reach to the affected users, which is especially important given the tight timeline - and it also causes less.. “public excitement” for the lack of a better term.
Thank you for your prompt answer, and for offering to have a look this evening.
There probably are problems with the migration, and I am for sure not asking this to be delivered to other podmins yet. As I would probably be the only one to enable it, I can definitely revert it if there is abuse like spammers.
Thorsten’s PR is only adding a front-end to it, so if there are issues they can be dealt with in other PRs if we prefer.
@tclaus any chance you can fix rubocop warnings?
Basically what @denschub said: There are still issues which need to be fixed and/or tested before this can be merged and released to the masses. I remember there was an issue with conversations of private messages which are broken after the import (only affects existing conversations, but can still be unexpected), and I don’t know if that’s handled yet. And sadly I’m very busy for the next few weeks, so I can’t do a “quick” review (as a quick review won’t mean anything, the easy stuff is working, the remaining stuff isn’t found by a quick review). Also, the import is a federated action, so it will also trigger stuff on other pods, which I don’t know how well that’s handled yet.
I agree that maybe sending out mails/PMs to the affected users directly might be a better idea. The important part is, that they export their data, even if they don’t want to use the current state of the import, they can always do this later. But it requires people to have at least their private key of the old account (which is included in the archive).
Also, if you want to tell people to use the current state of the import on your pod, I think it’s not enough to just tell them, that you won’t fix anything broken, but to also mention that it can’t be undone and it probably can’t be retried if it partially fails (as it can only be done once). So the result is going to be what it is, it’s a one time action, and they use it at their own risk. And as it’s federated, even if you would want to fix some things, you maybe can’t, as it’s maybe broken on other pods which you can’t control. If they don’t want that risk, they can always import their old data into their new account later, as long as they download the archive now (or at least have an old version of the archive still around somewhere).