• 1 Post
  • 508 Comments
Joined 2 years ago
cake
Cake day: July 14th, 2023

help-circle

  • I think the best way to handle this would be to just encode everything and upload all files. If I wanted some amount of history, I’d use some file system with automatic snapshots, like ZFS.

    If I wanted to do what you’ve outlined, I would probably use rclone with filtering for the extension types or something along those lines.

    If I wanted to do this with Git specifically, though, this is what I would try first:

    First, add lossless extensions (*.flac, *.wav) to my repo’s .gitignore

    Second, schedule a job on my local machine that:

    1. Watches for changes to the local file system (e.g., with inotifywait or fswatch)
    2. For any new lossless files, if there isn’t already an accompanying lossy files (i.e., identified by being collocated, having the exact same filename, sans extension, with an accepted extension, e.g., .mp3, .ogg - possibly also with a confirmation that the codec is up to my standards with a call to ffprobe, avprobe, mediainfo, exiftool, or something similar), it encodes the file to your preferred lossy format.
    3. Use git status --porcelain to if there have been any changes.
    4. If so, run git add --all && git commit --message "Automatic commit" && git push
    5. Optionally, automatically craft a better commit message by checking which files have been changed, generating text like Added album: "Satin Panthers - EP" by Hudson Mohawke or Removed album: "Brat" by Charli XCX; Added album "Brat and it's the same but there's three more songs so it's not" by Charli XCX

    Third, schedule a job on my remote machine server that runs git pull at regular intervals.

    One issue with this approach is that if you delete a file (as opposed to moving it), the space is not recovered on your local or your server. If space on your server is a concern, you could work around that by running something like the answer here (adjusting the depth to an appropriate amount for your use case):

    git fetch --depth=1
    git reflog expire --expire-unreachable=now --all
    git gc --aggressive --prune=all
    

    Another potential issue is that what I described above involves having an intermediary git to push to and pull from, e.g., running on a hosted Git forge, like GitHub, Codeberg, etc… This could result in getting copyright complaints or something along those lines, though.

    Alternatively, you could use your server as the git server (or check out forgejo if you want a Git forge as well), but then you can’t use the above trick to prune file history and save space from deleted files (on the server, at least - you could on your local, I think). If you then check out your working copy in a way such that Git can use hard links, you should at least be able to avoid needing to store two copies on your server.

    The other thing to check out, if you take this approach, is git lfs. EDIT: Actually, I take that back - you probably don’t want to use Git LFS.









  • If they do the form correctly, then it’s just an extra step for you to confirm. One flow I’ve seen that would accomplish this is:

    1. You enter your address into a form that can be auto-filled
    2. You submit the address
    3. If the address validates, the site saves the form and shows you the address in a more readable format. You can click Edit to make changes.
    4. If the address doesn’t validate, the site displays a modal asking you to confirm the address. If another address they were able to look up looks similar, it suggests you use that instead. It’s one click to continue editing, to use the suggested address, or to use what you originally entered.

    That said, if you’re regularly seeing the wrong address pop up it may be worth submitting a request to get your address added to the database they use. That process will differ depending on your location and the address verification service(s) used by the sites that are causing issues. If you’re in the US, a first step is to confirm that the USPS database has your address listed correctly, as their database is used by some downstream address verification services like “Melissa.” I believe that requires a visit to your local post office, but you may be able to fix it by calling your region’s USPS Address Management System office.








  • It’s okay, the author of the article didn’t actually read (or understand) the Copyright Office’s recommendations. They are:

    Based on an analysis of copyright law and policy, informed by the many thoughtful comments in response to our NOI, the Office makes the following conclusions and recommendations:

    • Questions of copyrightability and AI can be resolved pursuant to existing law, without the need for legislative change.
    • The use of AI tools to assist rather than stand in for human creativity does not affect the availability of copyright protection for the output.
    • Copyright protects the original expression in a work created by a human author, even if the work also includes AI-generated material.
    • Copyright does not extend to purely AI-generated material, or material where there is insufficient human control over the expressive elements.
    • Whether human contributions to AI-generated outputs are sufficient to constitute authorship must be analyzed on a case-by-case basis.
    • Based on the functioning of current generally available technology, prompts do not alone provide sufficient control.
    • Human authors are entitled to copyright in their works of authorship that are perceptible in AI-generated outputs, as well as the creative selection, coordination, or arrangement of material in the outputs, or creative modifications of the outputs.
    • The case has not been made for additional copyright or sui generis protection for AI- generated content.

    Pretty much everything the article’s author stated is contradicted by the above.



  • you’re the only one with your SSL keys. As part of authentication, you are identified. All the information about your device is transmitted. Then you stop identifying yourself in future messages, but your SSL keys tie your messages together. They are discarded once the message is decrypted by the server, so your messages should in theory be anonymised in the case of a leak to a third party. That seems to be what sealed sender is designed for, but it isn’t what I’m concerned about.

    Why do you think that Signal uses SSL client keys or that it transmits unique information about your device? Do you have a source for that or is it just an assumption?