Changes between Version 13 and Version 14 of BluePrint/Mobile/P2PSync


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

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Mobile/P2PSync

    v13 v14  
    3232
    3333===== 1.5. Peer persistence =====
    34 When a peer has been authenticated, the P2P sync component '''may''' allow the user to store information about the peer, including information that will allow the peer to be authenticated automatically during subsequent connections. If information about a peer has been stored, the P2P sync component '''must''' allow the user to revoke the peer's access to data.
     34When a peer has been authenticated, the P2P sync component '''may''' allow the user to store information about the peer, including information that will allow the peer to be authenticated automatically during subsequent connections. If information about a peer has been stored, the P2P sync component '''must''' allow the user to delete the information in order to prevent the peer from being authenticated automatically during subsequent connections.
    3535
    3636==== 2. Destination servers ====
     
    9393
    9494==== 1. Synchronize immutable documents ====
    95 
    9695In 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.
    9796
     
    103102
    104103==== 2. Synchronize changes to database records ====
    105 
    106104In 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.
    107105
    108106Detecting 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.
    109107
    110 This 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.
     108This 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 on the mobile device.
    111109
    112110The 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.
     111
     112==== Comparison of the options for each use case ====
     113The immutable documents option would be well suited to the "Situation Reporting and Assessment" and "Self-Organized Canvassing" use cases, which are primarily concerned with collecting data and delivering it to a central server.
     114
     115The "Aid Distribution" use case involves updating information as well as collecting it: for example, recording the fact that an individual who was previously eligible for aid has now received it. The database records option would be well suited to this use case, but it could also be handled with immutable documents by using a log structure: a log of documents representing events would be attached to each document representing an individual.
     116
     117The "Logistics Management" use case is primarily concerned with managing mutable information. This would be possible with immutable documents by using a log structure, but for efficiency it would probably also be necessary to maintain a representation of the current state. The complexity of maintaining two representations of the data might make the database records option preferable for this use case.
    113118
    114119=== Data Model ===
     
    116121
    117122=== Workflows ===
    118 <Diagrams or Pseudocode>
    119123
    120 === Site Map ===
    121 <for User Interface solutions>
     124==== 1. Peering between two mobile devices ====
    122125
    123 === Wireframes ===
    124 <for User Interface solutions>
     126===== 1.1. Peering without stored peer identities =====
     127* Users: U1 and U2, with devices D1 and D2, respectively
     128* U1 and U2 start peer discovery
     129* D1 discovers D2 and/or D2 discovers D1
     130* U1 chooses to peer with D2 and/or U2 chooses to peer with D1
     131* D1 connects to D2 and/or D2 connects to D1
     132* D1 and D2 exchange authentication information
     133* D1 and D2 display each other's authentication information
     134* U1 and U2 confirm the authentication information or skip authentication
     135* D1 and D2 become peers
     136* U1 and/or U2 may choose to store the peer's identity persistently
     137
     138===== 1.2. Peering with a stored peer identity on one device =====
     139* Users: U1 and U2, with devices D1 and D2, respectively
     140* D1 has stored peering information about D2
     141* U1 and U2 start peer discovery
     142* D1 discovers D2 and/or D2 discovers D1
     143* U1 chooses to peer with D2 and/or U2 chooses to peer with D1
     144* D1 connects to D2 and/or D2 connects to D1
     145* D1 and D2 exchange authentication information
     146* D1 automatically authenticates D2
     147* D2 displays D1's authentication information
     148* U2 confirms the authentication information or skips authentication
     149* D1 and D2 become peers
     150* U2 may choose to store the peer's identity persistently
     151
     152===== 1.3. Peering with stored peer identities on both devices =====
     153* Users: U1 and U2, with devices D1 and D2, respectively
     154* D1 has stored peering information about D2
     155* U1 and U2 start peer discovery
     156* D1 discovers D2 and/or D2 discovers D1
     157* U1 chooses to peer with D2 and/or U2 chooses to peer with D1
     158* D1 connects to D2 and/or D2 connects to D1
     159* D1 and D2 exchange authentication information
     160* D1 and D2 automatically authenticate each other
     161* D1 and D2 become peers
     162
     163==== 2. Configuring a destination server ====
     164* User or administrator enters the URL and OpenPGP key of a destination server
     165* The URL and OpenPGP key are automatically validated
     166* User or administrator may choose to test connectivity to the server
     167* User or administrator saves the configuration
     168
     169==== 3. Activating and deactivating P2P sync ====
     170* P2P sync is automatically activated whenever the user starts peer discovery
     171* P2P sync is automatically deactivated when peer discovery is not in progress and no peer connections are open
     172* User can see whether P2P sync is currently active
     173* User can manually deactivate P2P sync, which cancels peer discovery and closes any open peer connections
    125174
    126175=== Technologies ===
     176The P2P sync component will use the [https://code.briarproject.org/akwizgran/briar/tree/master Bramble library], which will be packaged as a Cordova plugin. The component will only be available on Android.
     177
     178The Bramble protocols [https://code.briarproject.org/akwizgran/briar-spec/blob/master/protocols/BTP.md BTP] and [https://code.briarproject.org/akwizgran/briar-spec/blob/master/protocols/BSP.md BSP] will be used for syncing data between peers. In Bramble terminology, the P2P sync component will be a BSP client. New modules for discovering, authenticating and storing peers will be developed, or the existing Bramble modules will be generalised.
    127179
    128180== Current Implementation ==
    129 <Leave open for a list of existing implementation of this solution in Sahana Eden:>
    130 <*a brief description of the implementation (date/time, name, design options chosen)>
    131 <*a link to the code>
    132 <*list of deployments of the implementation>
    133 <*links to case studies>
    134 <*short analysis of achievements/problems>
     181None.
    135182
    136183== Planned Implementation ==
    137 <List of goals for your implementations which you (include your name/github repo/IRC handle) are currently working on>
     184
     185=== Milestones ===
    138186
    139187== Future Extensions ==