BluePrint: Mobile Client Peer-to-Peer Synchronization

Introduction

Peer-to-peer sync will enable EdenMobile users to synchronize data between their devices without connecting to a server. This will allow mobile users to operate and collaborate more easily in areas where internet access is unreliable or unavailable.

Peer-to-peer sync capabilities exist in ​Serval Mesh and a number of messaging apps including ​Briar, ​Murmur and ​Anonymouse.

Stakeholders

EdenMobile users are the primary stakeholders - they will be able to use P2P sync to share data with each other. The data subjects will also be stakeholders, and appropriate data handling controls to protect the confidentiality, integrity and authenticity of data must be built in. If the server needs to be aware of P2P sync, for example in order to deduplicate data received from mobile clients, then the people deploying and operating the server will also be stakeholders.

User Stories

​User stories

Requirements

Functional requirements

1. Establishing peer relationships

1.1. Peer visibility

The P2P sync component must be able to make the device it is running on visible to nearby devices in order to establish a peer relationship.

1.2. Peer discovery

The P2P sync component must be able to discover nearby devices that have made themselves visible.

1.3. Peer selection

When peers have been discovered, the P2P sync component must allow the user to choose a device to establish a peer relationship with.

1.4. Peer authentication

When the user has chosen a device to peer with, the P2P sync component must allow the user to authenticate the peer before granting the peer access to any resources. The P2P sync component may allow the user to continue without authenticating the peer.

1.5. Peer persistence

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 resources.

2. Destination servers

2.1. Destination server configuration

The P2P sync component may allow the user or an administrator to enter the details of a destination server for the data being synchronized.

3. Data synchronization

3.1. Data selection

The P2P sync component may allow the user to choose which data to synchronize, either with peers in general or with each specific peer. When data is received from a peer, the P2P sync component may automatically choose it for synchronization with other peers.

3.2. Data deletion

The P2P sync component may allow the user to delete data from the device, regardless of whether that data has been chosen for synchronization. The P2P sync component may automatically delete data that has been received from peers, for example on receiving confirmation that the data has been delivered to a destination server.

4. Managing conflicts

4.1. Conflict detection

The P2P sync component must assign an identifier to each item of data chosen for synchronization, such that two peer devices performing synchronization can tell whether they are using the same identifier to refer to different data.

4.2. Conflict resolution

When a conflict is detected during synchronization, the P2P sync component may resolve the conflict automatically, either by merging the conflicting items or by assigning them distinct identifiers. If a conflict cannot be resolved automatically, the P2P sync component must be able to continue synchronizing other items with the peer. The P2P sync component may inform the user of conflicts that cannot be resolved automatically.

Non-functional

​http://en.wikipedia.org/wiki/Non-functional_requirements

Interoperability

Standards

System Constraints

Design

<Where relevant include alternative design options>

Data Model

(e.g. EER or class diagrams)

Workflows

<Diagrams or Pseudocode>

Site Map

<for User Interface solutions>

Wireframes

<for User Interface solutions>

Technologies

Current Implementation

<Leave open for a list of existing implementation of this solution in Sahana Eden:> <*a brief description of the implementation (date/time, name, design options chosen)> <*a link to the code> <*list of deployments of the implementation> <*links to case studies> <*short analysis of achievements/problems>

Planned Implementation

<List of goals for your implementations which you (include your name/github repo/IRC handle) are currently working on>

Future Extensions

<List of features which could be included, but are outside of the scope of this extension>

Outstanding Questions

<Questions about the features or design that haven't been (and need to be) answered>

References

<Links to external resources>

---

BluePrint