Idea
Today the wifi verb provisions credentials over a bespoke BLE GATT shape — the custom 128-bit UUIDs in examples/wifi_provision. It drives that one firmware. ESP-IDF, however, ships a standard provisioning protocol (network_provisioning, formerly wifi_provisioning before IDF v6.0) built on protocomm over BLE GATT, with graded security schemes (SEC0 plaintext / SEC1 X25519+AES256-CTR+PoP / SEC2 SRP6a+AES256-GCM).
A wifi verb that could also speak protocomm would provision any standard ESP-IDF provisioning firmware in the wild — not only the bundled example. That's a meaningful reach extension for a "hands on any ESP32" tool.
Why this is parked, not built
- It duplicates a maintained upstream tool. Espressif already ships
esp_prov (official Python host provisioning tool) plus first-party phone apps. Reimplementing protocomm here is rebuilding maintained code.
- It cuts against the design. BLE verbs bind by GATT property (
runtime._pick: first writable/notify/readable), deliberately firmware-agnostic. Protocomm is the opposite — a fixed service with protobuf-framed semantics and a crypto handshake. It wouldn't compose with _pick; it'd be a separate protocol client.
- Cost is lumpy. SEC1 = X25519 + AES256-CTR; SEC2 = SRP6a (RFC 5054) + AES256-GCM — real host-side handshake crypto + protobuf framing. A subsystem, not a thin verb.
Cheap fallback if a real need appears
Shell out to esp_prov from a verb rather than port the protocol — hours, not weeks, and keeps the crypto upstream. Build this only when there's an actual need to provision third-party ESP-IDF firmware from the loop.
Trigger to revisit
Someone wants to drive a non-esp32-loop ESP-IDF provisioning firmware, or needs encrypted (SEC1/SEC2) onboarding over the air rather than the example's plaintext creds-write.
Idea
Today the
wifiverb provisions credentials over a bespoke BLE GATT shape — the custom 128-bit UUIDs inexamples/wifi_provision. It drives that one firmware. ESP-IDF, however, ships a standard provisioning protocol (network_provisioning, formerlywifi_provisioningbefore IDF v6.0) built onprotocommover BLE GATT, with graded security schemes (SEC0 plaintext / SEC1 X25519+AES256-CTR+PoP / SEC2 SRP6a+AES256-GCM).A
wifiverb that could also speak protocomm would provision any standard ESP-IDF provisioning firmware in the wild — not only the bundled example. That's a meaningful reach extension for a "hands on any ESP32" tool.Why this is parked, not built
esp_prov(official Python host provisioning tool) plus first-party phone apps. Reimplementing protocomm here is rebuilding maintained code.runtime._pick: first writable/notify/readable), deliberately firmware-agnostic. Protocomm is the opposite — a fixed service with protobuf-framed semantics and a crypto handshake. It wouldn't compose with_pick; it'd be a separate protocol client.Cheap fallback if a real need appears
Shell out to
esp_provfrom a verb rather than port the protocol — hours, not weeks, and keeps the crypto upstream. Build this only when there's an actual need to provision third-party ESP-IDF firmware from the loop.Trigger to revisit
Someone wants to drive a non-esp32-loop ESP-IDF provisioning firmware, or needs encrypted (SEC1/SEC2) onboarding over the air rather than the example's plaintext creds-write.