Decided to try it out. After the installation, it asks to "create the library", share the analytics and log in - not exactly what I expected compared to other file explorers. Next, I decided to navigate to a random directory on one of my drives. After double clicking, nothing happened. Opening a dir with a context menu action did nothing too. Turns out 15k files in a directory make it effectively non-navigable. Total Commander and Window Explorer have no such issues. Spacedrive still has to iron out the basic file explorer features, it seems.
Hey thanks for trying Spacedrive! The bug you're experiencing is known when browsing before adding a "Location". We index Locations ahead of time to generate a cache that makes browsing super fast, Spacedrive is, contrary to some replies here, designed for big data, we cache and virtualize everything.
Next update we'll fix the bug browsing non-locations, as those who open the app tend to try browsing first, before adding as a location it seems. It's alpha software so I hope you give us time to iron it all out!
There has to be a better strategy than caching and virtualizing to not tip over with large files. Why not just do whatever is your system's equivalent of a SQL LIMIT query? I can't think of a good reason as to why you need to index everything when the view is limited to maybe 100 files tops.
Honestly, you can't call yourself a "file explorer" if you fail the basic task of exploring files without an additional step of "adding a location" (wat?)
Also, judging from the GitHub description, it's not a file explorer. It's a slightly extended Dropbox:
--- start quote ---
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.
We're early alpha, our product is free and open source
At the end of the day, it is an amazing experience simply just to search and organize files from not just devices, but disconnected drives. Search is lightning fast, the UI is clean and you own all the data, given its local first and peer-to-peer.
Hate it if you must, but we're super passionate about it and are ruthlessly working to reach full stability across all platforms.
Firstly, I'm not really an expert on marketing, so take what I say as mere opinion not fact.
I think that you should be pitching it a little differently: many people are confused about what your soundbite is actually saying (I also thought it was a file explorer, like all other file explorers I have even used).
Maybe lean hard into a phrase like "Unified file browser; see all files on all your devices, all at once, all the time".[1]
The other thing I would emphasise is that this isn't syncthing. You don't have to mention syncthing by name, but you could emphasise that "Your files aren't synced between devices, they're visible to all your devices".
Too many people who would otherwise use this would dismiss it with "I'm already using syncthing"! AIUI, you aren't syncing files between devices, only syncing file-listings.[2]
PS. For my own use, unfortunately, I don't need something like this. Sorry.
While it would be a nice to have in theory, it just doesn't solve any pain-points I am currently experiencing.
For example, any important document I need to read on different devices is already either in my email, or on google drive. I view movies on Netflix+AMZ+Disney+, I only ever share photos with others, not with other devices that belong to me. It's rare that I look at a file stored locally on my phone and say "I need to see this on my PC", or vice versa. It just never happens.
[1] That came out sounding super-weird: I did warn you that I wasn't any good at marketing :-)
[2] I expect you provide value on top of that, like transparently copy-n-paste between two different devices, even from a third device.
You are definitely suffering from miscommunication here. Calling it a file explorer is a bit misleading. I think what your project aims to be is really cool and very useful, but a file explorer is a secondary trait to what it actually is.
You know, I had quite a bashful [though in a good spirit] comment on your work before, but, thankfully, HN throttled me.
But thanks to your reply here now I not only can't endorse you, but I have an evidence what you really make some extremely opinionated thing and everybody else is wrong.
I can't wish you luck and I don't see myself as someone who would wait for news for this project.
Why are people pricks like this? Actually building a product and getting early feedback is literally the play book YC live and die by.
Here you are in the church of pg giving shit to people following the scriptures of pg.
Creators - ignore shit like this. Keep iterating. I like your idea, your execution will get better and better. Well done both on releasing stuff and going open source!
The explanations tell's me it's loading and interacting with remote file systems, not hosting them on their own. Which makes it different from dropbox&co., and a file explorer.
It uses Tauri which is the Rust equivalent of Electron.
I'm building an app using it now and it's significantly better than past attempts at browser-based, cross platform app development. It is extremely fast and efficient so apart from UI controls not looking the same it will be on par with a native app.
And one of the big advantages for me is that I get to leverage Rust's excellent low-level capabilities e.g. cross platform SIMD support, io_uring with minimal investment.
> t is extremely fast and efficient so apart from UI controls not looking the same it will be on par with a native app.
It uses system-provided WebView (WebKit on MacOS and Linux, and Edge on Windows) to display the UI shell, so the UI portion will be just as slow as any Electron app.
Sure but most of the issues with Electron apps aren't to do with the web layer.
It's the fact that the app is so slow to launch, consumes ridiculous amount of resources, does not take advantage of the hardware, is unstable etc. And then when you're using the app all of the interactions are slow because NodeJS's concurrency is so poor.
Rust and Tauri fixes all of those. It's not perfect but for a cross-platform app development library I've not seen anything better. Happy to be enlightened with alternatives.
It could target Win32, GTK and Qt all at compile time (even Android and OS X but that never got developed all that far AFAIK), depending what runs on your target platform, while you get common components and RAD at design time. I haven't seen anything like it since and sadly the language and ecosystem are mostly dead, which is a shame, because the idea was brilliant and it actually worked (and is still used in some software, like CudaText and PeaZip I think).
> It's the fact that the app is so slow to launch, consumes ridiculous amount of resources, does not take advantage of the hardware, is unstable etc.
You've just described almost any web-based UI ;)
> And then when you're using the app all of the interactions are slow because NodeJS's concurrency is so poor.
Most of the slow interactions come from the web-based UI. I mean, Slack needs 17% CPU to draw an animated emoji. And it's already running in a hyper optimised Chrome: https://twitter.com/dmitriid/status/1486364312910368769
I tried to build something much simpler than this.
For integration with cloud services you're going to run into OAuth, and guess what, that dance happens in a browser: get access to cloud drive -> get sent to provider login <<web>> page (or authorization page) -> get sent somewhere else.
I mean, you can build it without the browser, but a key and very early step involves a browser, you need it anyway. Might as well ship your own if you can do it.
Seems like a very nice app that works on multiple platforms, and it's even gifted to the community as open source. I don't know where you found the audacity to call something waste of time, but please keep it to yourself.
I presume that by TableView you mean List { } component. Sadly, there is no component for large horizontal lists in SwiftUI and no, ScrollView with LazyHStack is not an answer due to memory issues.
You can use one of the React-Virtualized components without the slightest idea how it works. TableView from SwiftUI is the same thing - a component that implements virtualization on top of the base GUI library for you.
React is not a UI framework, it's a low level reactive library with very limited scope - even the DOM bindings are shipped separately, and it can be used for much more than just GUI, for example VR experiences or cloud infrastructure deployment. Bring your own batteries.
The issue with the “bring your own widgets” approach in my experience is that it’s unusual for third party widget packages to have anywhere near the sort of depth and breadth of capabilities compared to the same widgets that come OOTB with native UI toolkits. This means “shopping” for the widget with the best tradeoffs for one’s particular use case and making up for whatever inadequacies it comes with yourself (or just living with the inadequacies, resulting in a crappier app), which is annoying at best.
It’s so much nicer to just be able to trust that an extensive library of stock widgets will be able to do whatever it is that you need, as tends to be the case with AppKit/UIKit.
When you're building a cross-platform app OSX isn't the weakest link. It's older versions of Windows and Linux.
And UI libraries like Tailwind, Shoelace etc are surprisingly extensive and constantly being improved. And if something isn't to your liking it's often to trivial to change it.
That'd be something provided by the Web platform (through the DOM bindings), not React. React provides a way to work with the DOM elements/native components/etc in a reactive way.
The real problem is that the Web platform doesn't offer a good set of customizable UI elements other than the most barebone basics.
Windows Explorer does struggle with many files in a directory on a HDD. It doesn't cache the sort order, so opening it with anything other than alphabetical order means waiting 5+ minutes for it to sort them.
I remember looking at it a good long time ago. They didn’t have release packages for me to play with so I told myself that I’d check it out later when they are ready. It looks like they released an alpha version an hour ago - hence this is on HN again.
It is a welcome concept. We have blurred the lines between strictly local files and all the cloud storage options these days. I personally maintain those boundaries and almost never mount cloud storage on my Mac, but my wife(as an academic) deals with Dropbox,iCloud drive, Google Drive and whatever Microsoft calls theirs, because the people she works with shares files through them and collaborate with reviews and such. If a solution like this can mask the vendor specific connection hiccups and quirks and provide a transparent file system that appears local but may be backed by $x cloud storage, that would be a nice boost to her workflow.
The key is the usability of such a tool. If the latencies are so high that it feels slower than Finder, then its chances are slim.
Hacker News is not the best crowd for something like this. Everyone here most likely already has their own optimized workflow for something like this, including me.
This is probably best suited for digital creative types who use Windows and Mac and aren't comfortable with the terminal. Animators, illustrators, video editors, 3d artists, music producers, youtubers, streamers, etc.
It's not clear to me that that second group wants something like this. To be fair, from your marketing I have no idea what your software does and I doubt that group would either. I get that you're trying to communicate this is a "universal" file experience but what does that mean in concrete terms? Users shouldn't have to install your software to understand what it does. I also don't see them caring that this is open source or works on Linux.
At this stage I would totally refresh the marketing and optimize it for that second group. Work with a PR person or marketing expert that understands how to concretely and efficiently communicate the value of what you are building to that second group. I would also take down the source repos and discontinue the Linux version (or keep it private for now, until there is demand) to save your team effort at this super early stage.
I've been keeping tabs on this for quite a while. Some feedback:
- Indexing one of my localdev directories has taken a robust 35+ minutes so far, and I will likely not wait until the end of it
- Like others have commented, latency is an issue (macOS M1 14inch base model). I've added a location and even there it sometimes takes 2-4 seconds after opening a folder to see any files
- Am I missing something or are there no tabs yet?
- Extremely lean (too much) in the ways of file sorting and grouping (non-existent), although I wager this will be worked upon during development
- It does feel like I have to do a lot of work to get to sensible indexing (add lots of locations by hand, and so forth)
- I know it's local first, but the way telemetry and login work really does not sit right with me.
Overall I'm almost sure it's not a fit for me, as interacting with it was a bit disappointing, but I can see an audience and there's still ways to go. It looks really good. Best of luck!
Why is this written in React? I understand Rust doesn't have any GUI frameworks (like Qt), but is this the way, then? Is it an adversity to learning something new?
You can reasonably write a C++ app or with Qt and write your GUI stuff in QML, and even plug in Lua, Python, or JavaScript as a scripting language. Yes, thats work.
Using a browser to render is just an easier version of using a GPU API like OpenGL to build your GUI. Your OS comes with gui stuff, use it.
Other than that, cool enough, though something like pcmanfm support adding remote locations as well...?
> I understand Rust doesn't have any GUI frameworks (like Qt), but is this the way, then?
Yes. If you want to build a cross-platform desktop app with Rust, Tauri + React would also be me recommendation right now.
Tauri makes it quite easy to drop down to Rust if you need to (for high-performance operations and everything interfacing with the OS), and it also comes with pre-built packaging for the main different platforms. With React you are able to leverage a great ecosystem that has existing UI components for many things (unlike most native Rust GUI frameworks). It also allows you to reuse you frontend engineers and all their expertise when it comes to web technologies (and working with designers).
True, but it's still less indirection than compiling to web and then embedding a browser, which is how the linked frameworks seem to approach the situation.
It seems unlikely to me that this repository has as many GitHub stars as it does given the early alpha phase and plethora of (known) bugs. Further, you’re seemingly VC funded which is more confusing to me than langchain or pinecone getting funding- and those projects are AI based whereas your project is very well trod territory.
People won’t want this even if it’s free forever. They definitely won’t want it when ads, tracking or a monthly subscription become baked in.
Basically, I have no reason to trust you and lots of reasons to distrust you.
Nothing personal, but if you haven’t considered this perspective you might want to.
> Using a "Virtual Distributed Filesystem" (VDFS), in other words; a decentralized database that emulates a filesystem. It indexes hardware filesystems to create a master database that is synchronized in realtime between your devices running Spacedrive.
> What makes this different to Dropbox or Google Drive?
> It is not a storage provider, Spacedrive is simply a database that exists on top of existing storage layers, from cloud services like Dropbox, Google Drive and iCloud to physical devices and external drives you already own. It doesn't provide you more storage, rather a supercharged view of your existing storage.
So more like Syncthing? Or rather Windows File Sharing/Samba? I don't really get it
That explanations read like it's taking in any kind of file system, local or remote, and combines them into one unified file system. Not really new, but most other file managers focus on the popular storage-services (Dropbox, Google Drive, OneDrive, samba, ftp), and are not open source. If you can easily create plugins for any remote storage, not just the traditional file storages, or even make up your own, then it could become something promising.
it was added last minute without any clear explanation for our users, our fault. i will be changed next update. eventually logging in will be a quick way to connect devices, like Tailscale does
A searchable, browseable meta-index of all my disparate cloud and local, mounted and unmounted file repositories is certainly interesting and has been a bit of a holy grail for some time.
Digital Asset Management is nothing new, but it is not a category currently flush with options. Things like Portfolio and <waves hands> Adobe’s tangle of things offer a lot of this, with less emphasis on cloud repositories and more emphasis on workflow and metadata.
These days I would have to consider yet another cloud-dependent service very carefully. Self-hosted/on-premises could be an absolute requirement, considering the potential sensitivity of “all files, including local and offline.” If accounts are required, I would want integration with existing identity management through OIDC or SAML (which, you know, does what this does but for accounts). I would also be looking at continuity facilities… if I build workflows around this and it becomes an essential single pane of glass over all my files, I’ll want to be confident in its availability.
Keep at it. Nobody has solved all this yet. Good luck!
Project looks amazing! Love the ambition. Have a few notes.
1. Please have one clear toggle for any WAN access. And another one for sending analytics or any sort of usage data be OFF by default. Better yet make them compile time flags too.
There was this new terminal called warp(?) that was so sexy but sent data over the net by default and that became a hard no for many.
2. Take some inspiration for Windirstat and everything. Especially everything. Use their search performance as a performance goal!
3. I noticed it in your road map but worth saying again. TABS!
4. Consider moving away from prisma. They really insulate you from your db and a lot of magic. And a part of me maybe unjustifiably is weary that they will do a license switch some day.
Can we stop treating "written in Rust" as a feature? It's one of the first things in the README. Whenever I see that I don't think "more stable", I think "someone's pet project".
I don't see any mention of Rust on their website as a feature. As far as the readme goes, it seems like a relevant detail to include for an open source project?
I like the idea. The vision is similar to Window's Explorer: seamless integration between offline files and online resources like Google Drive, Dropbox, OneDrive, Webdav, Samba, etc; fast, cached thumbnails; an indexer for fast search; encryption, backup etc. Of course in Windows Explorer all those features suck to varying degrees, some so hard they might as well not exist. So seeing an alternative implementation is nice, especially if it tries to take all these concepts even further. Most other file explorers stop far short of that vision.
Now if there is a way to identify dupes and consolidate, plus a way to instantly preview and dispatch photo libraries to new locations, these features would really answer the need to wrangle data.
Essentially it's an aggregator of file metadata from multiple sources. Accessing the local database can be a lot faster than accessing the data where it actually lives. It also allows for offline access if the device containing the files is temporarily removed. (Well, by access I mean previews and metadata.)
For example, I have a gigabit LAN with a Synology NAS, a server with a bunch of hard drives, and various networked machines. Gigabit LAN is pretty slow. Getting image previews of RAW photos on the NAS is insanely slow and frustrating. With something like SpaceDrive, you have basically instantaneous access to those previews, metadata, and Everything-like (the Windows application) search capabilities.
I'm really excited about it! I have files strewn about in so many places. Having access to them from a central location, with a single interface, not relying on a slow network, is really great. I might even go crazy and start to organize things with tags.
What do you mean? It is a file manager.
You use it to manage, explore, order your files. It could replace Explorer on Windows, Finder on MacOS or your file manager of choice on Linux.
Apparently they also have some special use cases in mind (if you read the roadmap) like multimedia conversion using ffmpeg woth the ability to offload the processing onto multiple computers.
> What do you mean? It is a file manager. You use it to manage, explore, order your files. It could replace Explorer on Windows, Finder on MacOS or your file manager of choice on Linux.
It's not. Read their description more carefully: it's a Dropbox with slightly extended functionality.
Dropbox is a storage with sync-client, not a file manager (even though it does have a filemanager-view). This app is working on top of storage-services, but it seems not to be like them.
Ok, I don't know if I'm doing it correctly, but there is no way to type some letters to jump to the folder starting with that name right? Also, no Cut/Copy/Paste/Delete yet I guess. Also, the one reason I run away from Finder on macOS is that it has no way to set 'Enter' to open or 'Delete' to delete files, and refuses to simply add a 'Cut' and paste option for files and folders (I know how to 'Move' after 'copying', but that's not the point, the point is that it's just stupid). Please make sure you don't do those mistakes. Keep whatever defaults you want, but at least have an option to enable 'Cut', 'Open', and 'Delete' with their expected buttons.
A file explorer that could work as a replacement for the Windows native one. You've got me interested. I am curious how much utility it has for those not needing the distributed parts. I'd also love to know if there's any performance uplift or hit for typical operations, like opening folders with either many files, large files, or both.
I don't suppose Spacedrive could (one day) show a 'details' view, but with the column widths ALWAYS correct? I get tired of having to do "size all columns to fit" constantly. Especially because it only considers the rows that are currently visible. Drives me up a wall.
A cross platform file explorer that has a nice UI and plugins is awesome. Many people have more 2 devices runing with different OS. But still, Web techs maybe not a good fit for system tools, for its heavy stack.
I don't wanna rag on this project and all the bugs since it's clearly in its super early days, but I keep wondering if there's something I'm missing:
Why no miller columns? Not a question just to Spacedrive but really any file manager, it's the main reason I pay and use OneCommander and it's surprising to me how few of them actually implement it, everything else feels a downgrade to me.
Super nice someone working through this, as it's the perfect target for Tauri, the motivation inside the GitHub makes it an exciting project that goes beyond just a regular file browser.
Since it has some glorified web app functionality, a non-tauri web demo with a remote `core` daemon would be super nice.
File explorers really should be one of the simplest tools available in a given desktop environment. Really, there are many tools getting the Electron treatment which should be vastly simpler than this insane upward ratchet of complexity JavaScript dominance has introduced into the equation.
Tried it out. Made an account. Looks like syncing between Mac and Windows at least isn't working correctly, on the same network. Really like the idea and am eager to hear about future development.
I recently discovered Double Commander (I Managed to overlook it for years). Once i started using it I couldn't go back to Total Command or Free Commander.
That is because the OS developer wants to push their product, not because it is something users want.
A third party cannot decide to provide something users do not want. Maybe they can get it preinstalled on Windows PCs or ANdroid phones. I cannot see MS (Or Google) being very happy with that.
Since always. Technically, any file explorer is accessing distributed storage. First the multiple storage-devices in your local system, later the different storage in your local network, which then grew to support remote servers like FTP, Webdav, etc. And modern file managers have for some years now also support for cloud-storage like OneDrive or Dropbox. Nothing new here, except being an app build from the ground up for supporting this specific targets.
> First the multiple storage-devices in your local system, later the different storage in your local network, which then grew to support remote servers like FTP, Webdav, etc.
These are not distributed file systems.
> And modern file managers have for some years now also support for cloud-storage like OneDrive or Dropbox.
OneDrive and Dropbox are not tied to any file manager.
The old age problem of having an open project where people don't understand what an alpha is.
You give this out to the world for feedback and people moan its not working.
I am old geek and back in the day you knew an Alpha was just for the playground to kick around - most likely will crash, worse case will destroy you PC but you have a play / provide some feedback and wait for the next release.
A lot of other projects do everything in the dark and do a big ta da at the end - and missed the opportunity for the community of "alpha" or "beta" testers to provide some feedback along the way.
Keep going - its added to my list to take look once in beta as I prefer to play in that playground rather than the alpha one these days.
It's the old-age disconnect between the marketing, the claims and the actual functionality.
For example, the title claims that it's a file explorer. However, someone in the comments shows that it fails at actually exploring files. Something which even an alpha project would not fail to do considering the claim.
Only when you read through the marketing copy and the comments, you realise that it's a hybrid cloud/local/cross-device Dropbox that creates a view of your files across systems/locations, and only once it's done that, only then can it do the actual file exploring. At least for now.
The title doesn't claim it IS a file explorer, it is an alpha version of something that aims to become a file explorer (for some definition of "explorer"). That's exactly the point of the OP?
> UPDATE: Spacedrive is under active development, we are in the pre-alpha stage, with builds occasionally released via GitHub actions, official alpha coming soon.
I think expectations broke as companies shifted from a focus on polished shrinkwrap to a ubiquitous race to market with continuous deployment.
For them, “alpha” and “beta” became ways to say “fresh out of the oven” and high profile revenue-generating products were proudly emblazoned with those words for years.
At this point, it doesn’t even mean anything. Half the internet is running on some 0.11.45-alpha of something or other, maintained by corporate engineering teams whose total compensation is in the millions.
It makes it legitimately hard for people to know what to expect and what standard to hold things to.
Time to wrap around and have -omegas. When that standard becomes the norm we can keep going backwards until -alpha, at which point we can use --omega and so on.
If they think they can make a better file manager, great, go ahead. But including transports in the file manager means that remote data only looks integrated, it isn't actually available to local apps.
Or (just as bad) they'll decide they need a copy-to-local and copy-back-to-network mechanism, which will work for some files opened by some apps but not all. Arghh.
Nemo (under Linux) does that for some protocols (eg. Android media transfer), and it is very annoying, especially as there are already FUSE drivers for (at least some) such protocols. In practice it means that the only thing you can do using Nemo is copy/move files around.
That's a very good point, I didn't even think about the aspect that FUSE is available system-wide, for all other applications to use transparently. That makes Spacedrive seem to come up really short, in comparison.
That was my reaction too, but FUSE is Linux only while this is cross-platform.
I am not convinced file managers need to be cross platform. There are plenty that will run on any desktop, IMO mobile platforms need different functionality and a very UI.
The real product as described on their website (not the github repo the linked) is that it is a drop box like sync service integrated into a file manager. I think most non-geeks will find it confusing compared to something that integrates with the familiar OS default file manager.
Yeah, FUSE is Linux only. But for completeness, for macs there is macFUSE, and for Windows there is winfsp. Both of these have fewer filesystems than FUSE, and I've used neither so I don't know how well they work.
It was kind of inevitable that after VC-funded terminals, mail clients, launchers sooner or later there would be file explorer.
As someone on Linux (popOS), I also gladly welcome it, as even the best file explorer I know (nemo) could use niceties that you find on Windows or macOS.
I'm highly skeptical of the economics of it though. The only way I would see it working out, if their planned "sync" product would be able to overcome the entrenchment of iCloud/OneDrive/Dropbox, which seems like a tall order. As a user I'd pay ~$50/year, but that would take a lot of customers to sustain even the current team size.
"It was kind of inevitable that after VC-funded terminals, mail clients, launchers sooner or later there would be file explorer."
Well, Nautilus [1] (nw "Gnome Files" apparently) was created for Gnome quite a long time ago now. The company was Eazel and included some ex-Apple luminaries. So money spent on file managing is nothing new.
OK, that explains why I have so many problems with the Nautilus UI! I switched to Thunar but it's missing some nice-to-haves. I'll have to check Nemo.
Regarding Spacedrive... Seems a solid idea but I think their UI goals (looks fancy) might not be aligned with my preferences (minimal, fast, high functionality, no jank).
The cloud storage is the part I'm not interested in. I already use Syncthing, and it fills that need really well (tough with a UX so meh that I'd be hesitant to hand it to non-developers). I'm interested in e.g. tagging of files and a good GUI, and Syncthing doesn't really do any of that (unless I've missed something).
What I would love to see is a UI on top of Syncthing that would allow for remote management so that it would be easier to add and remove folders without having to visit the remote devices physically.
I suppose I really should just get on and do something myself. :-(
I think for there are two already okay options. As Syncthings UI is already in the browser, one would be to just host that page in a way that it's remotely accessible (e.g. in you VPN, where I can highly recommend Tailscale). The other would be to use the option that Syncthing has built in to auto-accept folder invites from certain devices (that's what I have set up on my always-on server so I don't have to SSH into it every time).
I do miss the preview sidebar (bigger than thumbnail, renders and paginates PDFs even) and spacebar to pop a lightweight Preview.app modal window from when I used macOS.
What do you mean? Commercial file mangers exist for decades now. They are a bit out of style with everything being open source, but the old guard is still around on Windows & MacOS, and new fledglings appear on mobile regularly.
