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.
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.
I wonder what other transports you could do, like 38khz IR through a telescope?
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.
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.
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.
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.
I'm not saying Apple doesn't profit from it, but they're not just pocketing every penny.
As for "quality", they mostly check that your app isn't using unauthorized APIs, or doing other scetchy stuff, like leeching all of your data. They couldn't care less if your app is bad, thats' between you and your potential users.
Does it work ? apparently so. Apple catches around 2 million apps every year that are rejected for those reasons. Android has about the same amount of apps, but there they're caught by Kaspersky (and others) after they're published.
That doesn't mean that malware isn't making its way through the App Store review, the damage will be somewhat limited if it can't use private APIs.
I should add that here in the EU, where we’ve had 3rd party app stores for over a year, nobody uses them. The absolutely biggest one, Epic Games, has attracted about 29 million users across both iOS and Android, out of a population of 450 million.
You don't need to because you compile it from source yourself
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
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.
IMO ultimate solution is for Apple to curate some sort open source store where they vet the source and builds "in public".
Rofl. And citation needed.
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.
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.
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.
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.
Surprised to see Jack pushing code himself. Love to see it.
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?
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.
Use case? You're in the middle of a protest. Where to next?
Hopefully, not in prison.
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)
It works best if there's 3 phones though - as it can route via the other if a link drops.
Might be more reasonable to use higher bandwidth, lower latency codecs over bluetooth as well?
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.
I wonder if there's a home lab / self hosted solution for this.
(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!
Presumably that is the key to getting out of the Apple ghetto.
I wonder why they didn‘t implement the BLE mesh networking standard released in 2017 by the Bluetooth SIG.
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?
Aside from that, most of what your concept includes (but uses Internet instead of BT) exists with Nostr+Lightning.
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.
In fairness to op, the proposed solution seems best intended for comms blackouts in densely populated areas rather than areas with persistently limited access.
I would say that the underlying issue is that people do not really "own" their devices and the corporations that do are vulnerable to (or complicit in) state coercion.
You cannot truly have freedom on a non-free device, you can just be small enough to not be worth taking action against yet.
Central node addressing control is the only way to solve it. Making it self-governing through payments is a nice idea.
Not quite the discoverable, user-friendly experience of Briar, Bitchat etc. but it can be combined with online links (Briar can technically go online, but only via Tor; both Briar and Bitchat are only for smartphones).
The thing is, it's almost impossible to guarantee payments work as expected in decentralized system, see "double spend attack". Bitcoin was designed to prevent it but does it by having common ledger which is a bit too much for a chat
Cool to see he still gets his hands dirty in code.
ChrisMarshallNY•7h ago
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.
ajr0•7h ago
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...
ChrisMarshallNY•7h ago
Backrounding is kinda klunky. I think it's deliberate, as that's a real security vector.
ckcheng•7h ago
> protocol is designed to be platform-agnostic. An Android client can be built
https://github.com/jackjackbits/bitchat?tab=readme-ov-file#a...
ChrisMarshallNY•7h ago
If I were an Android developer, though, I'd just use the Swift files as a requirements spec, and write it native.
encom•7h ago
For Apple only. In what way is this universal?
1ark•6h ago
ChrisMarshallNY•6h ago
SwiftUI apps can often do both.
I’m probably gonna rewrite my Bluetooth explorer app in SwiftUI. Doesn’t need any fancy UI.
toast0•2h ago