1c7855ded6
* Initial Windows ffmpeg + libheif custom build * Add build steps for most of ffmpeg deps * FFmpeg deps and libheif * Fix libheif build * Fix libvpx and dlfcn + attempt to fix rav1e * Rework the whole ffmpeg-windows build system - New system based on https://github.com/BtbN/FFmpeg-Builds - Add new ffmpeg-windows workflow - Rename macos ffmpeg workflow - Adapt macos setupt script due to above name change * Forgot to update update the workflow name * Strip all libs from debug symbols * Add docs * Add libde265 deps, required by libheif - Make x265, svtav1 and dav1d as shared deps (used by both ffmpeg and libheif) * Add missing libheif to Linux setup script * Fix libx265 build script * Forgot to point x265 ninja install to the correct directory * Remove libaom and libsvt-av1 - dav1d and rav1d are our default AV1 decoders/encoders - Quote subshell executions - Make libweb shared * Forgot to remove libaom and libsvt-av1 build steps * Fix typo * Try force webp to link against static libs * Revert libwebp to a static build * Dumb typo * Modify windows script to download our ffmpeg build (WIP) * Fix dlls output folder structure * Fix dumb mistake * Remove unused ffbuild_enabled * Enable core's heif feature on Windows - Fix windows ffmpeg build not including the headers - Fix windows setupt script incorrect download loagic - Implement build_arg to pass which repo ref to use when cloning * Fix windows setup script * Fix workflow artifact path - Make ffmpeg-windows dockerfile respect the FFMPEG_VERSION env * Fix Windows setup script incorrect logic for downloading ffmpeg builds * Error out when workflow_runs is empty * Fix dumb mistake * Manually define ffmpeg version for windows script * Fix ffmpeg windows build extract logic * Fix prop access in windows setup script * Revert back to a web request because nightly.link does a redirect before serving the artifact content * Fix windows setup script * Do not use nightly.link in Github CI * Fix windows setup script * Should finally fix window setup script - Update ffmpeg-windows deps - Should fix ffmpeg-windows failing to build due to mingw changes in new base image * Fix libxz failing to build due to doxygen * Fix windows setup-script not executing till the end * Fix LASTEXITCODE not defined * Remove libjxl, deps are not being compiled * Fix dll and lib copy logic * Move final copy dll logic to external script * Use main for libjxl * Change brotli from stable to main - Attempt to fix libjxl * Attempt fix lib copy again * Split copy_dll logic to avoid cache burst in docker * Missing file * Change how to export build files from shared deps * Replace rsync with cp * Fix copy * Fix dir not existing * Fix pkgconfig * Remove superflous files from exported ffmpeg for windows - Adjust dav1d to not build tools and examples - Adjust windows setup-script to point linker to the libs directory * Fix dav1d meson config args * Fix dumb mistake * WORK PLZ * Fix .lib file location - Strip all dlls * Formatter |
||
|---|---|---|
| .cargo | ||
| .cspell | ||
| .github | ||
| .vscode | ||
| apps | ||
| core | ||
| crates | ||
| docs | ||
| extensions | ||
| interface | ||
| packages | ||
| .editorconfig | ||
| .eslintignore | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .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 | ||
| 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. ~
NOTE: Spacedrive is under active development, most of the listed features are still experimental and subject to change.
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.
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,webandlanding)config:eslintconfigurations (includeseslint-config-next,eslint-config-prettierand alltsconfig.jsonconfigs 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).