* Move postinstall script to a preprep script
- Fix libheif crate failing to build with our libheif
- Rework CI due to postinstall to preprep changes
* Linux heif build script + Update webp
* Fix ctrl+c/ctrl+v bug
* Improve libheif linux script
- Add support for linux aarch64
- Add CI workflow to build libheif for linux
- Some other misc fixes
* Fix libheif CI requires sudo
* Fix wrong path for libheif build.rs override in Windows
* Fix wrong path manipulations in libheif build script
* 🤦
* Use ubuntu-latest in libheif action
- Specify glib version in target triple to support old distros
- Fix libheif artifact publishing
* Fix artifact upload path again
* Add musl support for libheif
- Remove unused files from libheif artifact
- Add setup logic for libheif in postinstall script
* Build libheif for linux as a shared lib
* Fix meson not building the correct arch
- Add logic to get git branch from githubs CI env vars
* libheif finnaly works on linux
- Make spacedrive binary rpath point to where appimage and deb expects our libs to be
- Add some logic to tauri.js to convince tauri to bundle our shared libs
- Work-around appimage bundling step breaking sometimes
- Add logic to handle sigint in tauri.js to ensure we clean up after ourselves
- Rename postinstall.mjs to setup.mjs
- Add logic to setup.mjs to point our dev build to our shared libs in linux
* Fix windows dekstop dev
- Rename setup.mjs to preprep.mjs
* test cache-factory
* Fix preprep script not parsing the cross compilation target triple and always using the host info to download dependencies
- Fix action env vars not being correctly passed
- Remove possibility to pass multiple targests to rust action
* Don't compile mobile crates on desktop targets
* Remove cache-factory pull_request trigger
* remove patched tauri cli
* Use git plumbing command to get remote branch name
- Fallback to reading .git/HEAD if remote name was not retrieved
* fix type
---------
Co-authored-by: Brendan Allan <brendonovich@outlook.com>
|
||
---|---|---|
.cargo | ||
.cspell | ||
.github | ||
.vscode | ||
apps | ||
core | ||
crates | ||
docs | ||
extensions | ||
interface | ||
packages | ||
scripts | ||
.clippy.toml | ||
.editorconfig | ||
.eslintignore | ||
.gitattributes | ||
.gitignore | ||
.npmrc | ||
.nvmrc | ||
.prettierignore | ||
.prettierrc.js | ||
.rustfmt.toml | ||
Cargo.lock | ||
Cargo.toml | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
cspell.config.yaml | ||
LICENSE | ||
package.json | ||
pnpm-lock.yaml | ||
pnpm-workspace.yaml | ||
README.md | ||
SECURITY.md | ||
tsconfig.json | ||
turbo.json |
Spacedrive
A file explorer from the future.
spacedrive.com »
Download for
macOS
·
Windows
·
Linux
·
iOS
·
watchOS
·
Android
~ Links will be added once a release is available. ~
UPDATE: Spacedrive is under active development, we are in the pre-alpha stage, with builds occasionally released via GitHub actions, official alpha coming soon.
Organize files across many devices in one place. From cloud services to offline hard drives, Spacedrive combines the storage capacity and processing power of your devices into one personal distributed cloud, that is both secure and intuitive to use.
For independent creatives, hoarders and those that want to own their digital footprint, Spacedrive provides a free file management experience like no other.
What is a VDFS?
A VDFS (virtual distributed filesystem) is a filesystem designed to work across a variety of storage layers. With a uniform API to manipulate and access content across many devices, VDFS is not restricted to a single machine. It achieves this by maintaining a virtual index of all storage locations, synchronizing the database between clients in realtime. This implementation also uses CAS (Content-addressable storage) to uniquely identify files, while keeping record of logical file paths relative to the storage locations.
The first implementation of a VDFS can be found in this UC Berkeley paper by Haoyuan Li. This paper describes its use for cloud computing, however the underlying concepts can be translated to open consumer software.
Motivation
Many of us have multiple cloud accounts, drives that aren’t backed up and data at risk of loss. We depend on cloud services like Google Photos and iCloud, but are locked in with limited capacity and almost zero interoperability between services and operating systems. Photo albums shouldn’t be stuck in a device ecosystem, or harvested for advertising data. They should be OS agnostic, permanent and personally owned. Data we create is our legacy, that will long outlive us—open source technology is the only way to ensure we retain absolute control over the data that defines our lives, at unlimited scale.
Roadmap
View a list of our planned features here: spacedrive.com/roadmap
Developer Guide
Please refer to the contributing guide for how to install Spacedrive from sources.
Security Policy
Please refer to the security policy for details and information on how to responsibly report a security vulnerability or issue.
Architecture
This project is using what I'm calling the "PRRTT" stack (Prisma, Rust, React, TypeScript, Tauri).
- Prisma on the front-end? 🤯 Made possible thanks to prisma-client-rust, developed by Brendonovich. Gives us access to the powerful migration CLI in development, along with the Prisma syntax for our schema. The application bundles with the Prisma query engine and codegen for a beautiful Rust API. Our lightweight migration runner is custom built for a desktop app context.
- Tauri allows us to create a pure Rust native OS webview, without the overhead of your average Electron app. This brings the bundle size and average memory usage down dramatically. It also contributes to a more native feel, especially on macOS due to Safari's close integration with the OS.
- We also use rspc which allows us to define functions in Rust and call them on the Typescript frontend in a completely typesafe manner, so no unnecessary bugs make it into production!
- The core (
sdcore
) is written in pure Rust.
Monorepo structure:
Apps:
desktop
: A Tauri app.mobile
: A React Native app.web
: A React webapp.landing
: A React app using Vite SSR & Vite pages.
Core:
core
: The Rust core, referred to internally assdcore
. Contains filesystem, database and networking logic. Can be deployed in a variety of host applications.
Packages:
client
: A TypeScript client library to handle dataflow via RPC between UI and the Rust core.ui
: A React Shared component library.interface
: The complete user interface in React (used by appsdesktop
,web
andlanding
)config
:eslint
configurations (includeseslint-config-next
,eslint-config-prettier
and alltsconfig.json
configs used throughout the monorepo.macos
: A Swift Native binary for MacOS system extensions.ios
: A Swift Native binary (planned).windows
: A C# Native binary (planned).android
: A Kotlin Native binary (planned).