Profile in one file

[kolodziej]

Profile

There has been discussion about multi devices support, profile synchronising, password protection etc.. I would like to suggest project of profile in one, encrypted, easy to synchronise file.

This file would be an archive which would include:

1. Tor hidden service's data: private_key and hostname files
2. Tor's configuration and state files like torrc etc. (maybe not necessary in the future when Tor 0.2.7.x will be released)
3. Ricochet's settings: ricochet.json
4. Optionally: archives with all conversations

Whole file will be gzip or bzip2 tarball or encrypted with AES or aby other good encryption algoruthm. We can set file's extension to .rico in order to let Ricochet scan some directories (home, executable file's location etc.) for such files.

I know that now Tor needs to have all config files in readable form, but in my opinion it's still better to extract these files to temporary directory which will be removed after exiting Ricochet instead of keeping them unencrypted all the time. What's more in Linux-like systems we can use filesystem with tmpfs to store all extracted sensitive files to be sure that after restart they will be deleted in case something went wrong and application was terminated.

I heard that Tor 0.2.7 will let us to pass all data needed to create hidden service through control port. Having profile in such form will let us to implement support for this feature of Tor very fast.

Storing conversation archives in profile could be a bit problematic due to the fact that when profile will be used on more devices, archives could be incoherent. So synchronization will have to be provided by dedicated application which will solve all conflicts.

I think that it could keep one file with archive for each contact. Google Protocol Buffers which supports Ricochet's protocol can provide a structure for archive (two fields: repeated Packet and last synchronization date) which could be serialized to stream.

We can also consider creating this one file using Google Protocol Buffers instead of tarball. It is tested mechanism and we know it is very easy to serialize and deserialize data from and to C++ streams, so we could have everything in memory and if need be save it to temporary files.

Creating profile in this way will help us to solve #235 (storing/switching identities). Such profiles will also be easier to backup.

Merging, conflicts

If we have profile A from current device and profile B from other device, we should:

1. sdate = older last synchronisation date from A or B
2. put all messages older than sdate from both profiles to a map using SHA hash of whole message as key (we will remove duplicates this way)
3. remove all messages newer than sdate from both profiles
4. sort by date all messages from map and put to both profiles

Ricochet's settings would be synchronized in normal way: newer data is current. Dedicated solution could also prevent from overwriting private_key by other. Such situation could happen if user would try to synchronize profiles for different HS'.

Synchronization server

Due to the fact that each profile will represent the same hidden service, we cannot run two instances of Ricochet and synchronize their profiles. Users cannot use applications like Seafile, Dropbox or even MEGA, because of special mechanism which is required to synchronize archives. In my opinion the best solution would be creating small server application which will create separate hidden service. Client will connect to it, send his encrypted profile, server will:

1. decrypt it
2. synchronise
3. encrypt
4. send back to user

Each server will support only one user. So there will be no central one which would store more profiles of different users. Everybody will be responsible for running his instance on own machine.

It doesn't seem to be problematic. Nature of Tor's hidden services let us to run 'public' server even if we haven't public IP address. It can be even non-stop working computer at home or, better, cheap VPS.

---

Related issues: #33, #99, #227

[cybershambles]

I'd argue for having the ability to ONLY ever connect from a single location is a selling point.
If I'm connected from my box, and another box tries to bootstrap my profile... I should be alerted

That's a pretty good sign I should dump the profile :)

Maybe offer the ability to create single and multisite profiles?

[DirectorX]

+1