Dev and Maintainer of Lemmy Userdata Migration

  • 2 Posts
  • 13 Comments
Joined 2 months ago
cake
Cake day: April 20th, 2024

help-circle

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


  • 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!



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


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






  • An dieser Stelle reposte ich nochmal zwei einfache Wege, um seinen User (Settings und abonnierte/geblockte Communities) von einer Lemmy Instanz auf eine andere umzuziehen, beispielsweise von feddit.de auf feddit.org, von meinem ursprünglichen Post unter feddit.de/c/main ( https://alexandrite.app/feddit.de/post/11325409)


    Weg 1, falls man noch einen Browser mit aktiver Session auf feddit.de hat:

    Lemmy bietet seit Version 0.19 eine Funktion an, um die user data zu ex- und importieren. Das geht normalerweise über einen Button in den Settings des Webinterfaces, das geht aktuell bei feddit.de nicht.

    Aber der zugrundeliegende API-Aufruf funktioniert noch, solange man noch mit einem Browser auf feddit.de eingeloggt ist:

    1. Man gehe auf https://feddit.de/api/v3/user/export_settings und speichert die zurückgegebene Datei als irgendwas.json
    2. Man nehme einen (neuen) Account auf einer stabilen Instanz der Wahl, gehe auf /settings und lade irgendwas.json über den Import-Button hoch.
    3. Voilà, man genieße die neue Instanz.

    Das funktioniert mit jeder Instanz >=0.19, man muss lediglich das “feddit.de” in der URL ersetzen. Und wenn das Webinterface funktioniert, geht das auch über den Export- Button in den Settings.


    Weg 2:

    Für die Leute, die keine offene Browser Session haben, hier ein kleines, aber funktionales Bash Script, welches im Ausführungsverzeichnis eine myFedditUserData.json erstellt, welche bei anderen Instanzen importiert werden kann.

    Anforderungen:

    • Linux/Mac OS X /Windows mit WSL
    • jq installiert (Unter Ubuntu/Debian/Mint z.B. per sudo apt install -y jq

    Anleitung:

    • Folgendes Script unter einem beliebigen Namen mit .sh Endung abspeichern, z.B. getMyFedditUserData.sh
    • Script in beliebigen Textprogramm öffnen, Username/Mail und Passwort ausfüllen (optional Instanz ändern)
    • Terminal im Ordner des Scripts öffnen und chmod +x getMyFedditUserData.sh ausführen (Namen eventuell anpassen)
    • ./getMyFedditUserData.sh im Terminal eingeben
    • Nun liegt im Ordner neben dem Script eine frische myFedditUserData.json

    Anmerkung: Das Script ist recht simpel, es wird ein JWT Bearer Token angefragt und als Header bei dem GET Aufruf von https://feddit.de/api/v3/user/export_settings mitgegeben. Wer kein Linux/Mac OS X zur Verfügung hat, kann den Ablauf mit anderen Mitteln nachstellen.

    Das Script:

    #!/bin/bash
    
    # Basic login script for Lemmy API
    
    # CHANGE THESE VALUES
    my_instance="https://feddit.de"			# e.g. https://feddit.nl
    my_username=""			# e.g. freamon
    my_password=""			# e.g. hunter2
    
    ########################################################
    
    # Lemmy API version
    API="api/v3"
    
    ########################################################
    
    # Turn off history substitution (avoid errors with ! usage)
    set +H
    
    ########################################################
    
    # Login
    login() {
    	end_point="user/login"
    	json_data="{\"username_or_email\":\"$my_username\",\"password\":\"$my_password\"}"
    
    	url="$my_instance/$API/$end_point"
    
    	curl -H "Content-Type: application/json" -d "$json_data" "$url"
    }
    
    # Get userdata as JSON
    getUserData() {
    	end_point="user/export_settings"
    
    	url="$my_instance/$API/$end_point"
    
    	curl -H "Authorization: Bearer ${JWT}" "$url"
    }
    
    JWT=$(login | jq -r '.jwt')
    
    printf 'JWT Token: %s\n' "$JWT"
    
    getUserData | jq > myFedditUserData.json
    

    @elvith@feddit.org hat mein Script auch in PowerShell nachgebaut, welches unter Windows ohne WSL auskommt: https://gist.github.com/elvith-de/89107061661e001df659d7a7d413092b

    # CHANGE THESE VALUES
    $my_instance="https://feddit.de" # e.g. https://feddit.nl
    $target_file = "C:\Temp\export.json"
    
    ########################################################
    #Ask user for username and password
    $credentials = Get-Credential -Message "Logindata for $my_instance" -Title "Login"
    
    $my_username= $credentials.UserName
    $my_password= $credentials.GetNetworkCredential().Password
    
    # Lemmy API version
    $API="api/v3"
    
    # Login
    function Get-AuthToken() {
        $end_point="user/login"
        $json_data= @{
            "username_or_email" = $my_username;
            "password" = $my_password
        } | ConvertTo-Json
    
        $url="$my_instance/$API/$end_point"
    
        (Invoke-RestMethod -Headers @{"Content-Type" = "application/json"} -Body $json_data -Method Post -Uri $url).JWT
    }
    
    # Get userdata as JSON
    function Get-UserData() {
        $end_point="user/export_settings"
    
        $url="$my_instance/$API/$end_point"
    
        Invoke-RestMethod -Headers @{"Authorization"="Bearer $($JWT)"} -Method Get -Uri $url
    }
    
    $JWT= Get-AuthToken
    
    Write-Host "Got JWT Token: $JWT"
    
    Write-Host "Exporting data to $target_file"
    Get-UserData | ConvertTo-Json | Out-File -FilePath $target_file
    

  • Great synopsis!

    The cool thing about GrapheneOS: It provides basically all the comforts and usability as any Android (stock) ROM minus some compatibility issues with a portion of Google Apps and services (Google Pay doesn’t and probably will never work, for example) while providing state-of-the-art security and privacy if you choose to utilize those features. A modern Pixel with up-to-date GrapheneOS, configured the right way, is literally the most secure and private smartphone you can get today.




  • Emotet@slrpnk.nettoLinux@lemmy.mlLix - a new fork of Nix
    link
    fedilink
    arrow-up
    22
    arrow-down
    1
    ·
    2 months ago

    The problem with Nix and its forks, imho, is that it takes a lot of work, patience, time and the willingness to learn yet another complex workflow with all of its shortcomings, bits and quirks to transition from something tried, tested and stable to something very volatile with no guaranteed widespread adoption.

    The whole leadership drama and the resulting forks, which may or may not want to achieve feature parity or spin off into their own thing, certainly doesn’t make the investment seem more attractive, either.

    I, too, like the concept of Nix very, very much. But apart from some experimental VMs, I’m not touching it on anything resembling a production environment until it looks to like it’s here to stay (predictable).