Rotki as a Service

[LefterisJP]

Motivation

From feedback we have been getting, there are many users who don't want to be running a local application and would be willing to pay to have Rotki provided to them as a service, hosted in a webserver as long as it has the same advantages as the local Rotki version.

Rotki as a service would also be private and transparent since:

1. The same code as the local application will be served and as such will be opensource.
2. The user's data may be stored in the server, but just like with the local Rotki will be encrypted with Sqlcipher and as such will not be visible to the server operators.

Specification

Frontend

@kelsos TODO

Backend

@LefterisJP TODO

Related

#522 #523

[isidorosp]

What's the feasibility (technical & cost) of storing the data somewhere decentralized (e.g. IPFS)? I think the offering "aaS" makes sense, but it would be really cool if we can also make it decentralized in keeping with the ethos of the application and the blockchain in general. I realize something like IPFS is probably expensive, but perhaps it's something one could tie to Premium users? That way, even if "rotki" goes away, users will always be able to get their data (you could build in a fail-safe that allows you to export the data from IPFS that would never have to go through a central server).

[LefterisJP]

Hey @isidorosp thanks for the comment! I don't think IPFS makes sense for this. The whole point of Rotki as a service is to be able to use Rotki from anywhere without any need to run the software locally.

In that special case the safest place to have your data would be in a server normally like the OP describes. There is no advantage to IPFS here since this is your private encrypted data. You don't want to share it with other people, so IPFS wouldn't work.

[isidorosp]

IPFS is just where you store the user data. The webapp could still be centrally hosted somewhere (although technically if it's pure front-end you could probably even run it on IPFS, like Melon do). You would put the user data on IPFS (encrypted, of course), instead of storing it centrally. That way, there is never 1 central entity that actually holds the users' data; the users' data would always be available to them (and only them) on IPFS.

EDIT:

• Obviously there is a risk putting an encrypted document on a public platform, (i.e. the content will not be "quantum safe")
• The biggest obstacle/hurdle is basically that IPFS is not a mutable storage system (even though there are tools to interact with it as such). Every time you add data/content there you're basically just pointing to a new set of data which is non-ideal, both from a cost/storage perspective as well as the point above re: data security.

[LefterisJP]

And data in IPFS are not permanent unless pinned. Generally it makes no sense for this use-case.

[kelsos]

As we recently discussed, a possible approach to the rotki as a service would be the following.

We use the official docker images (we have to make the CI create and push a docker image on release). This way, we should be able to provide a user with their hosted instance of rotki.

The users will use their web-service account to gain access to their instance of rotki. After that, they will gain access to the regular rotki app login page.

There should be a single different instance of rotki for each user using this service.

In this context, the web-service only verifies access to the service. After that, the user has to create "local" rotki accounts and remember the credentials. Following, this approach ensures that a user's account is encrypted with their key and only unlocked by them.

We should provide an easy way for users to download their data from the service. Since the hosted version is the same as the local, a user should be able to use them in their local version too.

After access to the service ends, we should provide a grace period, during which we notify a user that their data are available for download for a period of x days before being deleted.

Some of the things we also discussed were for improving the login experience of the application itself. It would also apply to the secondary login of the hosted instance.

One of the ideas we discussed was the use of MetaMask or WalletConnect for the account login. That would work by generating the account password by signing a message.

That is the rough outline of the proposal.

We need to do more detailed research on automation and monitoring for the instances, along with best practices on container security.