Changes between Version 13 and Version 14 of BluePrint/Mobile/P2PSync
- Timestamp:
- 05/30/17 16:56:04 (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BluePrint/Mobile/P2PSync
v13 v14 32 32 33 33 ===== 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.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 delete the information in order to prevent the peer from being authenticated automatically during subsequent connections. 35 35 36 36 ==== 2. Destination servers ==== … … 93 93 94 94 ==== 1. Synchronize immutable documents ==== 95 96 95 In 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 96 … … 103 102 104 103 ==== 2. Synchronize changes to database records ==== 105 106 104 In 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 105 108 106 Detecting 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 107 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 intelligentlyon the mobile device.108 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 on the mobile device. 111 109 112 110 The 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 ==== 113 The 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 115 The "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 117 The "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. 113 118 114 119 === Data Model === … … 116 121 117 122 === Workflows === 118 <Diagrams or Pseudocode>119 123 120 === Site Map === 121 <for User Interface solutions> 124 ==== 1. Peering between two mobile devices ==== 122 125 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 125 174 126 175 === Technologies === 176 The 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 178 The 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. 127 179 128 180 == 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> 181 None. 135 182 136 183 == 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 === 138 186 139 187 == Future Extensions ==
