|
|
BSP is an application layer data synchronisation protocol for delay-tolerant networks. It can operate over any transport that can deliver a simplex stream of bytes from a sender to a recipient on a best-effort basis, meaning that streams may be delayed, lost, reordered or duplicated by the transport. BSP does not ensure the confidentiality, authenticity or integrity of streams; that is the responsibility of a transport layer security protocol such as [BTP](BTP).
|
|
|
|
|
|
BSP synchronises data between two devices referred to as the local and remote peers. The data to be synchronised consists of messages, which are organised into channels. From BSP's point of view, a message is simply a string of bytes and a channel is simply a set of messages. A message created by the local peer is called a local message, while a message synchronised from the remote peer is called a remote message.
|
|
|
BSP synchronises data between two devices referred to as the **local** and **remote peers**. The data to be synchronised consists of messages, which are organised into **channels**. From BSP's point of view, a message is simply a string of bytes and a channel is simply a set of messages. A message created by the local peer is called a **local message**, while a message synchronised from the remote peer is called a **remote message**.
|
|
|
|
|
|
Each channel on the local peer belongs to a client, which is responsible for deciding which messages are valid (the validity policy), which remote messages should be stored on the local peer (the storage policy), and which local messages should be shared with the remote peer (the sharing policy).
|
|
|
|
|
|
### Notation
|
|
|
|
|
|
We use || to denote concatenation, double quotes to denote an ASCII string, and len(x) to denote the length of x in bytes, represented as a 32-bit integer. All integers in BSP are big-endian.
|
|
|
We use `||` to denote concatenation, double quotes to denote an ASCII string, and `len(x)` to denote the length of `x` in bytes, represented as a 32-bit integer. All integers in BSP are big-endian.
|
|
|
|
|
|
### Crypto primitives
|
|
|
|
|
|
BSP uses a cryptographic hash function, H(m), with an output length of HASH_LEN bytes, and a random number generator, R(n), with an output length of n bytes. R(n) must be either a true random number generator or a cryptographically secure pseudo-random number generator. We use H(m) to define a multi-argument hash function:
|
|
|
BSP uses a cryptographic hash function, `H(m)`, with an output length of `HASH_LEN` bytes, and a random number generator, `R(n)`, with an output length of n bytes. `R(n)` must be either a true random number generator or a cryptographically secure pseudo-random number generator. We use `H(m)` to define a multi-argument hash function:
|
|
|
|
|
|
* `HASH(x_1, ..., x_n) == H(len(x_1) || x_1 || ... || len(x_n) || x_n)`
|
|
|
|
|
|
> Implementation note: We propose to use BLAKE2s as the hash function, which gives HASH_LEN = 32.
|
|
|
> Implementation note: We propose to use BLAKE2s as the hash function, which gives `HASH_LEN = 32`.
|
|
|
|
|
|
### Client identifiers
|
|
|
|
|
|
Each client has a unique random identifier HASH_LEN bytes long:
|
|
|
Each client has a unique random identifier `HASH_LEN` bytes long:
|
|
|
|
|
|
* `client_id = R(HASH_LEN)`
|
|
|
|
|
|
### Channel identifiers
|
|
|
|
|
|
Each channel has a unique identifier HASH_LEN bytes long. The identifier is calculated by hashing the client identifier and a data structure called the channel descriptor:
|
|
|
Each channel has a unique identifier `HASH_LEN` bytes long. The identifier is calculated by hashing the client identifier and a data structure called the channel descriptor:
|
|
|
|
|
|
* `channel_id = HASH("CHANNEL_ID", client_id, channel_descriptor)`
|
|
|
|
... | ... | @@ -32,9 +32,9 @@ The channel descriptor is supplied by the client and is not interpreted by BSP. |
|
|
|
|
|
### Message format
|
|
|
|
|
|
Each message consists of one or more blocks. Each block is BLOCK_LEN bytes long, except the last block of the message, which may be shorter.
|
|
|
Each message consists of one or more blocks. Each block is `BLOCK_LEN` bytes long, except the last block of the message, which may be shorter.
|
|
|
|
|
|
> Implementation note: BLOCK_LEN must be ≤ 2^15 . We propose to use BLOCK_LEN = 2^15.
|
|
|
> Implementation note: `BLOCK_LEN` must be ≤ 2^15 . We propose to use `BLOCK_LEN = 2^15`.
|
|
|
|
|
|
* `message = block_1 || ... || block_n`
|
|
|
|
... | ... | |