What could iroh plus Bluetooth Low Energy (BTLE/BLE) look like?

[b5]

We haven't looked into BTLE (bluetooth low energy) much. Our friends at https://github.com/berty/berty spent a lot of time trying to get BTLE to behave, and to be honest I don't think it was worth the amount of effort they had to put in to getting things into a workable state. I'd make a point of checking back in with the Berty team before revisiting in earnest.

The other issue with BTLE is the constricted bandwidth. Iroh is supposed to be "p2p that works", and if we were to auto-switch to a BTLE connection the max throughput of the connection drops considerably. Might be fine for some use cases, but certianly not for all.

That said, we're always interested in chat use cases & future possibilities!

[adiibanez]

Only starting with iroh so might very well be suggesting silly things.

In my usecase users will not be on the same network to start with in many situations. A secure low bandwidth p2p connection over ble could still be of great value. Specially when wifi / 4g / 5g isn't reliable for any reason ( network congestion, remote location, construction site, underground, ... ). also apple restricts any api access to eg. hotspots on ios as far as I know.

Maybe alternatives like objc2_multipeer_connectivity would be a more suitable approach at least for apple systems.
As far as I understand the underlying transport ( wifi-direct / ble ) is selected automatically by the system. So peers could end up with a ble connection anyway. Not sure how the different transports play together in practice.

eg. in the case of ditto they seem to maintain a number of ble connections as fallbacks even when higher throughput connections are available. That mechanism can also be switched off depending on mesh size / requirements. https://docs.ditto.live/sdk/latest/sync/managing-redundant-bluetooth-le-connections. Not sure on what native apis they rely and how they manage interoperability between different platforms.

Also not sure if there is any concept of modeling "transport" priority / QOS in iroh but that is what I would expect from a p2p system. protocols / routers and api clients should be able to detect and react to such degradation events. In my case only sending essential data and buffering the rest would be very valulable.

My interpretation is that "p2p that works" would definitely be more enabled by a low bandwidth local connection compared to fallback relay over the cloud. Or at the very least the endusers should have the choice. Specially in cases where the quality of that cloud connection is compromised for any reason.

What are your thoughts on such "fallback" transports?

Regarding ble I'm using btleplug crate to interface with sensors; it has multiplatform support for central role that works quite well so far. Currently looking for solutions to the peripheral role, did some poc with a unmaintained crate bluster but so far didn't have any luck with adversising services on osx. The code "works" but nothing happens.

[adiibanez]

I'm dipping my toes into the serverside "whale nodes" aspect of things. And how to approach the scenario of plenty availability in terms of connectivity.
Might be completely wrong and lack the deep understanding of some key aspects regarding iroh / p2p. But thinking about supporting "larger nodes" is when I realized that it is about managing connections based on resources that can be "spent" towards an appropriate swarming behaviour; more than following a "static" goal of a number of connections.

Being able to adjust the behaviour of a node at runtime based on external factors / events resp. a hard and concious user choice would be an interesting extension of the current "tuned for mobile" behaviour.
I like the "mindful default" approach of iroh optimized for mobile devices ... but at the end the user / application might know best what the behaviour should be towards the swarm shape and impact of fewer or more peer connections.

As far as I understand the main criteria would be:

• Maximise overall efficiency of nodes based on available resources; adapt to local circumstances
• Avoid wasting battery / data plan if those resources aren't readily available
• Avoid congestion on low bandwidth protocols or affect overall swarm performance
• Limit swarm "healing / reshuffeling" blast radius in the case of "whale nodes" going down

Potential node classes:

• Constrained, // 1-5 connections. Eg. Low-bandwidth transports( ble, uwb?, ... ), battery less than N% , memory ( embedded device ), low on prepaid credits / roaming abroad / 3G / congested wifi / ...
• Default, // 5 connections. Current behaviour without config mods, most suitable for dynamic mobile / wifi networking
• Whale/Hypernode?, // 5+, 50, ...? High bandwidth / storage capacity, 5G, always on, no constrain on battery / data plan drainage, server side, ...

[adiibanez]

Hey @flub — I just want to clarify that I didn’t mean to imply anything negative about the iroh docs. Quite the opposite: the documentation (as well as the YouTube content that actually "drawed" me into an integration ) is of very high quality — it presents deep and complex topics with some degree of compassion :) for potentially "not so much" p2p experts. really appreciated.

My current challenge isn’t the docs themselves, but more about cognitive capacity. I haven't been able to go deep into iroh yet — not due to a lack of interest or clarity, but because I’m already juggling other layers of complexity ( in particular around integrating iroh / rust and elixir, which has been a bit demanding, more than I expected ).

My focus is mostly on systems integration — making things work across browsers, mobile, servers, and bluetooth sensors — iroh might very well become a key component in that puzzle; specially because of the "just works" aspects.

I’ll definitely spend more time digging into the internals while implementing more iroh features ( currently only simplistic gossip msg ), and I’ll be happy to share feedback if anything stands out. But as of now, nothing in the docs has felt off or unclear.

One thing I would be interested is exploring or benefiting from your experiences and conclusions are actor style patterns for integrations like the one I did. Implemented in a way that play nice with iroh. Have been poking around a bit but don't have a clear strategy yet. I suspect that replacing gossip subscribe event loops could become such actors in my usecase ... but haven't engaged.

Great stuff

[flub]

Hey @flub — I just want to clarify that I didn’t mean to imply anything negative about the iroh docs.

And I didn't interpret it as such! I know our docs aren't perfect, and knowing what can improve from someone trying to understand the system is very valuable.

[adiibanez]

@flub One thing that could be extremely helpful are "simplified" state or sequence charts of the "public" iroh / iroh-gossip machinery. Anything visual.
In my case it would help a lot to understand without going too deep on the code and speeding up the process of distinguishing "internals" from things that I could / should cover as part of a FFI integration. My goal is to expose plenty of those states / events as message passing towards elixir / erlang. resp. the ones that make sense in the first place. I'm currently using "GenSevers aka Actors" on elixir side. but might switch to their FSM counterpart / extensions for some cases.

[adiibanez]

regarding potential iroh bluetooth support: This protocol ( don't know too much about it at this point ) seems to be one of the key differentiators regarding "solid" / "as good as it gets" performance in existing p2p ble mesh implementations https://www.geeksforgeeks.org/logical-link-control-and-adaptation-protocol-l2cap/

Only linux / bluez resp. embedded system based rust crates as "reference" but there definitely are other rust libs too with solid multiplatform support ( not l2cap enabled yet though, btleplug is the one I use ):

https://docs.rs/bluer/latest/bluer/l2cap/index.html
https://docs.rs/libbluetooth/latest/libbluetooth/l2cap/index.html

[adiibanez]

Would it be possible to get a highlevel overview into how iroh would be able to integrate with lower bandwidth / p2p transports? My impression is that some type of QoS / capacity concept for nodes / peers would be needed.
I'm poking around the ble / apple mpc / adhoc wifi aspects and might be able to come up with some "POC" quality entry points ( with focus on discovery / rust support / ffi aspects, not the iroh integration itself )

[luke-stdev001]

I've recently come across Jack Dorsey's git repo related to your interest in chat use-cases:
https://github.com/jackjackbits/bitchat

which supports P2P over Bluetooth Low Energy over a mesh network. Ditto, also does something like this, and supports a sort of multi-hop architecture where it can use the available protocols to find the shortest path for data (https://www.ditto.com/pricing/peer-to-peer-sync).

This would be an incredible feature for Iroh to support, especially for building features like offline-capable POS and other offline-capable web applications that can continue to communicate even without a functional network (eg. network equipment fails within a retail store, we can still support communication albeit more slowly over BT LE), or in adverse network conditions such as planes, boats, trains, remote locations where internet is patchy and sometimes unavailable and so on (contact tracing, disaster relief, restaurants, trade shows, event venues, etc. where internet is sometimes non-existent or too unreliable to rely on).

[Septias]

Would be very cool if this works for audio streaming (ad-hoc distributed silent disco where everyone can just bring their phone 😎)