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?
> Works best in areas with patchy or no internet, or under censorship.
The biggest problem I immediately foresee is that this sounds backwards. It doesn't work best in areas with patchy or no internet, it works best in areas with lots of participating devices. It's most needed in areas with patchy or no internet, but those areas are likely to be the opposite of the areas with lots of participating devices.
> It's most needed in areas with patchy or no internet, but those areas are likely to be the opposite of the areas with lots of participating devices.
In fairness to op, the proposed solution seems best intended for comms blackouts in densely populated areas rather than areas with persistently limited access.
Who would you pay for sending messages? That's your centralization point. Alternatively if you allow "starting balance", how would you prevent from making a lot of accounts for spam sending?
This can indeed work. The fundamental problem with mesh networks is that nodes have to behave, otherwise a malicious actor can just flood the network with undeliverable messages and/or fake nodes.
Central node addressing control is the only way to solve it. Making it self-governing through payments is a nice idea.
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)
How's the range on BLE? I was looking at this app for exactly the use case you mentioned but was curious if it worked with varying distances on bike rides
It's somewhat device dependant - but between her Pixel 6 and my Pixel 7 - if we've got line of sight and the handset's not being held to our body (so in a handlebar mount or saddle bag) - 50-75m? I've been victim to the recent Microsoft layoffs, so have a bit of time to work on it at the moment - looking at adding longer range CodedPhy support this week (though that would only be available on Android)
It works best if there's 3 phones though - as it can route via the other if a link drops.
Okay, this is neat! A true mesh networking bluetooth app- The other one that's notable, Briar is super impressive - but i think it doesn't actually have proper mesh capability due to difficulties with how devices handle things
Cool technology, but what is the usecase? I can imagine traveling abroad without a sim and using it as described. But is it any better than using the cellular network (when you have access to it)?
I possibly live more remote than you do - but mobile data isn't really a thing (in the UK at least) you can rely on continuously when you're cycling, or visiting the supermarket and you've lost your partner near the cheese aisle...
I've still got dead zones near me. If I were cycling with someone, and we wanted to chat on headsets, there's at least a few places I might ride where we'd hit dead air. If we're on different networks, then we both need coverage to communicate with cellular.
Might be more reasonable to use higher bandwidth, lower latency codecs over bluetooth as well?
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.
Legit curious what the use case would be, that would justify Apple adding it in. Like, when do you need to text someone who's within Bluetooth range but somehow has no WiFi or cell reception?
When you're at a protest and the government shuts off the internet in response to the protest. It's happening right now in Togo, has been for ten days (https://pulse.internetsociety.org/en/shutdowns/).
My eyes are opened as to how much more power the people would have if cell phones were all mesh network devices, especially as we enter a world where having a working cell phone is easier than having running water or food.
I'm not holding my breath--it would seem that keeping the people down is more profitable.
But if it happens we'll have to figure out how to write partition tolerant apps, which I think would be a lot of fun. It would also make "going viral" so much more apt, as you might catch the content from people you got physically close to.
On top of that “It would be so easy” is almost never true for a billion users network with all kinds of edge cases. Seems like a very narrow use case when there’s things missing from iMessage that could be way more appealing for a bigger group of users.
The technical details are often not the tricky part of new features. You have to integrate it into the existing app that people know and use, explain how it works, maintain it forever etc.
when do you need to text someone who's within Bluetooth range but somehow has no WiFi or cell reception?
There's no cell service or wifi at my neighborhood movie theater. If I could send her a message when she's up, I could tell my wife to bring me back a box of Sno-caps.
I've never understood this argument. Apple spends billions of dollars vetting their store for high quality apps. You can't even verify the build you get off Github was compiled from the same posted source.
As much as people want to be "leet" and run 3rd party software, it's inherently insecure and that's why Apple shuts it down.
There was a version of Apple at a point in time where I agree with your rhetoric. They have completely lost credibility to uphold that position IMO.
Apple definitely does not spend billions guaranteeing "quality". To prove my point, where does Apple even define what they consider "quality"? How can you quantify such an aubjecrive and ambiguous term?
They spend billions paying out the 70% they don't pocket.
Heck, They don't even adhere to their own HIG nor let us revert to past (objectively higher quality) versions of iOS.
This might sound crazy but some people want the freedom to use their belongings however they want instead of having artificial child locks placed on them by trillion dollar corporate daddies.
> You can't even verify the build you get off Github was compiled from the same posted source
Sure you can: build it and check the hash. If the maintainer prepared for such a check ahead of time it can be as simple as:
wget https://github.com/owner/foo-project/releases/download/.../foo
sha256sum foo # make note of this
nix build github:owner/foo-project
sha256sum result/bin/foo # it should match this
A pinky promise from a corporation can never be more trustworthy than something that we can all verify locally.
Of course there's still the should-you-trust-this-code part of the problem, but at least bad guys in that case must operate in public view, which is--once again--a stronger deterrent to shenanigans than anything that happens behind closed doors at Apple.
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'm working on a project that uses the same kind of idea as the Bluetooth tracking tags.
It's an Arduino library for mesh networking, that works over BLE and UDP, but it can also link to MQTT.
An MQTT node routes the packets it sees to the appropriate topics, and subscribes to topics for all the channels local nodes want, so you should be able to talk to anyone anywhere via the gateway.
The packet destination addresses are rolling codes, so you can't tell if someone's online just by watching their channel, at least not for more than an hour.
And there's a web app that talks directly to the public MQTT broker, and it can do chat and sensor data.
All payloads are Messagepack to make it easy to add new data types, and all packets are encrypted, authenticated, and timestamped to provide a bit of replay protection.
Everything is purely symmetric crypto, trust is left to a higher layer or something out of band, so you there's no handshakes or connection state management overhead, aside from one announce packet per hour to make the MQTT gateways work.
No LoRa, but the transports are modular and pluggable so you can easily add them. I just only have one LoRa Arduino node here so I haven't bothered writing a driver.
I'm also working on a Python port for easy pip-installable bots and home automation stuff.
Super interesting! Leaving the transport layer as modular is definitely a great choice! I like the idea of MQTT because there’s a lot of methods of serving it. I’ve been in the middle of setting up a meshtastic MQTT mode to try it out.
Once you have brought LoRa into the mix, you might as well just ask for p2p cell connectivity. Our phones could totally talk to each other over reasonable distances with no extra infrastructure.
It depends on the antenna efficiency of course, but I was surprised to discover that BLE modes around 128kbps using coded-PHY have a range extending over 1-1/2 km without a directional antenna. At 2.4ghz its line of sight, of course, but still…
Yeah, a BLE first mesh system honestly makes more sense in today's world since it's baked into every phone. In theory, a BLE to LoRA bridge should be doable with the existing meshtastic hardware like Nordic's nRF52840. The biggest caveat is going to be the data rate. Meshtastic is designed for around 200 bps (Long range mode) which vastly pales the ~2Mbps BLE expectation.
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.
Seems like people in this thread are inspired by this novel concept that isn't novel at all.
FireChat was in fact used against dictatorial governments during protests in Iraq and Hong Kong. So it fits the aspired goal for the apps suggested here perfectly, and yet still failed as a product.
I find this interesting, there was a briar app that was spoken about a few months ago that was only for android citing that iOS had issues [0] with apps running in background, wonder if/how this was solved here.
Also, I have not seen unlicense before -- guess I'm one of todays lucky 10,000
As long as it's Swift, I guess. The Protocols files seem "agnostic." I think the lower-level hardware files might need to be rewritten, though, so he's saying that an Android developer could write an app that incorporates the protocol.
If I were an Android developer, though, I'd just use the Swift files as a requirements spec, and write it native.
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.
Baseband access limitations. External RF/SDR solves for this if you’re seeking long haul RF capabilities, but admittedly requires non native/external hardware.
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.
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.
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.
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.
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?
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?
> Works best in areas with patchy or no internet, or under censorship.
The biggest problem I immediately foresee is that this sounds backwards. It doesn't work best in areas with patchy or no internet, it works best in areas with lots of participating devices. It's most needed in areas with patchy or no internet, but those areas are likely to be the opposite of the areas with lots of participating devices.
> It's most needed in areas with patchy or no internet, but those areas are likely to be the opposite of the areas with lots of participating devices.
In fairness to op, the proposed solution seems best intended for comms blackouts in densely populated areas rather than areas with persistently limited access.
Or where comms maybe blocked by governments such as during protests.
Internet don't work well in huge crowds - stadiums or mass protests. In second case govmt tend to block internet as well
If your country shuts off Internet access for demonstrations this would work great.
Areas with censorship will simply ban such services and make it a crime to participate.
Who would you pay for sending messages? That's your centralization point. Alternatively if you allow "starting balance", how would you prevent from making a lot of accounts for spam sending?
imagine building a lightning client into this.
Neat academic toy - unless you can predict why a large-scale, long-term internet outage should happen.
Aside from that, most of what your concept includes (but uses Internet instead of BT) exists with Nostr+Lightning.
Delta chat does this, without the micropayment.
Not inspired by FireChat?
This can indeed work. The fundamental problem with mesh networks is that nodes have to behave, otherwise a malicious actor can just flood the network with undeliverable messages and/or fake nodes.
Central node addressing control is the only way to solve it. Making it self-governing through payments is a nice idea.
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)
How's the range on BLE? I was looking at this app for exactly the use case you mentioned but was curious if it worked with varying distances on bike rides
It's somewhat device dependant - but between her Pixel 6 and my Pixel 7 - if we've got line of sight and the handset's not being held to our body (so in a handlebar mount or saddle bag) - 50-75m? I've been victim to the recent Microsoft layoffs, so have a bit of time to work on it at the moment - looking at adding longer range CodedPhy support this week (though that would only be available on Android)
It works best if there's 3 phones though - as it can route via the other if a link drops.
Okay, this is neat! A true mesh networking bluetooth app- The other one that's notable, Briar is super impressive - but i think it doesn't actually have proper mesh capability due to difficulties with how devices handle things
(See: https://old.reddit.com/r/Briar/comments/gxiffy/what_exactly_...
https://news.ycombinator.com/item?id=43363031 }
Anyway, -Question: I take it Murmur is end to end encrypted fully? Also, just curious if this is open source?
This could become SUPER useful- having a actual mesh networking Bluetooth app , if it's open source/E2EE!
It's AES128 encrypted with a key derived from the group password.
Cool technology, but what is the usecase? I can imagine traveling abroad without a sim and using it as described. But is it any better than using the cellular network (when you have access to it)?
I possibly live more remote than you do - but mobile data isn't really a thing (in the UK at least) you can rely on continuously when you're cycling, or visiting the supermarket and you've lost your partner near the cheese aisle...
I've still got dead zones near me. If I were cycling with someone, and we wanted to chat on headsets, there's at least a few places I might ride where we'd hit dead air. If we're on different networks, then we both need coverage to communicate with cellular.
Might be more reasonable to use higher bandwidth, lower latency codecs over bluetooth as well?
On festival sites and other crowded events, cellular sometimes gets quite saturated and slow. This might be a good alternative.
Also, I could see it as a useful tool in emergency situations. But a lot of people would need to use it to be actually useful.
Unfortunately you have generated a name collision: the server component of the Mumble VoIP is also called "Murmur", for a long time: https://en.m.wikipedia.org/wiki/Mumble_(software)
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.
Legit curious what the use case would be, that would justify Apple adding it in. Like, when do you need to text someone who's within Bluetooth range but somehow has no WiFi or cell reception?
When you're at a protest and the government shuts off the internet in response to the protest. It's happening right now in Togo, has been for ten days (https://pulse.internetsociety.org/en/shutdowns/).
My eyes are opened as to how much more power the people would have if cell phones were all mesh network devices, especially as we enter a world where having a working cell phone is easier than having running water or food.
I'm not holding my breath--it would seem that keeping the people down is more profitable.
But if it happens we'll have to figure out how to write partition tolerant apps, which I think would be a lot of fun. It would also make "going viral" so much more apt, as you might catch the content from people you got physically close to.
When would you want to peer over third party networks while a direct connection is possible?
On top of that “It would be so easy” is almost never true for a billion users network with all kinds of edge cases. Seems like a very narrow use case when there’s things missing from iMessage that could be way more appealing for a bigger group of users.
I’d agree if Airdrop, which includes offline identification via users’ address books, didn’t already exist. That seems to be by far the hardest part.
The technical details are often not the tricky part of new features. You have to integrate it into the existing app that people know and use, explain how it works, maintain it forever etc.
Airplane
I use Berkanan for just this purpose. Sometimes my partner and I don’t sit next to each other, and it’s an easy way to message.
and the reason they probably cite as why they don’t, children with no sim or wifi.
Hiking, Airplane, stadia (here in India the tower capacity get exhausted), underground metro etc
Maybe you want to have a local conversation about Winnie the Pooh?
When you're sufficiently outdoors with friends and/or family
when do you need to text someone who's within Bluetooth range but somehow has no WiFi or cell reception?
There's no cell service or wifi at my neighborhood movie theater. If I could send her a message when she's up, I could tell my wife to bring me back a box of Sno-caps.
I'd much rather Apple allow running something like this (open source) myself rather than use their "just trust me bro" store.
[dead]
I've never understood this argument. Apple spends billions of dollars vetting their store for high quality apps. You can't even verify the build you get off Github was compiled from the same posted source.
As much as people want to be "leet" and run 3rd party software, it's inherently insecure and that's why Apple shuts it down.
They shut it down because 30%.
There was a version of Apple at a point in time where I agree with your rhetoric. They have completely lost credibility to uphold that position IMO.
Apple definitely does not spend billions guaranteeing "quality". To prove my point, where does Apple even define what they consider "quality"? How can you quantify such an aubjecrive and ambiguous term?
They spend billions paying out the 70% they don't pocket.
Heck, They don't even adhere to their own HIG nor let us revert to past (objectively higher quality) versions of iOS.
Also, the store is fulfilled with _billions_ of shitty apps.
This might sound crazy but some people want the freedom to use their belongings however they want instead of having artificial child locks placed on them by trillion dollar corporate daddies.
But, sadly, as evidenced by apple’s share price, not enough people.
That’s only because there is only one alternative that is more or less equally shitty (Android) and no room for any competition whatsoever.
It’s not like people really have options to choose when it comes to choosing a smartphone.
It’s easy to have a growing share price when you are a duopoly. You don’t have to serve your users.
> You can't even verify the build you get off Github was compiled from the same posted source
Sure you can: build it and check the hash. If the maintainer prepared for such a check ahead of time it can be as simple as:
A pinky promise from a corporation can never be more trustworthy than something that we can all verify locally.Of course there's still the should-you-trust-this-code part of the problem, but at least bad guys in that case must operate in public view, which is--once again--a stronger deterrent to shenanigans than anything that happens behind closed doors at Apple.
> You can't even verify the build you get off Github was compiled from the same posted source.
You don't need to because you compile it from source yourself
You obviously build it yourself.
IMO ultimate solution is for Apple to curate some sort open source store where they vet the source and builds "in public".
FYI on X there is a TestFlight link to try it: https://x.com/jack/status/1941989435962212728
Surprised to see Jack pushing code himself. Love to see it.
Interestingly only a few commits were written by his account. Almost all were from https://github.com/nothankyou1
He doesn't use personal identifiers on any of his devices, afaik.
Is there a link to the TestFlight itself?
https://testflight.apple.com/join/QwkyFq6z
Wasn’t sure if a random TestFlight link would be safe/wise to share, so shared original source.
https://testflight.apple.com/join/QwkyFq6z
Technical whitepaper: https://github.com/jackjackbits/bitchat/blob/main/WHITEPAPER...
Presumably that is the key to getting out of the Apple ghetto.
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.
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'm working on a project that uses the same kind of idea as the Bluetooth tracking tags.
It's an Arduino library for mesh networking, that works over BLE and UDP, but it can also link to MQTT.
An MQTT node routes the packets it sees to the appropriate topics, and subscribes to topics for all the channels local nodes want, so you should be able to talk to anyone anywhere via the gateway.
The packet destination addresses are rolling codes, so you can't tell if someone's online just by watching their channel, at least not for more than an hour.
And there's a web app that talks directly to the public MQTT broker, and it can do chat and sensor data.
All payloads are Messagepack to make it easy to add new data types, and all packets are encrypted, authenticated, and timestamped to provide a bit of replay protection.
Everything is purely symmetric crypto, trust is left to a higher layer or something out of band, so you there's no handshakes or connection state management overhead, aside from one announce packet per hour to make the MQTT gateways work.
No LoRa, but the transports are modular and pluggable so you can easily add them. I just only have one LoRa Arduino node here so I haven't bothered writing a driver.
I'm also working on a Python port for easy pip-installable bots and home automation stuff.
https://github.com/EternityForest/LazyMesh#
Super interesting! Leaving the transport layer as modular is definitely a great choice! I like the idea of MQTT because there’s a lot of methods of serving it. I’ve been in the middle of setting up a meshtastic MQTT mode to try it out.
I was originally going to do OpenDHT, but that would have required building and paying to host a proxy backed for the web app.
I wonder what other transports you could do, like 38khz IR through a telescope?
Any line of sight stuff can be tough. Another one is standard 433 radio but difficult since its such a noisy environment.
Once you have brought LoRa into the mix, you might as well just ask for p2p cell connectivity. Our phones could totally talk to each other over reasonable distances with no extra infrastructure.
It depends on the antenna efficiency of course, but I was surprised to discover that BLE modes around 128kbps using coded-PHY have a range extending over 1-1/2 km without a directional antenna. At 2.4ghz its line of sight, of course, but still…
That's extremely surprising to me too. I would have expected BLE to reach a few meters, not kilometers. How can I learn more?
It'd be cool if Meshtastic's UDP mode could run over BLE like this, for local bluetooth clouds linked by just a few LoRa nodes.
Yeah, a BLE first mesh system honestly makes more sense in today's world since it's baked into every phone. In theory, a BLE to LoRA bridge should be doable with the existing meshtastic hardware like Nordic's nRF52840. The biggest caveat is going to be the data rate. Meshtastic is designed for around 200 bps (Long range mode) which vastly pales the ~2Mbps BLE expectation.
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.
Is this similar to Briar? I reckon a cool feature would be the ability to create a poll.
Use case? You're in the middle of a protest. Where to next?
Everything old is new again... Repo description reminds me of the Shortwave app from the 2010s. https://medium.com/@alonsoholmes/wtfbeacon-how-shortwave-wor...
I mentioned elsewhere: https://en.m.wikipedia.org/wiki/FireChat
Seems like people in this thread are inspired by this novel concept that isn't novel at all.
FireChat was in fact used against dictatorial governments during protests in Iraq and Hong Kong. So it fits the aspired goal for the apps suggested here perfectly, and yet still failed as a product.
Looks pretty interesting.
From 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.
I find this interesting, there was a briar app that was spoken about a few months ago that was only for android citing that iOS had issues [0] with apps running in background, wonder if/how this was solved here.
Also, I have not seen unlicense before -- guess I'm one of todays lucky 10,000
[0] https://code.briarproject.org/briar/briar/-/wikis/FAQ#will-t...
IOS/Apple Bluetooth is an interesting place.
Backrounding is kinda klunky. I think it's deliberate, as that's a real security vector.
No android but “can” be built?
> protocol is designed to be platform-agnostic. An Android client can be built
https://github.com/jackjackbits/bitchat?tab=readme-ov-file#a...
As long as it's Swift, I guess. The Protocols files seem "agnostic." I think the lower-level hardware files might need to be rewritten, though, so he's saying that an Android developer could write an app that incorporates the protocol.
If I were an Android developer, though, I'd just use the Swift files as a requirements spec, and write it native.
>Universal App
For Apple only. In what way is this universal?
It is Apple terminology for an app that supports both iPad and iPhone.
And Mac.
SwiftUI apps can often do both.
I’m probably gonna rewrite my Bluetooth explorer app in SwiftUI. Doesn’t need any fancy UI.
Hey, could be worse. A universal Windows Mobile 10 app wouldn't run on Windows Phone 8 even though WP8 had many more installed devices than WM10.
Is it Bit Chat or Bitch At?
Bitch At. Same as Bitch Ute.
I’m assuming that it’s Bitch At since with a ~30ft range you’ll be able to see who you’re bitching at
Or like the old chat client BitchX
Yes
Nice double entendre for sure.
[dead]
Depends if you're messaging your friends or your girls.
"Area Codes".
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.
Using the phone's RF modem itself would be the ideal choice. Why aren't there any userspace applications over this?
Baseband access limitations. External RF/SDR solves for this if you’re seeking long haul RF capabilities, but admittedly requires non native/external hardware.
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.
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.
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.
How about HaLow?
How does this differ from FireChat? https://en.wikipedia.org/wiki/FireChat
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...
Is this the real Jack Dorsey? I see he even has commit/push access to repos at Block
There's also https://github.com/meshenger-app/meshenger-android for generic LAN (without groups/peer discovery).
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.
Am I missing something?
why not just use meshtastic and you get longer range too?
Meshtastic requires a separate transceiver.
How easy it is to use for non-technical people?
This looks like a nerd’s tool, but I suspect we’ll start seeing more GUI-friendly versions, shortly.
More of this please. Bring back peer to peer
"Can I get your bitch at?"
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?
Is this actual programmer output or is this just what Claude gives you with a certain prompt?