Need to stream my encrypted movies from my google drive. I think that will be the main marketing point.
The browser doesnāt give access to the file system. The HTTP server needs an endpoint to serve up file listings. This is what we do for https://relicabackup.com. Itās still safe, as the HTTP server runs with the userās permissions, unless you run it as root; in other words, it takes on after the OSās normal permissions model, and the browser requires no extra permissions to be granted this way.
Also something weāve (mostly) figured out for Relica ā and it depends highly on the platform and is mostly simple (except on Windows) ā but what does rclone need to run as a daemon for? Unless youāre using rclone serveā¦
minio does this with js. Asks for access/secret key to list files in a web browser GUI. You can do a few operations, like download & delete.
A GUI would be very nice particularly if youāre using crypt & canāt use the one provided by the backend. I use the backup-dir flag on one remote and if I want to actually restore a deleted file it can be somewhat difficult to locate the file, properly escape the path, etc
I think Iāve used the wrong term by throwing in daemon. Iām sorry for the confusion.
What I imagine is to have a real desktop app for interaction and a helper/background app to keep track of/execute scheduled backups with desktop notifications. Something along the lines of Arq, Backblaze, etc.
I truly believe that a dedicated desktop app yields a better user experience than a browser based one. Especially when handling files via drag and drop. I may just be old and believe in platform specific paradigms. So please feel free to enlighten me with loads of examples.
Ah, okay, so now youāre talking about backup software. (And yes, this is what I had thought you meant before.) I get that rclone is used for backups a lot, but thatās definitely just one use case for it ā and Iām not sure that an official rclone UI would be a good fit for making rclone only backup software, or diverting too much engineering effort to just backups. IMO rclone should do one thing and do it well: file operations in the cloud.
It depends I think. People are very comfortable in the browser. Browsers provide standard navigation cues like a back button, a unique address for every screen the user is looking at, and makes documentation much easier. For example, the docs can point to a link rather than instructions for clicking through to find a certain element in a native UI
Yes, dragging files around is definitely better handled native; but browsers can be the drop targets of files, too. Admittedly it doesnāt provide all the information about the file that might be necessary, but in that case, there are definitely ways to build good in-browser-app drag-and-drop experiences, with the likes of a file pane on the left and on the right, and the ability to drag between them, if not from the native file explorer. But if you have a good file explorer in the same window, you may not need to fuss with one outside the window, which might even be easier. (Messing with window layouts, trying to size them and put them next to each other, is a pain in my experience.)
Anyway, just my $0.02. Thereās a lot of potential for browser-based GUIs. We want to push the limit with Relica, and Iām confident it will make a statement that browser UIs are totally workable.
Web UI served from rclone is very cool idea.
Itās better if rclone serve provide an RESE API, so a third-party web or GUI APP can access rclone serve
3 Likes
I do like this approach better than a fully-baked GUI into rclone itself.
I agree that approach is also what I prefer. With it we have all possiblities while maintaining a lightweight rclone binary.
Native file explorer
Thatās in my opinion the way to go. Have a stable REST API so tools can access rclone as a backend.
The software list was only given as an example to the automation and scheduling. Of course we should keep RClone as versatile as it is.
My thinking would be to extend the rc interface and to make a new command rclone serve rc or something like that which would run the rclone rc interface. Optionally it could serve files from somewhere.
1 Like
My fantasy is browser based gui, something like javascript client, so encryption end decryption would be on local client side.
Working in IOS on safari, chrome android, all browsers.
With possibility to bridge serve, so browser would create server like in rclone serve http or webdav command.
So other apps on ios, webdav clients would be able to use it.
For now i have normal rclone binary on jailbroken ios and filza so everything works for me.
But i cant upgrade my ipad to not lose jailbreak and lose shell and cydia and filza.
So such browser based client would be amazing.
1 Like
That is theoretically possible! I did compile rclone with gopherjs a while back and the go toolchain support web assembly now.
Weād need to work out
- how to get rclone doing its http requests through the browser
- how to attach that to some sort of GUI
A big project, but not impossible! Iāve been amazingly impressed with gopherjs & go/wasm - here are some things I made with it as warmup exercises!
2 Likes
https://gopherjs.github.io/playground/#/mjai5AS0t_
panic: network access is not supported by GopherJS
in context of rclone serve ā¦
but maybe
?
I donāt think the in-browser javascript or wasm world will ever support a server alas.
-being able to transfer from one remote to another remote.
-option to mount remote
-able to manipulate individual files copy/move etc.
So to summarize everything till now we will make a lightweight inbrowser GUI.
Suggestions on which language/js to use ?
What possiblities do we have to make rclone serve work from within the browser ?
Kill me for suggesting this, but what about making it an Electron app? Portability will be a non-issue, the UI wouldnāt be hard to bundle, and I think rclone could be bundled directly for those who donāt want to setup a GUI and rclone separately.