“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.

Instructions and tool available here

Code runs locally in your browser only.

You are viewing a single thread.
View all comments View context
1 point

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?

permalink
report
parent
reply
1 point

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”.

permalink
report
parent
reply
1 point

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.

permalink
report
parent
reply
1 point

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.

permalink
report
parent
reply

/kbin meta

!kbinMeta@kbin.social

Create post

Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign

Community stats

  • 1

    Monthly active users

  • 1.3K

    Posts

  • 13K

    Comments

Community moderators