Whoa this is really neat. I’ve been trying to get into Meshtastic but it’s hard to convince others when you need special hardware. Would be super neat if Apple did something similar. Shouldn’t be too hard since the AirTags use the same idea?
Would also be neat if there was a way to build a LoRA proxy to extend the range. I might give this a try with my meshtastic devices.
I think the reason AirTag works is because Apple turns it on-by-default on i-devices and people can't be bothered to go turn it off. For a chat to work on the same scale it would literally need Apple or Google to ship it as enabled-by-default on all phones.
Very nice! Could this be published in the App Store, or does it use any APIs Apple considers off-limits?
I'm regularly frustrated by modern phone's complete inabilities to allow any communication when outside of mobile network or Wi-Fi coverage, not even within the two large walled gardens.
It would be so easy for Apple to extend iMessage to work peer-to-peer, at least between people that have already messaged each other before and while both screens are on. That's literally how AirDrop works, and having to send a "Notes" text back and forth is just silly.
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.
this looks great for most use cases. most interception has been ruled out by the simple protocol for rooms, where the remaining attack appears to be just to clone the users keys, where it's more viable to attack the phones than the protocol, which is the point.
the spitball questions I would ask might be, a) how do you handle a theoretical timing attack where the time to respond to a room scan could yield whether a given device is a member of a known room, (the paralellism?) and b) does the GCM counter IV/nonce value cluster around rooms, so the counter for a given room will be in a shared range?
not dealbreakers or anything, this is simple and cool for its purpose, but design consideration wise, what's the thinking on those scenarios?
This is a really interesting app, but it is exclusive to Apple devices.
There are other alternatives for Android, like https://github.com/glodanif/BluetoothChat but it is only for close distance chatting without any network other than Bluetooth, doesn't have encryption, and is not IRC-themed.
Looks to be a little IRC-inspired with the usage/commands. Would be neat to have a lora network version, and have this run in a more of a sandbox/term environment instead of a locked-in iOS app.
Wonder how many Claude Code tokens that would take...
At first glance this seems like briar except only supports Bluetooth and is made by someone with a less than stellar privacy record. Its cool, but maybe more as a personal project of Jack's than something I'd want to use in the secure-context he's implying it'd be good at.
A bit different, as it's mainly for voice - but I made an app 'Murmur : Bluetooth Group Calls' - that lets you hold group voice calls and message via a mesh of Bluetooth LE connections. It's available on Android and iOS. https://apps.apple.com/gb/app/murmur-bluetooth-group-calls/i...
Doesn't really get any downloads, so not sure there's much demand for this - but I use it with some shokz bone conducting headphones for talking to my wife when we're cycling (also for wrangling our two small girls)
I'd guess you're not getting downloads because you're not marketing it to people who want it. You mention a few use cases at the end of the short description and that's it.
For example, this completes with motorcycle communicators such as Sena. That dedicated hardware can be over $400. If your app is as easy to use as a Sena device and you market it to bikers looking for a cheaper alternative you'll get users.
This looks really cool. I'd see it being useful as a headset to talk to camera people and others during a live stream. We already have hardware for this, but if we didn't it would be great.
For my use, I'd like to be able to join and monitor multiple groups at once (cameras, presenters, certain others individually), and select which I talk to (including being able to talk to several or all groups at once).
Another feature idea, if you are out of range, it would be good if there was an option to save the message until you come back and replay it.
Thanks! The protocol it uses does allow broadcasting to a subset of the group - I haven't hooked that up to the UI yet, but it's on the todo list (after CodedPhy and IP fallback).
Re. Messages - if you're not in range, as long as you don't leave the call, it'll send as soon as you reconnect. Messages are not currently persisted to a database though (- unsure if that's a feature or not?). I'd wanted to hold off on that until I was sure I'd covered everything I needed for the schema - they're currently encoded with ITA-2 (which is why some punctuation and emoticons go missing) - but I've made some improvements to the protocol, and intend to move to UTF-8 for broader character/language support.
The current protocol is very much designed to work around all the ways streaming audio really isn't a good fit for Bluetooth LE GATT. It does things which don't really make sense for messages, so I'm intending to separate messages from the live call.
The current focus is trying to make it play a little better with wireless headphones though. I started the app back in the days when phones had 3.5mm headphone jacks. If you've an Android phone and can use LE Audio headphones - they work much better, but wired headphones work best.
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?
You pass along a message, and get a token in return. Then, some options:
1) the message never makes it through
2) the message makes it through, via your path
3) the message makes it through, but via some other path, and yours is really a dead end
Also, how would you handle the case where multiple peers all get the message and send it through the same bottleneck node? I guess you’d want to have some incentive to widen bottlenecks, so that no nodes become important…
Planning paths in that kind of environment is impossible (literally not figuratively). Systems that achieve this are gossip broadcast systems, where messages explore every possible path, but those that don't scale well.
If you gossip/broadcast messages, the message will be copied to many nodes that end up not being involved in the actual path from source to destination. Will they still be paid for it?
If so, why shouldn't I copy each message I receive onto my 50000 Sybil devices that don't move, and get paid 50001 times what I should?
So let's assume instead that they don't get paid. That means when I receive the message I read out the path it actually took and pay those people. What if I simply don't pay those people? I could even forge a different path, maybe through my 50k Sybil devices.
I don't see a way to make it work. But nobody saw a way to make cryptographic digital currency work until Bitcoin, so maybe there's some crazy innovation that could make this work too.
If it's ever going to happen the receivers won't be getting anything. They'll just be forced to participate by Google/Apple who will run this as a system service, probably with dedicated hardware to reduce power usage impact.
For a real-world use case, maybe cruise ships? Internet service on the ships is expensive if it works at all, but that's not necessarily what people need - they just need to be able to exchange whatsapp style messages with people already on the same ship, especially if they can't find each other. Music festivals, mentioned elsewhere in this thread, might face a similar issue as they can be in remote locations.
I worked the field both academic and startup, I even made one of the first implementation of the Bundle protocol for store carry and forward (IETF transport protocol for the deep space network RFC9171).
Turns out the Mobile OS are making this kind of communication nearly impossible. To work well, it basically needs background job (automatic scan of nearby ble/wifi/radio) and automatic connection without user interaction (imagine being prompted to accept a connection every time you pass by someone), both have been basically made impossible (especially after covid).
I once saw a paper showing that if you don't mind hours of latency, and your nodes are mobile, then a network like that scales linearly with the number of nodes. So at least you won't have to worry about congestion.
(The paper was linked from internet co-inventor David Reed's open spectrum site, which appears to be gone now.)
This reminds me a little of [Scuttlebutt](https://scuttlebutt.nz) (positive it has been posted on HN before). But I think these little projects are awesome, even if they have a limited audience. Go forth!
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 ?
118 comments
[ 2.7 ms ] story [ 121 ms ] threadFrom what I can see, it's a native IOS/MacOS app (SwiftUI). I don't see an Android version.
Also seems pretty spartan, but it looks like it could be embedded in "friendlier" apps.
Would also be neat if there was a way to build a LoRA proxy to extend the range. I might give this a try with my meshtastic devices.
I'm regularly frustrated by modern phone's complete inabilities to allow any communication when outside of mobile network or Wi-Fi coverage, not even within the two large walled gardens.
It would be so easy for Apple to extend iMessage to work peer-to-peer, at least between people that have already messaged each other before and while both screens are on. That's literally how AirDrop works, and having to send a "Notes" text back and forth is just silly.
Surprised to see Jack pushing code himself. Love to see it.
Almost the whole repo is LLM generated. Look at the commits, code, structure and wording of the docs.
the spitball questions I would ask might be, a) how do you handle a theoretical timing attack where the time to respond to a room scan could yield whether a given device is a member of a known room, (the paralellism?) and b) does the GCM counter IV/nonce value cluster around rooms, so the counter for a given room will be in a shared range?
not dealbreakers or anything, this is simple and cool for its purpose, but design consideration wise, what's the thinking on those scenarios?
There are other alternatives for Android, like https://github.com/glodanif/BluetoothChat but it is only for close distance chatting without any network other than Bluetooth, doesn't have encryption, and is not IRC-themed.
Wonder how many Claude Code tokens that would take...
Am I missing something?
Use case? You're in the middle of a protest. Where to next?
Doesn't really get any downloads, so not sure there's much demand for this - but I use it with some shokz bone conducting headphones for talking to my wife when we're cycling (also for wrangling our two small girls)
For example, this completes with motorcycle communicators such as Sena. That dedicated hardware can be over $400. If your app is as easy to use as a Sena device and you market it to bikers looking for a cheaper alternative you'll get users.
For my use, I'd like to be able to join and monitor multiple groups at once (cameras, presenters, certain others individually), and select which I talk to (including being able to talk to several or all groups at once).
Another feature idea, if you are out of range, it would be good if there was an option to save the message until you come back and replay it.
Re. Messages - if you're not in range, as long as you don't leave the call, it'll send as soon as you reconnect. Messages are not currently persisted to a database though (- unsure if that's a feature or not?). I'd wanted to hold off on that until I was sure I'd covered everything I needed for the schema - they're currently encoded with ITA-2 (which is why some punctuation and emoticons go missing) - but I've made some improvements to the protocol, and intend to move to UTF-8 for broader character/language support.
The current protocol is very much designed to work around all the ways streaming audio really isn't a good fit for Bluetooth LE GATT. It does things which don't really make sense for messages, so I'm intending to separate messages from the live call.
The current focus is trying to make it play a little better with wireless headphones though. I started the app back in the days when phones had 3.5mm headphone jacks. If you've an Android phone and can use LE Audio headphones - they work much better, but wired headphones work best.
Presumably that is the key to getting out of the Apple ghetto.
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?
You pass along a message, and get a token in return. Then, some options:
1) the message never makes it through
2) the message makes it through, via your path
3) the message makes it through, but via some other path, and yours is really a dead end
Also, how would you handle the case where multiple peers all get the message and send it through the same bottleneck node? I guess you’d want to have some incentive to widen bottlenecks, so that no nodes become important…
If you gossip/broadcast messages, the message will be copied to many nodes that end up not being involved in the actual path from source to destination. Will they still be paid for it?
If so, why shouldn't I copy each message I receive onto my 50000 Sybil devices that don't move, and get paid 50001 times what I should?
So let's assume instead that they don't get paid. That means when I receive the message I read out the path it actually took and pay those people. What if I simply don't pay those people? I could even forge a different path, maybe through my 50k Sybil devices.
I don't see a way to make it work. But nobody saw a way to make cryptographic digital currency work until Bitcoin, so maybe there's some crazy innovation that could make this work too.
The Internet was a neat academic toy at one point for whatever that's worth :-)
I worked the field both academic and startup, I even made one of the first implementation of the Bundle protocol for store carry and forward (IETF transport protocol for the deep space network RFC9171).
Turns out the Mobile OS are making this kind of communication nearly impossible. To work well, it basically needs background job (automatic scan of nearby ble/wifi/radio) and automatic connection without user interaction (imagine being prompted to accept a connection every time you pass by someone), both have been basically made impossible (especially after covid).
(The paper was linked from internet co-inventor David Reed's open spectrum site, which appears to be gone now.)
Cool to see he still gets his hands dirty in code.