cloud sync

[paolostivanin]

It would be handy to have a cloud backup option integrated directly into the software. Providers that could be supported:

• webdav
• dropbox
• google drive
• ...

[paolostivanin]

there are many tools available on Linux to sync/copy files, no need to implement something here

[arimgibson]

@paolostivanin I've been trying to figure out something like this, would you be able to write up a super quick just bullet point list of how someone would go about this? I'm mostly not sure what files to sync, if I need to setup a cron to export, etc

With the base information, I feel like I could probably figure it out and would PR a proper tutorial to the docs

[paolostivanin]

Hello! There are only 2 files that need to be copied/synced:

• otpclient.cfg (located either here or there)
• the database (located either here or there)

To be honest, I don't think that adding sync within OTPClient would make much sense. There are no Android apps for it, so the only use case would be sync between PCs, but for that rsync/scp/dav/etc is more than enough (and cron'able)

[pm-pm]

I agree with you, because: "There are no Android apps for it"

But to have a sync with Android App "FreeOTP+" would be great! ;-) Using Nextcloud or something like this.

"FreeOPT+" <-sync-> "OTPclient"

Maybe you could "sync"/talk to the other team if you think it is a good idea?! ;-) I sync manually via LAN/NAS but it is bulky.

Thanks pm-pm

[arimgibson]

I feel like that could get tricky @pm-pm, because there are so many options for Android OTP. Could snowball into having to support LastPass Authenticator, Google Authenticator, Authy, Microsoft Authenticator, Duo, etc etc. I'm personally partial to andOTP, although it was recently announced that it's no longer being maintained

I might try out FreeOTP+ tho!

[arimgibson]

Been looking into it a bit more. It seems like unfortunately there is no 100% automated implementation because of shortfalls in current Android OTP software. My best suggestion for automation would be the following:

1. After adding a code, (manually) use the OTPClient CLI to export your codes to the format of your chosen Android OTP app
2. Setup cloud sync software like RClone to sync that folder
3. Have similar cloud sync software setup on Android to sync that file
4. Manually import that file on your chosen Android OTP app

It doesn't appear as if any of the common OTP apps support any automated import; it has to be done through the GUI. Then again, I'm no Android developer and might be missing something.

Fortunately, I don't think most people change their OTP codes frequently. What I'm planning on doing is setting everything up on OTPClient first, and then importing/exporting between OTPClient and my chosen Android OTP app (Aegis, andOTP, FreeOTP+...?) as needed.

Very lucky that OTPClient supports import and export from a variety of sources. Many of the Android OTP apps I've looked at only support exporting in their own format, which is a drag.

[paolostivanin]

I think there are 2 major issues with what you'd like to achieve:

1. it's likely that each app is using it's own DB format internally. Usually, the exported file is NOT the same as the real database.
2. AFAIK, in newer Android no app can write in another app's personal data folder

So the only option left would be to:

1. with OTPClient, sync to a network share (e.g. drive, dropbox, DAV, etc) the exported file
2. in Android, manually import the file

[paolostivanin]

Since there is some interest, I've reopened the issue. Let's see where we get :)

[arimgibson]

I'm down! Glad you're open to this idea overall, cuz seems like a pain to integrate :stuck_out_tongue:

I suppose the most seamless but frusterating implementation would be an Android port... not sure what that looks like as I've written exactly 0 lines of C in my life haha. Depending on the complexity, another idea could be making a fork of an Android OTP app that's already built out, and modifying it to use the same database formatting as OTPClient

I'm happy to do research into this if it seems viable. Would likely not be able to contribute on the technical side as much because my knowledge is constrained mostly to JavaScript and web design

[arimgibson]

Messed around with some preliminary research while waiting for updates to install haha

An Android port would most likely want to be implemented using the Android Native Development Kit, which allows for developing apps in C and C++.

Looking at some open-sourced Android OTP apps, the main choices seem to be andOTP, FreeOTP, and Aegis. All three are written in Java. If someone with Java experience was willing to take on that development, it's possible that some more custom functionality could be added into one of those apps to make it more similar to OTPClient. Otherwise, I'd wonder about the difficulty of just reworking one of those apps to conform to the database schema used by OTPClient. It seems like it could be possible to re-write that database fetching in C using Android NDK. Regardless, sync functionality would have to be added on top of any of those apps as it doesn't appear they have any sync functionality built-in, even with the same app on other Android devices

[paolostivanin]

The only thing I could implement from my side is syncing to a network service. Then it would be up to the user to deal with importing & co. Since importing is only done from time to time, IMHO it's not worth spending (my) time to deal with the Android part (reaching out to devs, explaining the problem, find a possible solution, etc).

[paolostivanin]

rough mock-up about what it could be:

[arimgibson]

The only thing I could implement from my side is syncing to a network service. Then it would be up to the user to deal with importing & co. Since importing is only done from time to time, IMHO it's not worth spending (my) time to deal with the Android part (reaching out to devs, explaining the problem, find a possible solution, etc).

That makes a lot of sense; totally understand. Tbh the more I think about it, the more I feel like just manually updating isn't too big of a deal... The effort this feature would take vs the time it would save users doesn't seem like a great trade-off

However I love the design on the mockup!

[paolostivanin]

I've set the status to "contributors-only", since I consider this a very minor feature and don't really have time to implement it right now. Maybe things will change in the future, but if someone comes first and develops it, then I'd be more than happy :smile:

[paolostivanin]

not enough interest on this, closing the suggestion.

[arimgibson]

Not to reopen haha, but maybe close as not planned instead of completed? Just makes it easier for people seeing in the future that this feature won't be implemented

[paolostivanin]

done, thanks for the feedback :)