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?
> 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.
The Helium Network tried something like this, but with a fixed infrastructure: People were incentivized to run Helium network nodes and could earn micropayments for running nodes and handling traffic.
It revealed a lot of problems with structures like this, such as the incentive to cheat through various loopholes that were discovered.
It also became apparent that the monetization/tokenization aspect overtook the network functionality as the primary motivator for the project. After a while, people started looking at the traffic and payouts and realized that almost nobody was using it for real communication, it had become one big shell game for collecting the payments designed to incentivize nodes to come online and relay traffic. Then the token itself had become a speculative commodity that people used for trading more than anything.
I think it would be interesting if someone could invent a stable coin cryptocurrency with low overhead that enabled some of these use cases, but it seems the allure of generating a new token that the founders can sell into a speculative market to raise funds for the project is always too alluring, so every project goes from having good intentions to becoming a veiled pump and dump. Maybe some day there will be a stable coin that escapes these issues, but I haven’t seen it yet.
> I think it would be interesting if someone could invent a stable coin cryptocurrency with low overhead
Like the US dollar and Postgres?
For like $200 anyone can start a business entity in the US with a tax ID and a bank, I’m still yet to understand how crypto is better other than for circumventing regulators
Cheating may not have helped but it was doomed to start with.
I did the math for my local city and to have full coverage you needed 5 nodes there were thousands.
Also the main customer: utilities companies would risk getting rates of transfer hiked. While startup cost would be around 500-600 to keep the control.
I legit did not know helium was intended for communication. I thought it was a way to mine crypto via the airwaves or something.
The OP's idea is an improvement: if you have to use crypto, then the only way a token is generated is when a sender buys one with fiat, so that they can transmit their message on the network.
Yes Helium was a terrible net negative for IoT protocols. It only caused a ton of very wasteful useless traffic that interfered with real purposeful networks like The Things Network. I'm glad it's mostly gone now.
Personally I think everything gets perverted when monetisation becomes the primary goal.
> 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.
First use that comes to mind is Gaza where Israel cut off power, bombed cell towers and internet cables. Something like this could help get messages out.
> 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.
Participate in the development of Reticulum. Install the app Sideband on your Smartphone or other device.
Sideband is a chat app that uses LXMF. LXMF is a messaging protocol based on Reticulum. Reticulum is a full network stack that is decentralized and transport layer agnostic.
What we need for your vision is LoRa modems integrated in our phones.
Or just a bluetooth mesh interface for Reticulum. That is a great idea. Develop that, and you have exactly what you described.
To be more specific:
Reticulum's main program is the daemon rnsd. It uses so called interfaces and can route between them (WiFi, LoRa, other radio services...).
Implement a new interface type that uses the technology called 'bluetooth mesh' and your vision is done.
> Implement a new interface type that uses the technology called 'bluetooth mesh' and your vision is done.
Reticulum supports using serial ports as interfaces, so if you get serial-over-Bluetooth working it can be done now.
One other thing I really like about Reticulum is that it also supports generic stdin/stdout to a process as an interface, so with some scripting and what not you can literally make it work over anything.
exactly! using your phone which knows when you are going to toilet, and shares that with advertisers, for "super secret communications" ? makes no sense.
I'd like to point you towards Meshtastic [1]. It's off-grid, decentralized text messaging that allows for encryption, and is inexpensive to get into (a basic node is about $30 or less), and don't require a license to operate.
The firmware on these devices is open source (minus proprietary blobs for ESP32 WiFi, etc.) and the community is active. Check the Meshmap [2] to see some nodes that have made their location public in your area.
Meshtastic barely works. There are only a few hundred nodes in Las Vegas and already the main public channels are at high utilization with almost no real end user traffic on it.
I love the project and participate, but people mentioning stuff like this in response to buzzwords irritates me. Like ipfs it is a buzzword-driven curiosity, not a real solution to real problems that anyone has.
Additionally, the meshtastic encryption is a toy. In 2025 when you say encryption you make people think of modern features like replay resistance, perfect forward secrecy, etc. Meshtastic doesn’t do any of this.
The meshtastic coverage might be much better in your area than it looks on Meshmap too. It relies on being connected to the main MQTT [0] server to get placed there and lots of people don't do that because the chatter there can be spammy and irrelevant to you locally. There are many city or state specific MQTT meshes that are far more popular. For example NCMesh [1] has way better coverage in NC, though most contacts still happen over MQTT instead of via RF, compared to the same area on Meshmap.
So long as you're using the standard long fast and 0/20 frequency slot you'll still have your messages passed via NCMesh nodes even if you're using the broader US Mesh as your MQTT server.
[0] MQTT here simply tunnels the messages over the internet so you get placed in a broader chat room and pseudomesh than you could reach through RF.
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.
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
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 is the same problem as bootstrapping a cryptocurrency. There are various ways, none very good. You could mine it with proof of work. You could distribute it widely to important figures, such as operators of big relays (as long as the internet stays up, there are going to be people sending messages inter-city through the internet instead of by plane). Perhaps you give half to big relay operators and half to their currently connected clients, that would incentivize people to get on the network early and try it out.
You could have a way to earn credits which would allow your own messages to get sent. i.e. it wouldn't be about money.
Ontop of that, I think payment isn't critical. You join the mesh because you want to use it yourself - all you need then is to limit how much power you're prepared to spend on it. What does it matter to you if 100 people use your phone or none? ....other than power.
To put it another way, I think money would introduce a commercial motive which would end up gobbling up the system like bitcoin mining.
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), which also muddle the accounting. But not doing so practically guarantees the message won't be delivered.
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 village B in the future.
It gets more complex if there's messages intended for Village C where no one from Village A visits though without some deleterious privacy impacts from needing to know what nodes see what other nodes but if the messages are relatively small you can address that with just increasing the level of optimistic caching and forwarding perhaps. Also the higher bandwidth the link the better so you can transfer more of these optimistic packets.
I'm generally against strapping a coin to this since it seems inevitably to hamper end user adoption in favor of making money for speculators and the people in the ICO. It could incentivize creating static point to point links though by providing potential revenue. Not sure that gets over the downsides of strapping a coin onto this though.
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.
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.
In a way, the Althea wireless network already does this, but it looks like a more conventional wireless ISP in some ways. If you have upstream connectivity that you provide to a downstream customer, you earn a cut. If you have access to a mountaintop or something and run a repeater that suddenly brings a lot of nodes better connectivity, you earn a cut.
Personally, I've always been surprised that traditional cellular networks didn't try to incentivize femtocell placement by awarding compensatory minutes or megs or something, to the operator of the serving femtocell. Imagine someone with an apartment over the old bakery downtown where the historical district has made it difficult to place normal towers, so they get a femtocell for their own usage. But if it carries other customers' traffic, they'd get kickbacks and incentive to place it near the window where it has the best view of the shopping area below. Suddenly they're working on RF optimization without even knowing it.
In both cases, you have an existing payment expectation that you're just piggybacking on. People already pay their ISP for connectivity, so they expect to pay Althea, and the distribution of money after that is a detail. People already pay their cellco for service, and if some of that kicks back to other customers, that's a detail.
I think your idea has legs, if you can solve the onboarding and payment expectation. There's also a critical-mass problem that Apple solved with Find My by just force-installing it on every device without consent, and you can't do that. So people will only run your software if they:
A) know about it
B) are in a place with poor enough connectivity that it's needed
C) are in a place with enough user density that it's worthwhile
D) perceive that it doesn't unduly kill their battery while in a place that also might not have a lot of opportunities to charge
That's a mighty tricky combination, especially the overlap between B and C. The only setting I can imagine is Burning Man. But micropayments directly conflict with the gifting and decommodification principles.
I think they want to run reliable networks. They might be legally required to run reliable networks. Obviously, spotty coverage in some places can't be avoided, but designing their network for exclusively spotty coverage might not be a good idea.
Remember that network operators plan their frequency allocations so that base stations on the same frequency don't also overlap in space. How would you ensure this with random femtocells? The frequency allocation plan for a femtocell relies on it having a very small area of coverage and being far away from others, so that it doesn't matter if they all use the same frequency.
Now, they could absolutely form a contract with a customer to put a proper base station in their apartment window - according to the locations and frequencies that best fulfill the needs of the network. Not just "buy one of these and plug it in for a discount" but "we'll pay you ten times over to let us fill a corner of your apartment with big metal boxes, and enter for maintenance with 24 hours notice". Evidently this is a lot of hassle compared to getting permission to put them on roofs, so they don't do it.
I assume this Althea network does something similar but with a reversed order of operations: first someone sets up a network repeater, then someone at Althea HQ figures out how much value they're providing to the network. If it's fully automated, it would run into the same problems as Helium, like people creating fake nodes to carry fake traffic (if nothing else, getting a discount on their real traffic by pretending it passed through 100 of their own nodes before reaching someone else's node).
Socially not viable since all actors that could make it happen are incentivised to actively work against this to ever happen: Governments and big tech. Where are the ad opportunities if stuff does not go to a central platform which profiles you and serves "content" with ads?
It would technologically be even pretty easy to do. There have been many attempts already, including things like roof net / freifunk. It just never works because you have very big actors against you.
Yeah I’ve wanted to build this for ages (and have tried a couple times). The use case is festivals/sporting events and other places where permanent infrastructure doesn’t really exist. The hard part is keeping messages small if you wanna include any of the token tech you’re talking about - probably, a system where your payment for usage is that you be an active relay node is more effective. Something something trust models, ala existing cert signing models.
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…
Bitcoin Lightning Network solves the routing payment problem via a series of cascading unlocks of value across the route. Nodes can change their fee policy independent of the network, so the bottleneck node could make more money in your scenario. Then those high fees attract additional nodes to provide liquidity along that route, bringing fee competition.
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.
How do I know that for device A to reach device B, I need to go through device C but not D?
And if I try to go through device D but device C actually delivers the message, then does device D get paid? How would you validate which devices actually participated in the transmission of the message? How does this not turn into a privacy nightmare?
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.
I wonder if one could run Delta Chat on top of yggmail[1] (very much an alpha software release) for a truly P2P IM chat. yggmail runs over IPv6 with a tun interface same as yggdrasil. Might test this out at some point for fun.
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).
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.
I can design such a system in a couple of minutes. As the adjacent commenter said it can be done with a blockchain, using smart contacts.
1. Sender deposits fee 2. Message includes unlocking code that itself only can be unlocked by the recipient 3. Message getting wrapped with details of forwarders while it moves between peers 4. Recipient unlocks the message via the smart contract thereby releasing the micropayments to the forwarders
Building on a a diverse transport layer of Bluetooth, UWB, and Wi-Fi Direct is incredibly astute as it would create a resilient, delay-tolerant fabric.
The model where senders pay and relayers earn is a perfectly balanced state machine, providing the exact proof-of-transit mechanism needed to prevent spam and ensure message integrity.
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 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.
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!
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).
> 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).
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 ?
“One hop further” sounds like an unbounded loose end… could you tighten this up further somehow?
Pre-allocate a larger, more worthwhile portion to do a round trip or something else more verifiable?
I've been toying with a concept for a cryptocurrency that works without internet access (like physical money) - peer to peer credit. I believe it is the only real use case for this technology.
Why does anyone need a cash incentive to pass a message silently? There is literally zero marginal cost to them to do this. Why does everything have to cost/make money?
It's very little energy, but it's literally non-zero, so definitely not "literally zero marginal cost".
Why would the user care if it's negligible? Because very-small-but-nonzero things scale very differently from actual zero things. If the price of injecting something is zero or almost zero, then this gets quickly abused and suddenly your battery drains like crazy because somebody decided that this is an excellent new vector to serve spam. So everybody will deinstall/deactivate this.
I see it as an anti-spam measure. If sending a message costs nothing I could just flood you with messages as fast as you can forward them. That's probably not okay with you. But if you get paid then it probably is okay with you.
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.
LOL, no. You can't even hear a ok quality music further than 20 metres away. Class 2 devices (smartphones) have maximum theoretical range of 30 metres with 2.4mW (4dBm).
Sena or Cardo work in 2.4 Ghz (ISM) range as well, but as a class 1 devices, which with 100mW (20 dBm), they can allow for maximum range in excess of 1 mile.
I'd use Walkie - talkies (PMR 446 MHz, about half of a mile of the range in the town) before resorting to the smartphone bluetooth. Likely only feasible on the parking.
Smartphone bluetooth is fine for two bicycles but it does NOT compete with a purpose-built hardware, especially not with the top makers like Cardo or Sena, LOL.
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
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.
Any chance it could use seamless transport switching? It would be so awesome if it could switch to cellular(if available) or wifi-direct as needed on the fly. I have been thinking about creating such an app but lacked the time.
I actually have this kind of working on a branch - really don't fancy hosting any infrastructure myself though - so I was intending it to be a Windows service or docker container you have to setup and pair with. Once you've done that - the endpoint is included in any group you create, and treated as an extra node in the graph. If available and lower latency than other routes, it'll be used.
Was trying to keep things simple though - the separate server seemed a step too far for most people I talked to about it.
I'd stayed away from WiFi Direct because Android and iOS don't play nicely with it - but looks like the EU has forced Apple to support WiFi Aware in iOS 26. It still looks like it would require A LOT of manual pairing through the system UI if you join a group with new people though. I really wanted to keep the single password (or qr code scan/NFC tap) to join.
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?
Cardo uses a similar tech for a dynamic mesh network, using Bluetooth I think, in their helmet comms. So if you are out on motorcycles or ATVs you can still talk without needing a cellular network. It makes things a lot more stable and not use any data. In these scenarios you'd struggle to talk face to face wearing helmets without some sort of comm.
So if you can remove the need to buy a specialized comm device to do it, sounds great.
I commonly Signal call my partner when we are at opposite ends of the house. I can see something like this being useful to prevent using some remote Internet server to facilitate a very local call.
I wonder if there's a home lab / self hosted solution for this.
Yeah, I think that fully explain apparent disinterest of users. No way nobody is looking for this app, but there is also no way this one shows up on searches over the other one.
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.
Looks interesting, especially that use case. May I ask which headphone you are using? I have the older openmove from shokzs and voice isn't really understandable while riding a bike.
We've got Openrun Pros - wind can be a problem, but if you cover the mics with a head band, it actually works pretty well. (To act as a crude wind muff)
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/).
This is admittedly a rare and minor use case, but maybe on a plane if you’re not sitting next to each other? Last time I flew I saw two teenage girls communicating by typing into the same note file and Airdropping it back and forth for hours - it struck me as very silly that there was no messaging interface that they could use instead.
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.
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.
This happens at festivals - despite being largely offline events, you still want to text your friends "hey I'm over at <place>", but the one rural cell that's usually empty for 362 days out of the year is getting DDoSed by 50000 people suddenly arriving one weekend.
Looks like it, at least on the README, section "Building for Production" mentions it.
I'm a bit more concerned that it is a niche application. Not having Mac myself, can't compile it without going through the hassle of getting the environment running.
It would be better if the application was built is something a bit more cross-platform, as I find the idea really good. Not sure if the "mesh network" part would work though, as you need a really high enrolled-device density in order for it to work further than just an office (it's BT after all). I guess the "Fork" button is there for a reason, or maybe a new repo with some other stack.
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.
I didn't read it like that immediately, but I noticed there was something that my brain recognized and asked me to look at it again. I wondered for a second if it could be filtered in some corporate filters (emails/servers/etc.).
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.
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…
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.
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.
FWIW, I've found a T-1000e to be a pretty good way to get people into meshtastic. It's not perfect because it has a weird dongle to charge, but it's pretty cool and I think you can convince people it's a worthwhile thing for emergency recovery.
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.
There are already several open source implementations, but the Bluetooth SIG standard only supports flood propagation.
This is fine for managing a few hundred temperature sensors or lighting controls up to the building's floor concentrator, which is the main use case for this standard, but it is completely unsuitable for sending individual messages from user A to user B.
Readit News
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?
The Helium Network tried something like this, but with a fixed infrastructure: People were incentivized to run Helium network nodes and could earn micropayments for running nodes and handling traffic.
It revealed a lot of problems with structures like this, such as the incentive to cheat through various loopholes that were discovered.
It also became apparent that the monetization/tokenization aspect overtook the network functionality as the primary motivator for the project. After a while, people started looking at the traffic and payouts and realized that almost nobody was using it for real communication, it had become one big shell game for collecting the payments designed to incentivize nodes to come online and relay traffic. Then the token itself had become a speculative commodity that people used for trading more than anything.
I think it would be interesting if someone could invent a stable coin cryptocurrency with low overhead that enabled some of these use cases, but it seems the allure of generating a new token that the founders can sell into a speculative market to raise funds for the project is always too alluring, so every project goes from having good intentions to becoming a veiled pump and dump. Maybe some day there will be a stable coin that escapes these issues, but I haven’t seen it yet.
Like the US dollar and Postgres?
For like $200 anyone can start a business entity in the US with a tax ID and a bank, I’m still yet to understand how crypto is better other than for circumventing regulators
The OP's idea is an improvement: if you have to use crypto, then the only way a token is generated is when a sender buys one with fiat, so that they can transmit their message on the network.
Personally I think everything gets perverted when monetisation becomes the primary goal.
We are thinking about this and building in this direction with Paygo.wtf
https://x.com/0x_Osprey/status/1925299005191577921
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.
Dead Comment
Participate in the development of Reticulum. Install the app Sideband on your Smartphone or other device.
Sideband is a chat app that uses LXMF. LXMF is a messaging protocol based on Reticulum. Reticulum is a full network stack that is decentralized and transport layer agnostic.
What we need for your vision is LoRa modems integrated in our phones.
Or just a bluetooth mesh interface for Reticulum. That is a great idea. Develop that, and you have exactly what you described.
To be more specific: Reticulum's main program is the daemon rnsd. It uses so called interfaces and can route between them (WiFi, LoRa, other radio services...). Implement a new interface type that uses the technology called 'bluetooth mesh' and your vision is done.
Reticulum supports using serial ports as interfaces, so if you get serial-over-Bluetooth working it can be done now.
One other thing I really like about Reticulum is that it also supports generic stdin/stdout to a process as an interface, so with some scripting and what not you can literally make it work over anything.
(YES APPLE DOES THAT TOO)
The firmware on these devices is open source (minus proprietary blobs for ESP32 WiFi, etc.) and the community is active. Check the Meshmap [2] to see some nodes that have made their location public in your area.
[1] https://meshtastic.org/ [2] https://meshmap.net/
I love the project and participate, but people mentioning stuff like this in response to buzzwords irritates me. Like ipfs it is a buzzword-driven curiosity, not a real solution to real problems that anyone has.
Additionally, the meshtastic encryption is a toy. In 2025 when you say encryption you make people think of modern features like replay resistance, perfect forward secrecy, etc. Meshtastic doesn’t do any of this.
So long as you're using the standard long fast and 0/20 frequency slot you'll still have your messages passed via NCMesh nodes even if you're using the broader US Mesh as your MQTT server.
[0] MQTT here simply tunnels the messages over the internet so you get placed in a broader chat room and pseudomesh than you could reach through RF.
[1] https://ncmesh.net/learn/#coverage
They have been around for longer and have some interesting thoughts in there.
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
Ontop of that, I think payment isn't critical. You join the mesh because you want to use it yourself - all you need then is to limit how much power you're prepared to spend on it. What does it matter to you if 100 people use your phone or none? ....other than power.
To put it another way, I think money would introduce a commercial motive which would end up gobbling up the system like bitcoin mining.
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), which also muddle the accounting. But not doing so practically guarantees the message won't be delivered.
It gets more complex if there's messages intended for Village C where no one from Village A visits though without some deleterious privacy impacts from needing to know what nodes see what other nodes but if the messages are relatively small you can address that with just increasing the level of optimistic caching and forwarding perhaps. Also the higher bandwidth the link the better so you can transfer more of these optimistic packets.
I'm generally against strapping a coin to this since it seems inevitably to hamper end user adoption in favor of making money for speculators and the people in the ICO. It could incentivize creating static point to point links though by providing potential revenue. Not sure that gets over the downsides of strapping a coin onto this though.
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.
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.
Personally, I've always been surprised that traditional cellular networks didn't try to incentivize femtocell placement by awarding compensatory minutes or megs or something, to the operator of the serving femtocell. Imagine someone with an apartment over the old bakery downtown where the historical district has made it difficult to place normal towers, so they get a femtocell for their own usage. But if it carries other customers' traffic, they'd get kickbacks and incentive to place it near the window where it has the best view of the shopping area below. Suddenly they're working on RF optimization without even knowing it.
In both cases, you have an existing payment expectation that you're just piggybacking on. People already pay their ISP for connectivity, so they expect to pay Althea, and the distribution of money after that is a detail. People already pay their cellco for service, and if some of that kicks back to other customers, that's a detail.
I think your idea has legs, if you can solve the onboarding and payment expectation. There's also a critical-mass problem that Apple solved with Find My by just force-installing it on every device without consent, and you can't do that. So people will only run your software if they:
A) know about it
B) are in a place with poor enough connectivity that it's needed
C) are in a place with enough user density that it's worthwhile
D) perceive that it doesn't unduly kill their battery while in a place that also might not have a lot of opportunities to charge
That's a mighty tricky combination, especially the overlap between B and C. The only setting I can imagine is Burning Man. But micropayments directly conflict with the gifting and decommodification principles.
Remember that network operators plan their frequency allocations so that base stations on the same frequency don't also overlap in space. How would you ensure this with random femtocells? The frequency allocation plan for a femtocell relies on it having a very small area of coverage and being far away from others, so that it doesn't matter if they all use the same frequency.
Cell networks aren't plug-and-play YOLO networks like wifi - they're properly engineered stuff.
Now, they could absolutely form a contract with a customer to put a proper base station in their apartment window - according to the locations and frequencies that best fulfill the needs of the network. Not just "buy one of these and plug it in for a discount" but "we'll pay you ten times over to let us fill a corner of your apartment with big metal boxes, and enter for maintenance with 24 hours notice". Evidently this is a lot of hassle compared to getting permission to put them on roofs, so they don't do it.
I assume this Althea network does something similar but with a reversed order of operations: first someone sets up a network repeater, then someone at Althea HQ figures out how much value they're providing to the network. If it's fully automated, it would run into the same problems as Helium, like people creating fake nodes to carry fake traffic (if nothing else, getting a discount on their real traffic by pretending it passed through 100 of their own nodes before reaching someone else's node).
Socially not viable since all actors that could make it happen are incentivised to actively work against this to ever happen: Governments and big tech. Where are the ad opportunities if stuff does not go to a central platform which profiles you and serves "content" with ads?
It would technologically be even pretty easy to do. There have been many attempts already, including things like roof net / freifunk. It just never works because you have very big actors against you.
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.
How do I know that for device A to reach device B, I need to go through device C but not D?
And if I try to go through device D but device C actually delivers the message, then does device D get paid? How would you validate which devices actually participated in the transmission of the message? How does this not turn into a privacy nightmare?
Look up "distributed peer to peer" e.g. kademlia
Timing is the key: you want to start working on it when the regular internet shows cracks.
In the meantime, build features that work in both worlds!
http://radiomesh.org
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).
1: https://github.com/neilalexander/yggmail
Aside from that, most of what your concept includes (but uses Internet instead of BT) exists with Nostr+Lightning.
Building on a a diverse transport layer of Bluetooth, UWB, and Wi-Fi Direct is incredibly astute as it would create a resilient, delay-tolerant fabric.
The model where senders pay and relayers earn is a perfectly balanced state machine, providing the exact proof-of-transit mechanism needed to prevent spam and ensure message integrity.
Ship a TestFlight beta and do a Show HN.
(The paper was linked from internet co-inventor David Reed's open spectrum site, which appears to be gone now.)
Central node addressing control is the only way to solve it. Making it self-governing through payments is a nice idea.
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).
Isn't this how some covid-specific apps work to let you know if you've come in contact with an identified carrier? https://www.gao.gov/blog/covid-19-exposure-notification-apps...
The Internet was a neat academic toy at one point for whatever that's worth :-)
It's very little energy, but it's literally non-zero, so definitely not "literally zero marginal cost".
Why would the user care if it's negligible? Because very-small-but-nonzero things scale very differently from actual zero things. If the price of injecting something is zero or almost zero, then this gets quickly abused and suddenly your battery drains like crazy because somebody decided that this is an excellent new vector to serve spam. So everybody will deinstall/deactivate this.
And that's why we can't have nice things.
Dead Comment
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.
Sena or Cardo work in 2.4 Ghz (ISM) range as well, but as a class 1 devices, which with 100mW (20 dBm), they can allow for maximum range in excess of 1 mile.
I'd use Walkie - talkies (PMR 446 MHz, about half of a mile of the range in the town) before resorting to the smartphone bluetooth. Likely only feasible on the parking.
Smartphone bluetooth is fine for two bicycles but it does NOT compete with a purpose-built hardware, especially not with the top makers like Cardo or Sena, LOL.
(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 works best if there's 3 phones though - as it can route via the other if a link drops.
If it's open source, I would love to help.
I will give your app a try.
Was trying to keep things simple though - the separate server seemed a step too far for most people I talked to about it.
Might be more reasonable to use higher bandwidth, lower latency codecs over bluetooth as well?
I wonder if there's a home lab / self hosted solution for this.
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.
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.
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.
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.
https://developer.apple.com/documentation/multipeerconnectiv...
I'm a bit more concerned that it is a niche application. Not having Mac myself, can't compile it without going through the hassle of getting the environment running.
It would be better if the application was built is something a bit more cross-platform, as I find the idea really good. Not sure if the "mesh network" part would work though, as you need a really high enrolled-device density in order for it to work further than just an office (it's BT after all). I guess the "Fork" button is there for a reason, or maybe a new repo with some other stack.
Dead Comment
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.
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.
https://blog.technitium.com/2015/05/technitium-bit-chat-rele...
I had released that 10 yrs ago lol.
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.
https://github.com/EternityForest/LazyMesh#
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.
This is fine for managing a few hundred temperature sensors or lighting controls up to the building's floor concentrator, which is the main use case for this standard, but it is completely unsuitable for sending individual messages from user A to user B.