casync VS spacedrive

For arbitrary state changes however, it's better to use something like casync. Note that there are a lot of tunables, implicit and explicit; for package indexing I would particularly think about "how is the index sorted" and "what is the desired chunk size".

If you just want something practical to play with, see casync. Even if it doesn't fit your workflow, or if you think you can do better, chances are you're best off building on top of it or adding patches to it, not starting from scratch.

You probably want casync.

Obligatory link to casync, which implements this better than most alternatives.

(personally, I think more people need to be aware of casync for the update storage/distribution problem. It isn't perfect for every use case, but it's good enough that you're probably better off wrapping/forking it rather than reimplementing it badly from scratch)

Does something like casync (https://github.com/systemd/casync or https://github.com/folbricht/desync) serve any purpose or provide any advantage to propagating rpm changes over rsync?

Software that comes to mind for syncing lots of small files: git (and other source versioning tools), casync (https://github.com/systemd/casync) and a go implementation (https://github.com/folbricht/desync). Not really an answer and I can't think of a way to shoehorn that into your workflow, but maybe it leads you down a useful road.

Casync – A Content-Addressable Data Synchronization Tool\ (15 comments)

In the video, Mo talked about a few packages like Cidre and StrOm, and we referred to SpaceDrive.

AGPLv3 (switched in 2022 https://github.com/spacedriveapp/spacedrive/commit/8e5c71dea... ) and FWIW I don't see any mention of CLA or other license assignment, so I don't believe they can currently rug pull containing contributed changes since they don't own the license for them: https://github.com/spacedriveapp/spacedrive/blob/main/CONTRI...

Already opened a bug report for that: https://github.com/spacedriveapp/spacedrive/issues/1481

While Electron wouldn't be on top of my wishlist, if it looked nice and was functional I wouldn't mind at all. I found this project https://github.com/spacedriveapp/spacedrive which uses Tauri and seems to be very interesting, but they haven't released yet

In Tauri (or Axum) the app compiles to a single binary. rspc is the key to this because it allows for multiple transports with the frontend. It supports both Tauri IPC, HTTP or websockets. Our core crate (at ./core) exports an rspc router that is transport agnostic then within the apps (at ./apps/desktop or ./app/server) we expose it with a transport. We use Tauri IPC for desktop and websockets for Axum because we use subscriptions. Then in the wrapper React project (at ./apps/desktop/src/App.tsx) we create the rspc client with the Tauri link, mount its React context and then mount the app package (). You can give the codebase a look if you want cause it’s all open source https://github.com/spacedriveapp/spacedrive

Taking a departure from REST and GraphQL, I'd suggest checking out rspc instead of GraphQL and Prisma Client Rust as your ORM. Both have been developed by a coworker and I for Spacedrive, the company we work for, and have provided what we believe is the best Rust + TypeScript stack that doesn't use GraphQL (new GrpahQL server incoming one day tho).

This might help https://github.com/spacedriveapp/spacedrive