Any Plans on Evolving This into a Web Service?

[Librechain]

Hey, great job on putting this together. You said you're still beta in in the 'readme', but this project looks extremely solid already.

Noticed in the readme, you state:

Yes, but this is not allowed by default, as the prvt server is listening on 127.0.0.1 only. To connect to a prvt server over the network, set the --address 0.0.0.0 option for the prvt serve command

And also

Note that prvt is optimized for running on your local machine and does not feature any authentication out-of-the-box. If you expose prvt on the network, anyone can access the files in your repository through the web UI.

I found the last statement there particularly interesting where it says that, "If you expose prvt on the network, anyone can access the files in your repository through the web UI."

I'm not doubting that this is true but rather wondering what the challenges would be (if any) for throwing some sort of 'login scheme' together in front of the exposed IP and then simply routing users to their respective repositories once authenticated.

If this is not feasible, then pardon my ignorance, but from what was described for this project this seemed like something that could be added w/o any trouble.

What Void Does This Project Fill Without Over-the-Network Communications?

Don't want to sound like an asshole with this question, but if someone is only going to use this tool locally, why even expose on the local network in the first place? Seems that it would be a lot more convenient (and quicker) for one to create some sort of ad-hoc storage within their own FS.

Again, please correct me if I'm wrong. Thank you.

[ItalyPaleAle]

This is a great question.

I built prvt because I wanted an E2E-encrypted storage app where to store files, especially photos and videos. There are other apps but I couldn't find something that allowed me to keep a sort of "archive" of files in a way that was quick to access when I wanted it.

A FS is an option, but that works best for "hot" data and then you have to deal with a whole bunch of other problems around synchronization, partial file access, etc. prvt is optimized for "cold" data and my goal was to offer a UI that allowed viewing documents quickly without having to download them first (although you can download files). I wanted to be able to look at the files inside a web browser because browsers are great at rendering media.

The main reason why I don't recommend running it over the network is that you'd miss out on E2E encryption. In fact, at that point there'd be one machine somewhere that sees your file decrypted. So it's not really E2E anymore.

The other issue is that prvt today is meant to be single-user and something that you launch when you need it.

Thus said, I have been thinking about what could be next for prvt and making it a web service is definitely on the backlog.

The first step in that direction was adding a preview of In-browser E2E encryption which is in the latest beta. This way the data stays encrypted all the way to the browser, and fixes the "philosophical objection" about not-making it "truly" E2E encrypted. This is in preview and I know there are a few bugs I need to fix (most are in my code, but at least one is in the web platform specification themselves). It's also read-only for now, but eventually I would like to add support for writing files too. Eventually, in-browser E2EE would ideally be the only option offered by prvt, it's just safer even on the local machine.

There are other things that need to be implemented before this can be used over the network however.

1. First is authentication as you correctly pointed out. Adding an auth check in the APIs is easy (like, requiring a JWT), but adding authentication overall is hard. I am thinking this would need to leverage an external identity provider. See my blog: https://withblue.ink/2020/04/08/stop-writing-your-own-user-authentication-code.html
2. Next is multi-user support. When you add authentication, this comes as a natural extension. It's doable but it will require some work on supporting multiple stores.
3. Last is encryption in transit. Adding TLS is easy, but users will expect support for Let's encrypt too. Which is not too hard, but it's another thing on the backlog.

In short, yes, eventually I would want this to become a web service. But I haven't had much time to work on prvt lately so there hasn't been much progress. But work has begun on the in-browser E2EE.

As for the beta... until the code gets audited by someone else, I won't be making this 1.0.

[ItalyPaleAle]

Closing as this is more of a question that an actionable item. But feel free to respond here!