Isn't this functionality already built into the default web UI?
Fediverse
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
The export/import functionality is, yes. This implementation uses the same API endpoints, but the main reason for this existing:
An instance I was on slowly died, starting with the frontend (default web UI). At least at the time, no client implemented the export/import functionality, so I wrote a simple script in Bash to download the user data, if the backend still works. Running a script can still be a challenge to some users, so I wrote a web application with the same functionality. It's a bit redundant if we're talking about regularly working instances, but can be of use if the frontend isn't available for some reason.
Interesting. I guess it can be useful for feddit.de (now feddit.org) users
what kind of data does it export? post, comments, upvotes, downvotes, subscribed communities?
- "display_name"
- "bio"
- "avatar"
- "banner"
- "matrix_id"
- "bot_account"
- "settings"
- "followed_communities"
- "saved_posts"
- "saved_comments"
- "blocked_communities"
- "blocked_users"
- "blocked_instances"
Could this work offline as a PWA? By offline I mean not hosted on your server, but locally.
Sure, the code is completely client-side, simply clone it. If you're running into CORS problems due to the file:// scheme Origin of opening a local file, simply host it as a local temporary server with something like python -m http.server
.
This is due to the two ways most instances validate Cross-Origin requests:
- Sending Access-Control-Allow-Origin: * (allow all hosts)
- Dynamically putting your Origin into the Origin header of the response to your requests by the backend
file://
URLs will result in a null
or file://
Origin which can't be authorized via the second option, therefore the need to sometimes host the application via (local) webserver.
What about forking lasim, which is now inactive? https://github.com/CMahaff/lasim
It's better than the built-in option because it gives you more options. For example, if I only want to add blocks from one account to another without overwriting any other settings. I don't see that your tool allows for that.
The whole point of this being a web app is to make it as easy as possible for the user to download/modify/transfer their user data. LASIM is a traditional app the user has to download and install, similar to a script this web app was developed to replace due to being too difficult to use for some users.
The import functionality targeted by this API is additive and my app features a built-in editor to add, modify or remove information as the user sees fit. To achieve your stated goal, you'd have to remove anything except the blocked_users
entries before importing, which my app supports, I added a wiki entry explaining the workflow in more Detail.
I may add options to modify the exported data in some ways via a simple checkbox in the future, but I wouldn't count on it. I'm always open for pull requests!
Thanks for the info!
I may add options to modify the exported data in some ways via a simple checkbox in the future, but I wouldn’t count on it.
The 2nd screenshot https://github.com/StableNarwhal/Lemmy-Userdata-Migration/wiki/How-to-only-export-or-transfer-a-part-of-my-user-data,-e.g.-blocked-instances%3F shows that feature already exists?
Indeed it does, I was talking about adding a checkbox tagged "Only transfer blocked users" instead of having to click through some menus.