Changes between Version 10 and Version 11 of BluePrint/Mobile/P2PSync


Ignore:
Timestamp:
05/29/17 16:30:04 (8 years ago)
Author:
MichaelRogers
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Mobile/P2PSync

    v10 v11  
    33
    44== Introduction ==
    5 Peer-to-peer sync will enable [http://eden.sahanafoundation.org/wiki/DeveloperGuidelines/EdenMobile EdenMobile] users to synchronize data between mobile devices without connecting to a server. This will allow users to operate and collaborate more easily in areas where internet access is unreliable or unavailable.
     5Peer-to-peer sync will enable !EdenMobile users to synchronize data between mobile devices without being connected to a server. This will allow users to operate and collaborate more easily in areas where internet access is unreliable or unavailable.
    66
    77Peer-to-peer sync capabilities exist in [http://developer.servalproject.org/dokuwiki/doku.php?id=content:servalmesh:main_page Serval Mesh] and several messaging apps including [https://briarproject.org/ Briar], [https://github.com/casific/murmur Murmur] and [http://whispercomm.org/shout/ Anonymouse].
     
    3737
    3838===== 2.1. Destination server configuration =====
    39 The P2P sync component '''may''' allow the user or an administrator to enter the details of a '''destination server''' for the data being synchronized. If a destination server has been configured, the P2P sync component '''may''' deliver data to the server automatically when internet access is available.
     39The P2P sync component '''may''' allow the user or an administrator to enter the details of a '''destination server''' for the data being synced. If a destination server has been configured, the P2P sync component '''may''' deliver data to the server automatically when internet access is available.
    4040
    4141==== 3. Data synchronization ====
     
    6666
    6767===== 1.3. Access control =====
    68 The P2P sync component '''must''' authenticate peers, or allow the user to authenticate them, before granting them access to data. If a destination server has been configured, the P2P sync component '''must''' authenticate the destination server before granting it access to data. If a delivery confirmation from a destination server is received, either directly from the server itself or from a peer, the P2P sync component '''must''' authenticate the delivery confirmation before acting on it or synchronizing it with peers.
     68The P2P sync component '''must''' authenticate peers, or allow the user to authenticate them, before granting them access to data. If a destination server has been configured, the P2P sync component '''must''' authenticate the destination server before granting it access to data.
     69
     70If a delivery confirmation from a destination server is received, either directly from the server itself or from a peer, the P2P sync component '''must''' authenticate the delivery confirmation before acting on it or synchronizing it with peers.
     71
     72To protect the privacy of data subjects, the P2P sync component '''may''' encrypt data before synchronizing it with peers, such that it can only be decrypted by the destination server.
    6973
    7074==== 2. Performance ====
     
    7377The P2P sync component '''must not''' significantly reduce the battery life of the device when P2P sync is not being used.
    7478
    75 ===== 2.2. Network efficiency =====
     79===== 2.2. Communication efficiency =====
    7680The P2P sync component '''must not''' significantly increase the mobile data usage of the device, regardless of whether P2P sync is being used.
    7781
    7882=== Interoperability ===
    79 For each deployment, the same version of the !EdenMobile app will be used for all mobile devices, which should minimize interoperability issues. The protocols used between peers, and between mobile devices and the destination server, should use version negotiation so that any interoperability issues are detected as early as possible. Interoperability with other applications is not required.
     83For a given deployment, the same version of the !EdenMobile app will be used for all mobile devices, which should minimize interoperability issues. The protocols used between peers, and between mobile devices and the destination server, should use version negotiation so that any interoperability issues are detected as early as possible. Interoperability with other applications is not required.
    8084
    8185=== Standards ===
    82 Communication between mobile devices and the destination server should use HTTPS.
     86Communication between mobile devices and the destination server should use HTTPS. If the P2P sync component protects the privacy of data subjects by encrypting data before synchronizing it, this should be done using OpenPGP.
    8387
    8488=== System Constraints ===
     89The P2P sync component must operate on mobile devices with limited battery life, storage, and network bandwidth. It must be usable with minimal training and background knowledge. It must tolerate intermittent and unreliable connections between peers, and between mobile devices and the destination server.
    8590
    8691== Design ==
    87 <Where relevant include alternative design options>
     92There are two design options:
     93
     94==== 1. Synchronize immutable documents ====
     95
     96In this option, the data to be synced consists of immutable documents, each of which originates on one mobile device and is synced to other devices without being modified. Examples of immutable documents might include a completed form or a photo.
     97
     98Detecting and resolving conflicts is simple in this option: each data item is identified by its cryptographic hash, which ensures that if two items have the same identifier then they also contain the same data.
     99
     100This option also makes it simple for data to be encrypted on the originating device and decrypted on the destination server.
     101
     102The destination server confirms delivery of an immutable document by creating a delivery confirmation containing the document's identifier, signed with the server's OpenPGP key. The confirmation can be synced between mobile devices, which can delete the confirmed document if they no longer need a local copy.
     103
     104==== 2. Synchronize changes to database records ====
     105
     106In this option, the data to be synced consists of database records that may be modified independently on any device. This provides maximum flexibility for the application, as anything stored in the database can potentially be synced, but it also requires the application to handle conflicts that may arise from concurrent modification of a given record on multiple devices.
     107
     108Detecting and resolving conflicts in this option follows a similar approach to [http://docs.couchdb.org/en/2.0.0/intro/consistency.html CouchDB]. Non-conflicting updates are applied automatically. If a conflict occurs, the P2P sync component stores all conflicting versions of the record and asks the application to resolve the conflict, which may require user intervention, either on the mobile device or on the destination server.
     109
     110This option allows individual database fields to be encrypted on the originating device and decrypted on the destination server, but if a conflict occurs in an encrypted field it may not be possible to resolve it intelligently on the mobile device.
     111
     112The destination server confirms delivery of a record by creating a delivery confirmation containing the record's identifier and [https://wiki.apache.org/couchdb/Replication_and_conflicts revision], signed with the server's OpenPGP key. The confirmation can be synced between mobile devices, which can delete the confirmed record if they are storing the same revision and no longer need a local copy. Multiple revisions of a given record may be confirmed by the destination server.
    88113
    89114=== Data Model ===