BLE Mesh Syncing Spec

Overview

This document describes how two BLEMeshChat clients propagate messages to one another.

Procedure

1. Peers advertise BLEMeshChat Service containing a "Messages" Readable Characteristic, and an "Identity" Readable Characteristic.

2. Peers simultaneously scan for the BLE broadcast described above.

3. When a peer establishes a connection to a Peripheral or Central peer, it will wait a short time for the connection to be reciprocated.

   • If the local peer is acting as a Peripheral it should immediately establish a parallel connection to its remote peer in the Central role.

   • If the local peer is a Central it should request to read the "Identity" Characteristic as soon as possible. The local peer should also await a Peripheral connection from the remote peer.

   TODO: Is it possible to quickly ensure the second peripheral / central link is to the expected device without additional calls to the "Identity" Characteristic? Perhaps search by Device Name set to some maximum length nonce?

   The local and remote peer should abandon the symmetrical connection if any of the above steps fail to occur within some short time constant.

4. After a reciprocated connection is established and both peers read each other's "Identity" Characteristic, they receive the other's public key and signed alias.

5. Each peer begins an extended read to the other's "Messages" Characteristic:

   • Each peer reads the "Messages" Characteristic and repeats the read request on each successful delivery of characteristic data from the other until the Extended Response packet count is reached (or a GATT status code indicates the request is over?).

   • Each peer uses internal caching to avoid re-delivering messages to the same Identity.

6. The symmetrical connection is torn down, and the two peer avoid re-pairing with each other for some medium_time constant.