spacedrive VS locenv

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

Here is a PoC made by me: https://github.com/locenv/locenv/tree/main/crates/kami

Or if you prefer to go straight to the code here is the repository :) https://github.com/locenv/locenv

Link to repository: https://github.com/locenv/locenv

It is depend on what you are trying to do. If the plugin don't need a direct access to the OS by themself WebAssembly might be a good choice. Currently I'm working on https://github.com/locenv/locenv but my project required a scripting, not the compiled code; and it also required the plugin to be able to direct access to the OS so I choose Lua as a scripting language and the plugin can be written in any languages that can output a shared library.