OC EXIT 0.1.0: Export subscriptions across kbin/mbin instances
"EXIT" -- Export Across Instances Tool
This is a simple and self-contained tool that helps automate the process of exporting your magazine subscriptions from one instance to another, provided you have accounts on both.
Could also be used to copy subscriptions from one named account to another named account on the same instance, or to back them up for later.
Will this also migrate my blocked lists (instances, magazines, and users)?
If not, does anyone know of a similar tool that will?
I've been trying out other kbin/mbin instances since the recent issues with kbin.social's lack of federation, hoping to open an alt there for backup, but having to manually recreate my block lists isn't something I'm really wanting to do..
Ok, thanks. And thanks for making the tool in the first place!
I think for me, at least at the moment the frustration with kbin.social is still less than that of having to start over on a new instance, so I'll wait it out for now, and hopefully migration tools will continue evolving so it becomes less and less of a hassle as time goes on (I would gladly contribute if I had any relevant knowhow myself, unfortunately that's not the case).
The export process says it has copied subscriptions to the clipboard, but when I paste I just get the code I had pasted in to the browser console. I'm using Safari on macOS.
It's not a big deal. I don't mind starting from scratch.
I have made some modifications that should prompt you to click a button to copy the contents to the clipboard, rather than doing it automatically. This is done because Safari only permits modifying the clipboard if there was direct user interaction. Can you try again?
I just gave this a try and I think there's a potentially worrisome problem, it silently failed on a lot of community subscriptions. The ones that returned HTTP 500 errors were listed in the "fail" list that the importer script generated, but a whole bunch of others returned 404 errors and weren't listed in either the success or fail lists.
So I advise those running this to pay attention to the error log to avoid losing track of those communities rather than trusting the "fail" list.
I'll try to reproduce this and look into tightening the error handling. A 404 error should imply that the magazine is not available at the remote. Are those magazines available at the target instance? Agree that those should at least be added to the log--perhaps should add a third category for "Unavailable." Remember that it will also navigate you to the magazines list at the end for visual confirmation.
When you said community subscription, were you referring to something in particular, or just using this term generically to refer to magazines?
I haven't tried all of them, but the ones I did check were ones that had not had posts on them at their source instance for quite a while. A few random examples:
I had 43 failures and 111 successes, so visual inspection wouldn't really help. I kept copies of the error log and the script output in a text file to figure it out later.
I assume that this means these communities haven't had activity since fedia.io opened, and so fedia.io doesn't know they exist? I've always wondered how the first person to subscribe to a community on an instance is able to do that.
And yeah, I'm using "community" to refer to "magazine".
Hmm, this is a good finding. Just on a cursory review, I had a look at the magazines list on fedia, and it does list magazines with zero threads, comments, posts, or subscribers on them (on other instances other than kbin.social). So maybe you've discovered a problem with kbin.social's federation? I don't know too much about this issue, so this is just my initial reaction before looking into it further.
Addressing your issue, I have bumped the version number to 0.1.3 and made a change to the async method handling so that instances not available at the remote get added to the fail log correctly.
This doesn't explicitly address the fact that some instances are unfederated, but it will make the log results clean.
As for the federation issue, what I've initially found is that a user on an instance has to visit the remote instance for the home instance to be aware of this remote instance, and a user (could be a different user) has to subscribe to that instance for the posts to start federating. What is unclear is how a user on an instance visits a remote instance from the home instance, as this is implementation-specific and could vary from instanc to instance.
Add comment