←back to thread

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

(github.com)
770 points ananddtyagi | 1 comments | 07 Jul 25 00:05 UTC | HN request time: 0.25s | source
Show context
moneywaters ◴[07 Jul 25 05:35 UTC] No.44487086[source]▶
I’ve been toying with a concept inspired by Apple’s Find My network: Imagine a decentralized, delay-tolerant messaging system where messages hop device-to-device (e.g., via Bluetooth, UWB, Wi-Fi Direct), similar to how “Find My” relays location via nearby iPhones.

Now add a twist: • Senders pay a small fee to send a message. • Relaying devices earn a micro-payment (could be tokens, sats, etc.) for carrying the message one hop further. • End-to-end encrypted, fully decentralized, optionally anonymous.

Basically, a “postal network” built on people’s phones, without needing a traditional internet connection. Works best in areas with patchy or no internet, or under censorship.

Obvious challenges: • Latency and reliability (it’s not real-time). • Abuse/spam prevention. • Power consumption and user opt-in. • Viable incentive structures.

What do you think? Is this viable? Any real-world use cases where this might be actually useful — or is it just a neat academic toy?

replies(42): >>44487111 #>>44487126 #>>44487137 #>>44487162 #>>44487174 #>>44487219 #>>44487306 #>>44487401 #>>44487416 #>>44487875 #>>44487918 #>>44487994 #>>44488076 #>>44488351 #>>44488419 #>>44488612 #>>44488911 #>>44488986 #>>44489072 #>>44489735 #>>44489867 #>>44489897 #>>44489908 #>>44490304 #>>44490306 #>>44490405 #>>44490521 #>>44490567 #>>44490746 #>>44491021 #>>44491277 #>>44491800 #>>44491846 #>>44492206 #>>44492341 #>>44493200 #>>44493256 #>>44494750 #>>44494963 #>>44499945 #>>44515267 #>>44523816 #
N19PEDL2 ◴[07 Jul 25 12:55 UTC] No.44489908[source]▶
I really like the idea and it would certainly be very useful for communicating in case of censorship or Internet outage.

However, I wonder how would the sender know how to route the message so that it gets to the correct recipient. It would have to send it to all nearby devices, which would then send it to all nearby devices, and so on, but that would be terribly inefficient; moreover, the message would continue to circulate even after the recipient received it, unless the recipient sends a receipt acknowledgement, which would then need to be propagated to all devices as well.

Apple's Find My network is not decentralized: all participating devices send the locations of objects they find to Apple's servers, which then forward the information directly to the correct recipients.

replies(1): >>44491429 #
1. wildzzz ◴[07 Jul 25 15:33 UTC] No.44491429[source]▶
Mesh networks are somewhat inefficient but there are some ways to make it better. Nodes would hold onto a short routing table of their neighbors. Depending on the activity of the network, you need to limit the number of hops a message is allowed to travel. A busy network allows only a couple hops whereas a very inactive network can handle a lot more. The message has (at least) a recipient, the payload, and a number of allowed hops. When a message is sent, nodes compare the recipient node to their list of neighbors, if the recipient is known, the message is forwarded on with the number of allowed hops set to zero. If the recipient isn't known, the message is passed to the neighbors and the number of allowed hops in the metadata is decreased by one. Those neighbors keep forwarding on the message and decreasing the number of allowed hops until it hits zero. One final transmission could be allowed when the counter hits zero on the chance that the recipient is within range but has not associated with its neighbors (helpful for a highly mobile network of nodes). As the nodes pass on the message, they include their name in the metadata to build a routing table that the recipient can now use to quickly reply directly to the original sender. This routing table can be kept in memory so that it can be reused later for any more messages nodes want to send each other. However, mesh networks are often mobile so this adhoc routing table and the list of known neighbors needs a time-to-live to ensure nodes don't waste time sending messages to a recipient that is no longer there. The TTL would be set based on whether a node is mobile or static.

Having nodes know their neighbors isn't necessarily required. It can help build a more efficient network where nodes know their neighbors and their neighbors' neighbors which can allow for a shorter number of allowed hops. If a node knows the route to get to a recipient, it can continue passing the message even if the hop counter is at zero. For example, a node in a rural area would require a couple hops to reach the edge of the city where the message is immediately passed using a known route even if the allowed hop count has run out.

But you can also build a totally blind network where nodes just pass a message until the counter hits zero. A blind network may be helpful in a contested environment where you can't trust any nodes with information beyond its own view.

If the information isn't critical, then you can hide the network even further by not requiring ACK messages from the recipient and not building a route trace in the metadata. This prevents a bad node from collecting network information.