intro⌗

Traditionally, file browsers have always been local. They’re usually used to move, copy, modify and create files and folders. The reason for this is simple: There is no need to create a remote file server.

Why create a remote file server, when all your devices are connected to your local computer. Since modern operating systems do not share resources such as CPUs or memory, having a remote file server isn’t of much use.

However, one application of a remote file server could be through a hub. A lot of modern operating systems have the ability to share their hard disks over the network and so making one computer have the sources of several other computers, thereby increasing the efficiency and power of one single computer.

A small low-power computer could act as a hub. The reason you’d use a small low-power computer and not a big beefy pc is because it’s much more elegant.

Think about how easy it’d be to avoid data corruption if your file browser could depend on a battery for redundancy. Or, how much power you can give a device that doesn’t have many ports such as your smart phone.

This is practically the end of my proposal, there is no other use for remote file browsers besides safety and power. It’s not necessarily efficient but it can be definitely.

stack⌗

The HTTP protocol dominates. It is, by far, the most popular and accessible protocol there is, with great library support in most languages, even in the mature 30 year old language Common Lisp.

backend⌗

Go is a pretty good language for low-level abstractions that are good enough. A language like Rust, C, or C++ could also do, but I prefer Go.

cool things that Go provides⌗

  • stability
  • concurrency
  • single binary distribution
  • cross platform
  • data structures to support all kinds of devices with ease

and a plethora of other pros. Although I am tempted to use a language like Common Lisp, but its library is nowhere near Go.

Plus, Go’s io/fs provides rock-solid file system abstractions that can allow for easy file operations in filesystems. Simply put, Go is, in my opinion, the best decision for this project.

frontend⌗

For the interface, a regular old HTML web app would work just fine.

cool things that Web Apps provide:⌗

  • libraries that can last a life time
  • insane device support
  • can have low-resource footprint
  • can look extremely print

features⌗

Here are features I’d like to implement:

  • mounting flash drives
  • mounting other devices: MTP protocol and iPhone’s protocol
  • expose specific files through a virtual remote file system such as NFS or SSH or WebDav
  • approximate times for file operations
  • dynamic speed limits for operations
  • REST api exposure
  • basic bitmask permission system

non-features⌗

More importantly, here are features I’d like to avoid implementing:

  • history support: It doesn’t matter and you could implement it through a custom interface
  • an authentication system: For authentication, I’d like to use a service such as Authelia or any other authentication service
  • any notification system: Notification should be done through a middleware similar to the authentication system or not done at all
  • any sort of payment, order, or item system…
  • image thumbnails: no-need. just display file names and their metadata
  • any sort of special file execution: files can be streamed through http, but how it executes depends on the operating system
  • any scripting language outside of invoking an external program and reading its output

last note⌗

I look forward into making this project come into life, as it’s simple and It’ll be useful for me. I’d like to also make it open source for everyone to use and modify. It’ll be my first open source project and I hope my code isn’t too spaghetti-like…