- cross-posted to:
- lemmy_support@lemmy.ml
- cross-posted to:
- lemmy_support@lemmy.ml
cross-posted from: https://slrpnk.net/post/10823519
So I wrote a little web app that allows a user to move their user data, like settings and subscribed/banned communities, from one account/instance to another.
It runs completely client-side, but is hosted on GitHub for the moment. Maybe it’ll be of some use!
Features:
- Don’t trust me or GitHub? Clone the project and host it yourself or run it locally (Example in Wiki)
- Export user data from any Lemmy instance (>=v0.19)
- Download user data as a text file
- Modify user data, e.g. to add or remove followed users/communites (Example in Wiki)
- “display_name”
- “bio”
- “avatar”
- “banner”
- “matrix_id”
- “bot_account”
- “settings”
- “followed_communities”
- “saved_posts”
- “saved_comments”
- “blocked_communities”
- “blocked_users”
- “blocked_instances”
- Transfer user data to the target account on the target instance
You must log in or # to comment.
Isn’t this functionality already built into the default web UI?
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”
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_usersentries 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.
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 anullorfile://Origin which can’t be authorized via the second option, therefore the need to sometimes host the application via (local) webserver.
