←back to thread

Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

(github.com)
770 points ananddtyagi | 2 comments | 07 Jul 25 00:05 UTC | HN request time: 0s | source
Show context
kragen ◴[07 Jul 25 03:53 UTC] No.44486602[source]▶
Technical whitepaper: https://github.com/jackjackbits/bitchat/blob/main/WHITEPAPER...

Presumably that is the key to getting out of the Apple ghetto.

replies(1): >>44487125 #
Tepix ◴[07 Jul 25 05:41 UTC] No.44487125[source]▶
From the whitepaper: "bitchat implements a custom mesh networking protocol over BLE"

I wonder why they didn‘t implement the BLE mesh networking standard released in 2017 by the Bluetooth SIG.

replies(1): >>44490354 #
Beretta_Vexee ◴[07 Jul 25 13:48 UTC] No.44490354[source]▶
There are already several open source implementations, but the Bluetooth SIG standard only supports flood propagation.

This is fine for managing a few hundred temperature sensors or lighting controls up to the building's floor concentrator, which is the main use case for this standard, but it is completely unsuitable for sending individual messages from user A to user B.

replies(2): >>44491766 #>>44500712 #
kragen ◴[07 Jul 25 16:07 UTC] No.44491766[source]▶
Flooding does work for sending individual messages from user A to user B at a small enough scale, but it gets progressively less efficient as the network grows, and at some level it will collapse.
replies(1): >>44498199 #
Beretta_Vexee ◴[08 Jul 25 08:36 UTC] No.44498199[source]▶
Flooding works if there is not too much hops between the sender and the recipient. For indoor IoT, it is very rare to have more than 3 hops and the data rates are extremely low and messages are just few bytes (on/off light, temperature).

It would only take 4 people at 5 hops apart trying to exchange photos of less than a megabyte to completely saturate a network of hundred devices.

replies(1): >>44505446 #
kragen ◴[09 Jul 25 01:12 UTC] No.44505446[source]▶
It depends on how often they're exchanging those photos, but it doesn't depend on the number of hops, or even the number of nodes, just the total number of publishers and the bandwidth desired by each publisher. In flooding every message gets transmitted (eventually) by every device, so the bandwidth available for the average publisher is the bandwidth of the slowest device divided by the number of publishers, regardless of how many hops or nodes there are.
replies(1): >>44509826 #
1. Beretta_Vexee ◴[09 Jul 25 13:29 UTC] No.44509826[source]▶
No, because messages have a TTL precisely to avoid continuously flooding of the entire network, or messages looping, etc. Without this, all the links would quickly become saturated, as would the caches, and the network would collapse.

Ideally, the TTL should be as low as possible in order to preserve maximum bandwidth and not hit nodes far from the transmitter.

The Bitchat documentation indicates that the maximum TTL is 7. There is also mention of gateways on the internet to enable long-distance communication.

In the case of IoT devices, their location is generally fixed and the gateway or hub is placed in the centre in order to limit the TTL, save bandwith, limit wakeup time. Some more advanced mesh network protocols use flooding only for announcements and network mapping in order to avoid this problem. This allows it to define preferred routes, set up an acknowledgement system, replay, etc.

replies(1): >>44518667 #
2. kragen ◴[10 Jul 25 08:28 UTC] No.44518667[source]▶
Not all flooding protocols have TTLs, and there are non-TTL ways to prevent messages looping in flooding protocols. Possibly what you're saying is correct specifically pertaining to Bluetooth, which I don't know anything about.