1> __Warning__ `unrecommended`: only implemented once and unclear whether it works, requires review23NIP-BE4======56Nostr BLE Communications Protocol7---------------------------------89`draft` `unrecommended` `optional`1011This NIP specifies how Nostr apps can use BLE to communicate and synchronize with each other. The BLE protocol follows a client-server pattern, so this NIP emulates the WS structure in a similar way, but with some adaptations to its limitations.1213## Device advertisement14A device advertises itself with:15- Service UUID: `0000180f-0000-1000-8000-00805f9b34fb`16- Data: Device UUID in ByteArray format1718## GATT service19The device exposes a Nordic UART Service with the following characteristics:20211. Write Characteristic22 - UUID: `87654321-0000-1000-8000-00805f9b34fb`23 - Properties: Write24252. Read Characteristic26 - UUID: `12345678-0000-1000-8000-00805f9b34fb`27 - Properties: Notify, Read2829## Role assignment3031When one device initially finds another advertising the service, it will read the service's data to get the device UUID and compare it with its own advertised device UUID. For this communication, the device with the highest ID will take the role of GATT Server (Relay), the other will be considered the GATT Client (Client) and will proceed to establish the connection.3233For devices whose purpose will require a single role, its device UUID will always be:3435- GATT Server: `FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF`36- GATT Client: `00000000-0000-0000-0000-000000000000`3738## Messages3940All messages will follow [NIP-01](/01.md) message structure. For a given message, a compression stream (DEFLATE) is applied to the message to generate a byte array. Depending on the BLE version, the byte array can be too large for a single message (20-23 bytes in BLE 4.2, 256 bytes in BLE > 4.2). In that case, this byte array is split into any number of batches following the structure:4142```43[batch index (first 2 bytes)][batch n][is last batch (last byte)]44```45After reception of all batches, the other device can then join them and decompress. To ensure reliability, only 1 message will be read/written at a time. MTU can be negotiated in advance. The maximum size for a message is 64KB; bigger messages will be rejected.4647## Examples4849This example implements a function to split and compress a byte array into chunks, as well as another function to join and decompress them in order to obtain the initial result:5051```kotlin52fun splitInChunks(message: ByteArray): Array<ByteArray> {53 val chunkSize = 500 // define the chunk size54 var byteArray = compressByteArray(message)55 val numChunks = (byteArray.size + chunkSize - 1) / chunkSize // calculate the number of chunks56 var chunkIndex = 057 val chunks = Array(numChunks) { ByteArray(0) }5859 for (i in 0 until numChunks) {60 val start = i * chunkSize61 val end = minOf((i + 1) * chunkSize, byteArray.size)62 val chunk = byteArray.copyOfRange(start, end)6364 // add chunk index to the first 2 bytes and last chunk flag to the last byte65 val chunkWithIndex = ByteArray(chunk.size + 2)66 chunkWithIndex[0] = chunkIndex.toByte() // chunk index67 chunk.copyInto(chunkWithIndex, 1)68 chunkWithIndex[chunkWithIndex.size - 1] = numChunks.toByte()6970 // store the chunk in the array71 chunks[i] = chunkWithIndex7273 chunkIndex++74 }7576 return chunks77}7879fun joinChunks(chunks: Array<ByteArray>): ByteArray {80 val sortedChunks = chunks.sortedBy { it[0] }81 var reassembledByteArray = ByteArray(0)82 for (chunk in sortedChunks) {83 val chunkData = chunk.copyOfRange(1, chunk.size - 1)84 reassembledByteArray = reassembledByteArray.copyOf(reassembledByteArray.size + chunkData.size)85 chunkData.copyInto(reassembledByteArray, reassembledByteArray.size - chunkData.size)86 }8788 return decompressByteArray(reassembledByteArray)89}9091```9293## Workflows9495### Client to relay9697- Any message the client wants to send to a relay will be a write message.98- Any message the client receives from a relay will be a read message.99100### Relay to client101102The relay should notify the client about any new event matching subscription's filters by using the Notify action of the Read Characteristic. After that, the client can proceed to read messages from the relay.103104### Device synchronization105106Given the nature of BLE, it is expected that the direct connection between two devices might be extremely intermittent, with gaps of hours or even days. That's why it's crucial to define a synchronization process by following [NIP-77](./77.md) but with an adaptation to the limitations of the technology.107108After two devices have successfully connected and established the Client-Server roles, the devices will use half-duplex communication to intermittently send and receive messages.109110#### Half-duplex synchronization111112Right after the 2 devices connect, the Client starts the workflow by sending the first message.1131141. Client - Writes ["NEG-OPEN"](/77.md#initial-message-client-to-relay) message.1152. Server - Sends `write-success`.1163. Client - Sends `read-message`.1174. Server - Responds with ["NEG-MSG"](./77.md#subsequent-messages-bidirectional) message.1185. Client -119 1. If the Client has messages missing on the Server, it writes one `EVENT`.120 2. If the Client doesn't have any messages missing on the Server, it writes `EOSE`. In this case, subsequent messages to the Server will be empty while the Server claims to have more notes for the Client.1216. Server - Sends `write-success`.1227. Client - Sends `read-message`.1238. Server -124 1. If the Server has messages missing on the Client, it responds with one `EVENT`.125 2. If the Client doesn't have any messages missing on the Server, it responds with `EOSE`. In this case, subsequent responses to the Client will be empty.1269. If the Client detects that the devices are not synchronized yet, jump to step 5.12710. After the two devices detect that there are no more missing events on both ends, the workflow will pause at this point.128129#### Half-duplex event spread130131While two devices are connected and synchronized, it might happen that one of them receives a new message from another connected peer. Devices MUST keep track of which notes have been sent to its peers while they are connected. If the newly received event is detected as missing in one of the connected and synchronized peers:1321331. If the peer is a Server:134 1. Client - It writes the `EVENT`.135 2. Server - Sends `write-success`.1362. If the peer is a Client:137 1. Server - It will send an empty notification to the Client.138 2. Client - Sends `read-message`.139 3. Server - Responds with the `EVENT`.