Replies: 1 comment
-
|
Reference implementation (BLE handoff JSON → |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
This discussion captures the maintainer stance on combining Bluetooth with
py-libp2pwithout native BLE inside the stack. It continues the thread from the former tracking issue #1290.Summary (scope: proxy / gateway)
Recommended integration: use a BLE gateway/proxy in front of
py-libp2p— not native BLE inside the stack.bleak)py-libp2phost over existing transports (TCP / QUIC / WebSocket)After handoff, negotiation, Noise/TLS, and streams use the normal libp2p path. The gateway forwards bootstrap/session material (e.g. multiaddr, peer info, short-lived tokens) to the local host.
Explicit non-goal here: first-class BLE transport inside
py-libp2p(dial/listen on BLE as a libp2p transport). That is optional future research — open a separate discussion/issue if pursued.Why
Proximity and constrained-edge connectivity matter for offline-adjacent scenarios. A gateway keeps BLE in the application/OS layer where stacks and permissions are well-supported, while
py-libp2pstays on mature transports.Prior art (lightweight)
js-libp2pdocs note proximity-style discovery (e.g. bluetooth) as not currently implemented in that productized sense.Maintainer stance
The gateway/proxy pattern is reasonable and supported as the near-term way to combine BLE with
py-libp2p.Optional follow-up (project priorities): add a short docs pointer or example sketch in this repo or in an application repo: “BLE handoff →
host.connect/ open stream using an existing multiaddr”.Reference implementation
Application-level examples (mock + optional
bleakon Raspberry Pi) and docs live in the libp2pxfilecoin project (separate repo), not inpy-libp2pcore.Former issue: #1290 (closed; content preserved here.)
Beta Was this translation helpful? Give feedback.
All reactions