| 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 documents might include a completed form or a photo. |
| 96 | | |
| 97 | | Detecting 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. Therefore from the point of view of the sync protocol, conflicts are always avoided. |
| | 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. For example, a completed form or a photo can be treated as an immutable document. |
| | 96 | |
| | 97 | Detecting 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. |
| 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 the use case could also be handled with immutable documents by using a log structure: a log of documents representing events would be attached to a document representing an individual, for example. |
| 116 | | |
| 117 | | The "Logistics Management" use case is primarily concerned with managing mutable information. This would be possible with immutable documents 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 | The immutable documents option is 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 is well suited to this use case, but the use case can also be handled with immutable documents by using a log structure: for example, a log of documents representing events is attached to a document representing an individual. |
| | 116 | |
| | 117 | The "Logistics Management" use case is primarily concerned with managing mutable information. This can be handled with immutable documents using a log structure, but for efficiency it may also be necessary to maintain a representation of the current state. The complexity of maintaining two representations of the data may make the database records option preferable for this use case. |
| | 180 | The structure of the BSP client, and the interface between the P2P sync component and the !EdenMobile app, depend on which design option is chosen. |
| | 181 | |
| | 182 | In both options, the P2P sync component exposes the following capabilities to the !EdenMobile app: |
| | 183 | * Activate and deactivate P2P sync. |
| | 184 | * Discover and authenticate peers. |
| | 185 | * Optionally store peer identities in the component's database. |
| | 186 | * Optionally configure a destination server and store the configuration in the component's database. |
| | 187 | * Optionally encrypt the component's database with a password-derived key. |
| | 188 | |
| | 189 | The P2P sync component also implements the following capabilities internally: |
| | 190 | * Connect to the destination server when internet access is available. |
| | 191 | * Synchronize data with peers and the destination server. |
| | 192 | * Authenticate delivery confirmations received from peers and the destination server. |
| | 193 | |
| | 194 | The component has the following dependencies: |
| | 195 | * Bramble |
| | 196 | * OpenPGP |
| | 197 | |
| | 198 | ==== 1. Synchronize immutable documents ==== |
| | 199 | |
| | 200 | In this option, the P2P sync component exposes the following extra capabilities to the app: |
| | 201 | * Store immutable documents in the component's database. |
| | 202 | * Optionally encrypt documents with the destination server's public key before storing them. |
| | 203 | * Choose documents from the component's database to be synchronized. |
| | 204 | |
| | 205 | The P2P sync component implements the following extra capabilities internally: |
| | 206 | * Delete documents that were received from peers and have been confirmed by the server. |
| | 207 | |
| | 208 | ==== 2. Synchronize database records ==== |
| | 209 | |
| | 210 | In this option, the P2P sync component exposes the following extra capabilities to the app: |
| | 211 | * Choose records from the app's database to be synchronized. |
| | 212 | |
| | 213 | This option requires the app's database to be ported from the [https://github.com/nolanlawson/cordova-plugin-sqlite-2 Cordova SQLite plugin] to [https://pouchdb.com/ PouchDB], which [https://pouchdb.com/adapters.html wraps] the SQLite plugin. The [https://github.com/pouchdb-community/pouchdb-replication-stream PouchDB Replication Stream] module extracts changes from the database to be synced via Bramble. |
| | 214 | |
| | 215 | This option has the following extra dependencies: |
| | 216 | * PouchDB |
| | 217 | * PouchDB Replication Stream |
| | 218 | |
| 193 | | <Links to external resources> |
| | 232 | * [http://developer.servalproject.org/dokuwiki/doku.php?id=content:servalmesh:main_page Serval Mesh] |
| | 233 | * [https://briarproject.org/ Briar] |
| | 234 | * [https://github.com/casific/murmur Murmur] |
| | 235 | * [http://whispercomm.org/shout/ Anonymouse] |
| | 236 | * [https://code.briarproject.org/akwizgran/briar/uploads/655c21456bbc36a83193bdb5e0473f07/SahanaEDENBrambleProjectUseCases.odt User stories] |
| | 237 | * [http://docs.couchdb.org/en/2.0.0/intro/consistency.html CouchDB: Consistency] |
| | 238 | * [https://wiki.apache.org/couchdb/Replication_and_conflicts CouchDB: Replication and conflicts] |
| | 239 | * [https://code.briarproject.org/akwizgran/briar/tree/master Bramble] |
| | 240 | * [https://code.briarproject.org/akwizgran/briar-spec/blob/master/protocols/BTP.md BTP] |
| | 241 | * [https://code.briarproject.org/akwizgran/briar-spec/blob/master/protocols/BSP.md BSP] |
| | 242 | * [https://github.com/nolanlawson/cordova-plugin-sqlite-2 Cordova SQLite Plugin] |
| | 243 | * [https://pouchdb.com/ PouchDB] |
| | 244 | * [https://pouchdb.com/adapters.html PouchDB: Adapters] |
| | 245 | * [https://github.com/pouchdb-community/pouchdb-replication-stream PouchDB Replication Stream] |
