Public-Mesh-Research-Report.md

@@ -355,25 +355,20 @@ The newly connected central and the peripheral can then communicate in a socket-
 
 When the central disconnects, the peripheral deallocates the read characteristic and puts a null value in the corresponding element of the allocator characteristic, indicating that it has capacity available for another central.
 
-#### Peer Advertisement
-
-Peer advertisement is nearly identical to the previous BLESSED section, the Bluetooth peripheral service will advertise a characteristic with a dedicated UUID representing the public mesh application.
+The full handshake as implemented in the `blessed-gatt-allocator-vuln` and `blessed-gatt-allocator-pairfix` branches is outlined below:
 
-#### Peer Discovery
+![allocator-char-diagram](uploads/b09ac8ca880e598d01bba8bb0985afe6/allocator-char-diagram.png)
 
-At its core, peer discovery is similar to the approach listed in the BLESSED section earlier. A central Bluetooth device scans for the UUID for the appropriate characteristic. However, with the added allocator characteristic, there is another method that peers can find each other. The allocator characteristic works as an active list of nearby peers, so higher level protocols could possibly utilize this as a way to further increase peer discovery and data propagation.
+#### Notes
 
-#### Peer Connectivity
+The allocator characteristic works as an active list of nearby peers, so higher level protocols could possibly utilize this as a way to further increase peer discovery and data propagation.
 
 Because each peripheral has a limited number of read characteristics, protocols built on top of this strategy should prioritize quicker, more frequent connections rather than long lasting data transfers.
 
-A central connects to a peripheral by first by reading the peripheral's allocator characteristic, and confirming it is not already reading from that peripheral. On the connection, the central gives the peripheral it's `SESSION_ID`, which is then added to the peripheral's allocator characteristic. By reading this update, the central receives information on which read characteristic to read from. The full handshake as implemented in `blessed-gatt-allocator-vuln` and `blessed-gatt-allocator-pairfix` is outlined below:
-
-![allocator-char-diagram](uploads/b09ac8ca880e598d01bba8bb0985afe6/allocator-char-diagram.png)
-
-It can be noted that this has been a GATT-only protocol so far, the reasoning behind this is that GATT has much greater support among Android devices, especially devices running older hardware. This allocator system allows for an L2CAP-like abstraction to be made on top of regular GATT reads and writes, and this abstraction could also support L2CAP (and potentially other transport layers like Local Service Discovery) under the hood for devices that support it. 
-
-#### Notes
+The allocator system allows a socket-like abstraction to be made on top of regular GATT reads and writes.
+This is useful because GATT has much greater support than L2CAP CoC among Android devices, especially older devices.
+The allocator characteristic system can be used in parallel with L2CAP CoC, by advertising the PSM of the peripheral's L2CAP server socket along with the UUID of the mesh service.
+This allows L2CAP CoC to be used between centrals and peripherals that support it, with the allocator characteristic system providing a fallback for older devices.
 
 ### BluetoothCommunicator