this post was submitted on 27 Jun 2024
93 points (98.9% liked)

Fediverse

28216 readers
463 users here now

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 [email protected]!

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

founded 1 year ago
MODERATORS
 

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 are viewing a single comment's thread
view the rest of the comments
[–] warmaster 2 points 4 months ago* (last edited 4 months ago) (1 children)

Could this work offline as a PWA? By offline I mean not hosted on your server, but locally.

[–] [email protected] 1 points 4 months ago

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.