microReticulumTbeam/exercises/BLE_MAC_address_Differentiator.md

Yes. In the current dual-role BLE exercises, every T-Beam starts as both:

• a BLE peripheral/server, advertising the Reticulum BLE service
• a BLE central/client, scanning for peers

The tie-breaker is the BLE MAC address string.

In TBeamSupremeBleInterface.cpp:

return strcmp(_local_address.c_str(), peer_address.c_str()) < 0;

So the unit with the lower BLE MAC address initiates the BLE connection as the client/central. The unit with the higher BLE MAC stays available as the server/peripheral.

Sorted from lowest to highest priority by your list:

1. GUY  48:ca:43:5a:40:e0
2. ED   48:ca:43:5a:90:d0
3. CY   48:ca:43:5a:91:44
4. DAN  48:ca:43:5a:93:a0
5. FLO  48:ca:43:5b:8c:74
6. BOB  48:ca:43:5b:93:dc
7. AMY  48:ca:43:5b:bf:68

Meaning:

GUY will initiate BLE connections to everyone.
AMY will never initiate against this set; everyone else has lower priority and will connect to AMY.
BOB initiates to AMY, but stays server for GUY/ED/CY/DAN/FLO.
FLO initiates to BOB and AMY, but stays server for GUY/ED/CY/DAN.

There is also a second, similar tie-breaker for the Reticulum Link itself in main.cpp:

return strcmp(node_label.c_str(), label.c_str()) < 0;

That compares the Node-... labels. In practice those labels are derived from the ESP MAC, so the same "lower identity initiates" idea is used again after the BLE connection exists.