←back to thread

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

(github.com)
770 points ananddtyagi | 5 comments | 07 Jul 25 00:05 UTC | HN request time: 1.127s | source
Show context
halfmatthalfcat ◴[07 Jul 25 00:40 UTC] No.44485546[source]▶
Interesting try but Bluetooth LE is a non-starter when talking about building a truly decentralized mesh network at scale. The range isn’t there to build a network unless its very tight (in distance). You need sub MHz and eventually cubesats to build something robust, everything else is a toy.
replies(3): >>44485644 #>>44486559 #>>44486669 #
1. eternityforest ◴[07 Jul 25 00:56 UTC] No.44485644[source]▶
The big problem with BLE is the insane amounts of packet loss with extended advertising, even with perfect SNR many devices seem to just kind of not have the receive windows lined up right and drop 10% of packets.

The range is perfectly good for a lot of applications where one might actually want to not use the internet, just not all of them.

replies(1): >>44486624 #
2. kragen ◴[07 Jul 25 03:59 UTC] No.44486624[source]▶
Dropping 10% of packets sounds like a trivial problem to solve. That's not a range that requires fancy things like erasure coding or even SACK; it's easily handled by just retransmitting packets that don't get acknowledged.
replies(1): >>44487069 #
3. eternityforest ◴[07 Jul 25 05:31 UTC] No.44487069[source]▶
You need to track individual subscribers at that point, which uses lots of ram and could use lots of airtime, heuristics like resending until you get 1 reply like Meshtastic don't work well.

If there's receive window timing issues you can't assume two nodes right next two each other will get the same subset of packets most of the time.

My solution is just to resend every message four times, and not bother with protocol layer reliability for BLE at all, the packet rate is low and all the acknowledgements use airtime anyway.

replies(1): >>44491740 #
4. kragen ◴[07 Jul 25 16:04 UTC] No.44491740{3}[source]▶
There are scalable reliable multicast protocol designs that don't require publishers to track subscriber lists, but you're right that the approach I suggested above would require that.
replies(1): >>44506831 #
5. ◴[09 Jul 25 06:19 UTC] No.44506831{4}[source]▶