Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Allow users to set storage location #276

Open
VA2XJM opened this issue Mar 26, 2018 · 4 comments
Open

[Feature Request] Allow users to set storage location #276

VA2XJM opened this issue Mar 26, 2018 · 4 comments

Comments

@VA2XJM
Copy link

VA2XJM commented Mar 26, 2018

Hi,

I'd like to see a new feature appears in Haven so the users can select the path where Haven stores pictures.

This would kind of fix #48 and #126 in a simple way. In fact storing pictures in a selected folder will allow users to be able to sync with whatever other devices/computers using SyncThing or whatever other sync apps allowing folders to be synced.

Use case : If the Haven device is removed or destroyed when discovered, evidences will most likely be transferred to other device(s). In my case for example I would sync my Haven device with my home server (24/7) and with my cellphone (not always on network).

@n8fr8 n8fr8 added this to the Next Sprint milestone Jul 2, 2018
@ghost
Copy link

ghost commented Aug 6, 2018

I must expand on this, and say that all logs (not just video logs), should be capable of remote storage.

One of the important features of Haven is to escape the dodgy 3rd party cloud that other security tools subject their users to, so it would not be a good idea (for example) to say "tick this box and expose your junk to dropbox (w/Condaleeza Rice on the board)". At the same time, remote logging is very important for security.

Simple approach:

User specifies where on the SD card to store all logs. That's it, as far as Haven goes. Some other tool can be responsible for syncing that directory to a remote location. The beauty of this is very little effort on the Haven project, and no redundant coding is needed. Also, Android users probably would like to have their phones backed up anyway, so this same syncing tool could be responsible for monitoring other local folders (e.g. /mnt/sdcard/DCIM) as well. We would want the syncing tool to be Orbot-aware, so that the remote server could be an .onion address.

SSHFS approach:

Ideally, a local mount point would establish a webdav or SSH connection to remote storage. The mount point appears local to the app, but it's instantly transmitted remotely.

The only problem with this approach is that there are no SSHFS tools on F-Droid.org. So a tool may need to be reinvented so people don't need to rely on google playstore blobs. I'm also not sure if the Playstore version of SSHFS can connect to .onion addresses.

If the network is disrupted, it would be important for Haven to continue logging things locally and sync them the moment it's reestablished. This perhaps suggests doing a hybrid of the two approaches.

(edit: this looks like free software for SSHFS => https://github.com/greyltc/android_external_sshfs. Not sure why that's not on F-Droid)

FTP:

We also might want to consider that some proprietary SOHO routers include file servers, which I think is normally FTP. Not sure though. Perhaps it's sufficient to say Openwrt routers have SSH and can adapt to whatever is needed, so no need to cater for FTP.

@jbizzle2
Copy link

jbizzle2 commented Aug 7, 2018 via email

@deviantollam
Copy link

when talking to @n8fr8 we discussed this and now Issue #330 exists... dupe of this?

@n8fr8
Copy link
Member

n8fr8 commented Sep 13, 2018

I think #330 represents the simple use case, and one we can finish this sprint.

The rest of this ticket is more about remote sync/transfer options. We are looking into both rsync and webdav, as well as an RSS/JSON feed that could be synced over the onion address.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants