Live data from Hacker News

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

github.com

411–420 of 457 posts

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

#411
post #390
post #142

Earlier quoted context omitted.

I cannot imagine how that would work when there are gaps between populations, such as villages. There are so many places where you have gap of several kilometers until the next village or city. How do you plan to bridge that gap? And if someone tries and fails to send a message across such a gap, is it stored on every phone in the vicinity? That could lead to unwanted conditions (large queues, multiple delivery), whi…

There's going to be people who travel more often between the two network islands already so there's several ways you could do it. The network as a whole could track nodes who often see rarely seen nodes and navigate packets towards those 'bridge/traveller' nodes or the nodes themselves could keep track of nodes they commonly see and choose to cache more messages intended for those nodes it thinks it might reach in vi…

I think there are other difficult scenarios as well, and that you might underestimate the size of an island. There are isolated cities, e.g. Perth with 2M inhabitants, and practically nothing around it.

One option --but it might require some centralization-- is that people announce they're going to travel, and stash a bunch of messages. If the sender can provide information about the geographical destination, that could help.

About monetization: remember what money did to the internet. But the above option would practically invite some form of payment. Thinking of Perth, that would lead to a kind of "Mad Max meets Johnny Mnemnonic".

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

#412
post #402

Earlier quoted context omitted.

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.

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, regard…

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.

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

#413
post #411
post #390

Earlier quoted context omitted.

There's going to be people who travel more often between the two network islands already so there's several ways you could do it. The network as a whole could track nodes who often see rarely seen nodes and navigate packets towards those 'bridge/traveller' nodes or the nodes themselves could keep track of nodes they commonly see and choose to cache more messages intended for those nodes it thinks it might reach in vi…

I think there are other difficult scenarios as well, and that you might underestimate the size of an island. There are isolated cities, e.g. Perth with 2M inhabitants, and practically nothing around it. One option --but it might require some centralization-- is that people announce they're going to travel, and stash a bunch of messages. If the sender can provide information about the geographical destination, that co…

Building the map of what nodes are where is definitely a hard challenge and why most mesh networks have just resorted to flood broadcasting with occasional replays instead of trying to build actual routing in then adding 'mesh tunnels' over the internet like Meshtastic's use of MQTT to link geographically disparate clusters of nodes. It's better with static nodes where you don't have to constantly rebuild your routing tables but gets tough when you mix in mobile nodes and another level when you add intermittent connections like Australian cities, best solution is probably long range backhaul nodes purpose built to link those in the end.

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

#414

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 messag…

basically, a user friendly and publicly accessible variant of APRS for ham radio?

Kind of, with every node also acting as a digipeater with some logic on top to avoid messages endlessly echoing through the network.

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

#416

Earlier quoted context omitted.

I dunno, that still sounds like a perfect use case for a third-party app like the one this post is about. I'm not sure government crackdowns are a core enough experience that it needs a first-party app from Apple.

They happen regularly in the USA and Europe now.

Government shutdowns of the internet happen "regularly" in the USA? Name one time.

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

#417

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 messag…

But will hopping from device to device increase latency ? Are there any resources where offline messaging like this (eg. Bluetooth) are explained like the tech behind them ?

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

#418

Earlier quoted context omitted.

Well, there's the "Given the intended use-case, that would not work." part which very much means the payment system is in the context of the intended use case.

The full comment quoted: >I like the idea, I just don't know how to implement a robust micropayment system that does not require a lot of messages back and forth for a transaction. Given the intended use-case, that would not work. My reply is: here is the system that will work. Very simple. Keep in mind that multiple use cases and applications were mentioned, so I don’t see an issue for such an economic model to supp…

It doesn't work for this use case, as they tried to explain, as it breaks the entire point of the system as a messaging platform that doesn't require the internet.

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

#419

Earlier quoted context omitted.

How do you solve double spending?

You don't really need to. In IOU systems you extend credit to someone you know, based on ones reputation or credit score. How back in the day your local milk man would just keep a tab of what you owe. In a way everyone has something to barter: you owe the milk man, your employer owes you. Identities form a web of trust in the physical world.

But how would you eventually reconcile and settle balances?

Would all payments be just non-fungible bilateral agreements? So if I paid the milkman for some milk, but there was no good or service I could later provide to him, he would be unable to take my payment to the butcher to buy some meat (unless the butcher was also willing to enter into a new bilateral agreement with me)?

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

#420
post #402

Earlier quoted context omitted.

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, regard…

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…

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.
Post reply on HN