Spacedrive - Open-Source-basierter plattformübergreifender Datei-Explorer
(github.com/spacedriveapp)- Spacedrive ist eine cross-device data platform, die Dateien über mehrere Geräte und die Cloud hinweg an einem Ort verwaltet, Dateien, E-Mails, Notizen und externe Quellen indexiert und durchsucht sowie per P2P synchronisiert
- Es ersetzt weder Finder noch Explorer, sondern fungiert als übergeordnete Schicht über dem Dateimanager des Betriebssystems, um lokale Datenträger, externe Laufwerke, NAS, Cloud-Speicher und archivierte Datenquellen zu durchsuchen und zu erkunden
- Allen Dateien wird ein BLAKE3-Inhaltshash zugewiesen, sodass dieselbe Datei anhand desselben Hashes identifiziert wird und Duplikatverfolgung sowie Deduplizierung über mehrere Geräte hinweg möglich werden
- Die Synchronisierung zwischen Geräten erfolgt als auf Iroh/QUIC basierende P2P sync mit Direktverbindung, synchronisiert Metadaten ohne Server, Cloud oder Single Point of Failure und belässt die Dateien an ihrem ursprünglichen Speicherort
- S3, Google Drive, Dropbox, OneDrive, Azure und GCS werden zusammen mit lokalem Speicher als cloud volumes indexiert, während Gmail, Apple Notes, Chrome Bookmarks, Slack, GitHub und weitere über skriptbasierte Adapter zu durchsuchbaren Speichern werden
- In Verbindung mit Spacebot wird optional in einem separaten Prozess eine AI-Agent-Runtime ausgeführt, wobei Spacedrive die Daten-, Berechtigungs- und Ausführungsebene übernimmt und Spacebot für die Intelligenz zuständig ist
- Jede Spacebot-Instanz ist mit einem Spacedrive-Knoten gekoppelt; dieser Knoten übernimmt die Agent-Authentifizierung, die Pflege des Device Graph, die Auflösung von Berechtigungen und die Weiterleitung von Aufgaben an Peer-Geräte
- Dateilesen, Shell-Befehle und Aufgaben werden über Spacedrive an das Zielgerät weitergeleitet, während das Berechtigungssystem regelt, auf welche Geräte, Pfade, Aufgaben und Personen zugegriffen werden darf und ob eine Bestätigung durch Personen erforderlich ist
- Nach der Aktivierung durchlaufen zu indexierende Datensätze eine Safety Screening-Pipeline, bevor sie durchsuchbar werden
- Prompt Guard 2 erkennt Prompt-Injection in E-Mails, Nachrichten und Dokumenten mit einem lokalen Klassifikator
- Über Trust-Ebenen, ein Isolationssystem und Content Fencing werden markierte Datensätze aus AI-Agent-Abfragen ausgeschlossen und können in der Desktop-App überprüft werden
- Die Kernarchitektur besteht aus einem Virtual Distributed Filesystem, einem inhaltsbasierten Identifikationssystem, transaktionalen Aktionen und leaderloser Synchronisierung
- Dateien und Ordner werden zu Objekten unabhängig von ihrem physischen Speicherort, und jede Datei besitzt eine
SdPath-Adresse, die über mehrere Geräte hinweg funktioniert - Dateioperationen haben die Form langlebiger Jobs mit Vorschau vor der Ausführung, Genehmigung oder Abbruch und sind robust gegenüber Netzwerkausfällen und Geräte-Neustarts
- Dateien und Ordner werden zu Objekten unabhängig von ihrem physischen Speicherort, und jede Datei besitzt eine
- Die Implementierung basiert auf einem einzelnen Rust-Crate und einer CQRS/DDD-Architektur; zentrale Technologien sind Tokio, SQLite, SeaORM, sqlx, Iroh, BLAKE3, LanceDB, FastEmbed, OpenDAL, Tauri 2, React Native, React 19, Vite, TanStack Query, Tailwind CSS v4 und Specta
- Die Desktop-App unterstützt macOS, Windows und Linux, die Mobile-App iOS und Android; zusätzlich gibt es eine Struktur mit CLI und Daemon, headless server und browser client
- Voraussetzungen für die Ausführung sind Rust 1.81+, Bun 1.3+, just und für Adapter Python 3.9+; als Entwicklungsbefehle werden
just setup,just dev-desktopundjust testverwendet - Das Datenschutz- und Sicherheitsmodell ist local-first; P2P-Datenverkehr ist mit QUIC/TLS verschlüsselt, die Bibliothek kann mit SQLCipher Festplattenverschlüsselung nutzen, und es gibt kein Telemetrie-Tracking oder Analytics
- Die Lizenz ist FSL-1.1-ALv2 Functional Source License und wechselt nach 2 Jahren zu Apache 2.0
1 Kommentare
Meinungen auf Hacker News
Direkt nach der Installation wurden das Anlegen einer Library, das Teilen von Analysedaten und ein Login verlangt, daher waren die Erwartungen andere als bei anderen Datei-Explorern.
Ich bin in ein beliebiges Verzeichnis auf dem Laufwerk gewechselt und habe doppelt geklickt, aber es passierte nichts; auch das Öffnen über das Kontextmenü änderte nichts.
Wie sich herausstellte, wird das Browsen praktisch unmöglich, wenn in einem Verzeichnis 15.000 Dateien liegen.
Total Commander und Windows Explorer haben dieses Problem nicht, daher sollte Spacedrive wohl zuerst die grundlegenden Datei-Explorer-Funktionen weiter verfeinern.
Spacedrive wurde, anders als einige Antworten hier nahelegen, mit Blick auf große Datenmengen entworfen: Locations werden vorab indiziert, ein Cache wird aufgebaut, und alles wird gecacht und virtualisiert.
Im nächsten Update soll der Bug beim Browsen außerhalb von Locations behoben werden, und offenbar probieren viele Nutzer erst das Browsen aus, bevor sie etwas als Location hinzufügen.
Es ist noch Alpha-Software, also hoffentlich wird sie mit der Zeit weiter ausgereift.
Man kann das nicht nur den Entwicklern anlasten; meiner Meinung nach sollte das Framework so etwas standardmäßig unterstützen.
Man sollte nicht erst Virtualized Lists verstehen müssen.
Als ich mit SwiftUI eine TableView gebaut habe, konnte ich Tausende Einträge scrollen, ohne überhaupt zu wissen, wie es intern funktioniert.
Weil es keinen Cache für die Sortierreihenfolge gibt, muss man beim Öffnen in einer anderen Sortierung als alphabetisch mehr als fünf Minuten warten, während sortiert wird.
Als ich es vor ziemlich langer Zeit gesehen habe, gab es noch kein Release-Paket zum Ausprobieren, also wollte ich später wieder nachsehen, wenn es bereit ist; offenbar ist vor einer Stunde eine Alpha-Version erschienen, weshalb es wohl wieder auf HN gelandet ist.
Das Konzept an sich ist willkommen.
Heutzutage verschwimmen die Grenzen zwischen strikt lokalen Dateien und mehreren Cloud-Speichern.
Ich persönlich halte diese Grenze aufrecht und mounte Cloud-Speicher auf dem Mac kaum, aber meine Frau ist Wissenschaftlerin und nutzt Dropbox, iCloud Drive, Google Drive und Microsoft-Speicher.
Der Grund ist, dass ihre Kolleginnen und Kollegen Dateien über die jeweiligen Dienste teilen und beim Review zusammenarbeiten.
Wenn ein solches Tool die Verbindungsprobleme und Eigenheiten der einzelnen Anbieter verbergen und ein transparentes Dateisystem bereitstellen würde, das lokal wirkt, hinter dem aber irgendein Cloud-Speicher hängen kann, wäre das für den Workflow ziemlich hilfreich.
Entscheidend ist die Nutzbarkeit; wenn die Latenz hoch ist und es sich langsamer als Finder anfühlt, sinken die Chancen deutlich.
Hacker News ist wahrscheinlich nicht die optimale Zielgruppe für ein solches Produkt.
Die Leute hier haben mit hoher Wahrscheinlichkeit bereits jeweils optimierte Workflows, ich eingeschlossen.
Dieses Produkt scheint eher zu digitalen Kreativen zu passen, die Windows und Mac nutzen, aber mit dem Terminal nicht vertraut sind.
Also zu Leuten wie Animatoren, Illustratoren, Video-Editoren, 3D-Artists, Musikproduzenten, YouTubern und Streamern.
Allerdings bin ich mir nicht sicher, ob diese zweite Gruppe so etwas wirklich will.
Allein anhand des Marketings verstehe ich nicht genau, was die Software macht, und dieser Gruppe wird es vermutlich genauso gehen.
Ich verstehe, dass man eine „universelle Datei-Erfahrung“ vermitteln will, aber es bleibt unklar, was das konkret bedeutet.
Nutzer sollten die Software nicht installieren müssen, nur um die Funktionen zu verstehen.
Dass sie Open Source ist oder unter Linux läuft, scheint für sie auch nicht besonders wichtig zu sein.
In dieser Phase würde ich das Marketing komplett neu aufsetzen und auf diese zweite Gruppe optimieren.
Es wäre besser, gemeinsam mit PR- oder Marketingfachleuten konkret und effizient zu vermitteln, welchen Wert man schafft.
Außerdem würde ich zur Schonung der Teamressourcen das Source-Repository offline nehmen und auch die Linux-Version einstellen oder sie bis zu echter Nachfrage privat halten.
Viel Glück.
Ich verfolge das Projekt schon ziemlich lange und habe ein paar Punkte als Feedback.
Das Indizieren eines einzelnen lokalen Entwicklungsverzeichnisses hat bisher mehr als 35 Minuten gedauert, und ich glaube nicht, dass ich bis zum Ende warten werde.
Wie andere schon gesagt haben, ist Latenz ein Problem.
Auf einem macOS M1 14-Zoll-Basismodell dauert es selbst nach dem Hinzufügen einer Location manchmal 2 bis 4 Sekunden, bis ein Ordner geöffnet ist und die Dateien sichtbar werden.
Wenn ich nichts übersehen habe, gibt es anscheinend noch keine Tabs.
Dateisortierung und Gruppierung sind extrem dürftig oder praktisch nicht vorhanden, dürften sich aber im Laufe der Entwicklung verbessern.
Um einen vernünftigen Indexierungszustand zu erreichen, scheint der Nutzer einiges tun zu müssen, etwa viele Locations manuell hinzufügen.
Ich verstehe den Local-first-Ansatz, aber die Art von Telemetrie und Login gefällt mir überhaupt nicht.
Insgesamt war ich beim Ausprobieren etwas enttäuscht, weshalb es für mich wahrscheinlich nicht passt; es kann aber durchaus eine Zielgruppe geben, und es liegt noch ein weiter Weg vor dem Projekt.
Optisch sieht es wirklich gut aus.
Ich frage mich, warum das mit React gebaut wurde.
Ich verstehe, dass Rust kein GUI-Framework wie Qt hat, aber ob das deshalb die Antwort ist?
Liegt es daran, dass man nichts Neues lernen wollte?
Man könnte das problemlos als C++-App oder mit Qt bauen, die GUI in QML schreiben und Lua, Python oder JavaScript als Skriptsprache anbinden.
Klar, das ist Arbeit.
Rendering im Browser ist im Grunde eine einfachere Variante davon, eine GUI mit einer GPU-API wie OpenGL zu bauen.
Das Betriebssystem bringt bereits GUI-Werkzeuge mit, also sollte man die nutzen.
Ansonsten sieht es ziemlich ordentlich aus, aber ich meine, dass auch etwas wie pcmanfm das Hinzufügen entfernter Orte unterstützt.
Eine weitere Frage ist, warum Prisma verwendet wird.
Mit Tauri kann man leicht auf Rust heruntergehen, wenn performante Aufgaben oder Betriebssystemintegration nötig sind, und Packaging für die wichtigsten Plattformen ist schon vorhanden.
Mit React kann man ein hervorragendes Ökosystem nutzen, in dem es bereits viele UI-Komponenten gibt.
Das ist anders als bei den meisten nativen Rust-GUI-Frameworks.
Außerdem kann man Frontend-Engineers und ihre Webtechnologien sowie ihre Fähigkeiten zur Zusammenarbeit mit Designern wiederverwenden.
Man kann sagen, dass sie nicht so ausgereift wie Qt sind, aber im Vergleich zu etwas, das im Browser läuft, reichen sie oft aus.
Dass dieses Repository noch in einer frühen Alpha-Phase ist und es viele bekannte Bugs gibt, aber trotzdem so viele GitHub-Stars hat, ist schwer zu glauben.
Außerdem sieht es so aus, als hätte es VC-Finanzierung erhalten, was noch verwirrender ist als bei langchain oder pinecone.
Die sind immerhin AI-basierte Projekte, aber dieses Projekt bewegt sich in einem Bereich, der schon vielfach bearbeitet wurde.
Selbst wenn es für immer kostenlos wäre, glaube ich nicht, dass die Leute es wollen würden; und wenn Werbung, Tracking oder ein Monatsabo dazukommen, erst recht nicht.
Im Grunde gibt es keinen Grund, ihm zu vertrauen, aber viele Gründe, misstrauisch zu sein.
Das ist kein persönlicher Angriff, aber wenn ihr diese Perspektive noch nicht bedacht habt, solltet ihr das tun.
Der erste Bildschirm nach „welcome“ ist ein Login.
Ich verstehe nicht, warum man sich bei einem Datei-Explorer einloggen muss; diese Zeit ist seltsam.
Der Grund für den Login ist, dass es sich um ein Remote-Dateisystem handelt.
Man sollte dabei eher an Dropbox denken als an einen Datei-Explorer.
Das wird sich im nächsten Update ändern.
Letztlich wird der Login eine Möglichkeit sein, Geräte schnell zu verbinden, ähnlich wie bei Tailscale.
Ein durchsuchbarer und explorierbarer Meta-Index für verstreute Cloud- und lokale Speicher sowie für eingehängte und nicht eingehängte Speicher ist definitiv interessant und war eine Zeit lang eine Art heiliger Gral.
Digital Asset Management ist kein neues Konzept, aber es ist derzeit kein Bereich mit besonders vielen Optionen.
Portfolio oder Adobes komplexe Produktsuite bieten viele dieser Funktionen, konzentrieren sich aber stärker auf Workflows und Metadaten als auf Cloud-Speicher.
Heutzutage sollte man sehr vorsichtig sein, wenn man noch einen weiteren cloudabhängigen Dienst einführt.
Angesichts der Sensibilität von „allen Dateien, einschließlich lokaler und Offline-Dateien“ könnte Self-Hosting/On-Premises eine zwingende Anforderung sein.
Wenn ein Konto erforderlich ist, wird man eine Integration in bestehendes Identitätsmanagement über OIDC oder SAML wollen.
Wenn dieses Tool zur zentralen Anlaufstelle für den gesamten Dateibestand wird und man darauf Workflows aufbaut, braucht es auch Kontinuitätsfunktionen, bei denen man sich der Verfügbarkeit sicher sein kann.
Ich hoffe, ihr bleibt dran.
Noch hat das niemand vollständig gelöst.
Das Projekt sieht cool aus, und mir gefällt der Anspruch.
Ein paar Anmerkungen:
Es sollte einen klaren Toggle für jeglichen WAN-Zugriff geben, und separate Toggles für das Senden von Analyse- oder Nutzungsdaten, die standardmäßig deaktiviert sind.
Noch besser wäre es, wenn das auch Compile-Time-Flags wären.
Früher war das neue Terminal Warp sehr attraktiv, aber weil es standardmäßig Daten übers Netzwerk sendete, war es für viele sofort ein Ausschlusskriterium.
Ich hoffe, ihr lasst euch stark von Windirstat und Everything inspirieren, und nehmt euch insbesondere die Suchleistung von Everything zum Ziel.
Ich habe gesehen, dass es auf der Roadmap steht, aber um es noch einmal zu sagen: Tabs werden gebraucht.
Überlegt auch, von Prisma wegzugehen.
Es kapselt die Datenbank zu stark und bringt zu viel Magie mit.
Die Begründung mag schwach sein, aber ich mache mir ein wenig Sorgen, dass irgendwann die Lizenz geändert wird.
Ich wünschte, man würde endlich aufhören, written in Rust am Anfang der README wie ein Feature zu behandeln.
Jedes Mal, wenn ich so eine Formulierung sehe, denke ich nicht „das wird stabiler sein“, sondern „das ist wohl jemandes Hobbyprojekt“.
In einer README scheint es bei einem Open-Source-Projekt als relevantes Detail durchaus passend zu sein.