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
Cryptocurrency transfers are irreversible, publicly verifiable and pseudonymous. For a privacy focused application, these attributes make crypto a better choice than USD and the traditional banking system.
Only pseudonymous so far as you never accidentally link yourself to a wallet then everyone can know your entire transfer/spending history. It gets people all the time just look at the investigations into various alt coin rug pulls or other fraud.
Irreversible is also not a good thing just ask anyone who had their NFTs stolen during that craze. If someone hacks my bank account or skims my card and transfers the money out the bank can reverse a lot of those transactions. Irreversibility wipes out decades of consumer protection advances.
That's not enough to get people to actually use Monero though given it's got 1/10th the transaction volume of BTC and that's just counting the directly on chain transactions for BTC not those happening on the lightning network. Being off most of the exchanges also makes it difficult for most people to consider using since it's disconnected from the normal market precisely because it's impossible to do KYC to the satisfaction of regulators.
> For a privacy focused application, these attributes make crypto a better choice than USD and the traditional banking system.
So is cash. What we really need are ways of scanning a piece of fiat currency that instantly transfers that money to an account while then disabling the physical copy from the registry as valid. That's how silly I see crypto for anything other than illicit transactions
USPS will happily exchange your cash for a money order without an ID as long as it’s under a certain amount, if you’re willing to take the risk you can mail the money order and transfer reasonably sized checks fully anonymously, there are good reasons large transfers of cash probably shouldn’t be anonymous
If you’re really paranoid, you can mail cash directly if you’re willing that risk. I’m guessing the number of grandparents sending $5 for birthdays is getting smaller, but I’ve seen first hand the number of people willing to send cash to avoid having checks/credit card charges for specific places. There is no more anonymous method of payment than cash regardless of what cryptoBros tell you. This isn’t X-files where wanting to believe is enough
> I lost ~$1,000 in a bad transfer because of a typo.
Was the option of doing a much smaller amount available to validate the account before following up with the full transfer? I've never understood not doing a test transfer first.
Advice: next time pay attention before sending, all wallets ask for confirmation prior to sending, for what is it worth. Always double check, or triple check.
I just got sent real estate documents because the sender used my uncommon firstNameLastName@ gmail, but because they had a typo of the last name it landed in my inbox.
Are we talking about cryptocurrencies? Because they are not based on e-mail.
In fact, I have no idea how your comment is relevant to losing money.
You accidentally got someone else's document. How is that relevant to losing money?
As a reminder, you said: "I lost ~$1,000 in a bad transfer because of a typo.". How can you lose ~$1,000 because of someone else's typo in which an e-mail landed in your inbox?
Handing someone a $1 is irreversible if they won't give it back. All transactions are anonymous and private when using a physical dollar. Crypto has the primary advantage of allowing you to launder money by converting the "Coin" in criminal friendly countries to a fiat currency (dollars) that actually buys stuff. Especially useful when hackers hold your data ransom. Usually what people mean by not like "traditional banking system" is unregulated/lawless.
People who don't like traditional banking system just want a system where they have more money. If they actually wanted to fix fairness etc creating a new system is not a way, you can make the old system fairer like you can make a new unfair one
The old system is a centralized one where there is one entity in charge which gets to set the level of fairness, unless you mean the meta-system whereby anyone can create a new system where they will be the dictator.
Nobody ever addresses the money laundering issue or wash trading that goes on that gives Bitcoin the illusion of liquidity.
>".... one entity in charge which gets to set the level of fairness"
Exactly what is unfair about the current system? The way we insure fairness is with laws and regulation. A system without those will suffer - well - lawlessness.
How is it centralized? The vast majority of dollars only exist as bits in computers in multiple banks all over the world. Doesn't get more distributed than that. Not only that - if you don't like dollars trade it for Euro's or Yen - you can pay your rent, mortgage and buy things with them also.
Other benefits of the current system. If someone steals my credit card I'm only on the hook for $50. My transactions are confirmed in a matter seconds pretty much anywhere in the world. I AutoPay many of my bills. If I set up automatic payments with Bitcoin I wouldn't be able to sleep at night.
There are problems that Bitcoin could help solve - it just isn't replacing currencies. I see a technology in search of a problem.
If you don't think the government is corrupt, I don't know what to tell you. You can keep on using your "fair" government currency (which the government prints by the hundred billion and gives to its billionaire friends) for everything, I'll be over here wishing for alternatives to Bitcoin.
Do you even hold significant government currency, or do you only hold the layer-2 bank currency, and stocks?
Yes my entire retirement is in "gov't currency" called US dollars and Stocks.
I asked for specific evidence or instances of corruption or unfairness. Making an accusation (gov't is corrupt) without evidence or example and saying something is true repeatedly is not a substitute for actual evidence. There are many documented cases of money laundering and wash trades with Bitcoin. These same activities are done using fiat currencies, but in the US at least BT (before Trump), they were illegal and people doing it were subject to criminal investigation. I do agree that there are many gov't policies that have lead to inequities in the distribution of the money that should be addressed.
Bitcoin will only make a fixed number of Bitcoins but they forked Bitcoins into 2 separate coins years ago which some might consider as printing more Bitcoin since everyone got a copy of their existing coins. New ShitCoins are minted to scam people on a regular basis. If anything the barriers to printing too much money are lower with Crypto because it is so easy to make a new coin type. Have you invested in any NFT's lately? What about coin front running? [0]
Thinking Crypto is not subject to corruption is very naive.
>"If you don't think the government is corrupt, I don't know what to tell you. "
If you cannot explain of give examples then I have to assume you don't really know - it is your opinion. I am sure people living in certain deeply corrupt countries - Russia comes to mind - like Bitcoin because their countries currencies are unstable and access to other currencies is limited. That said the reason they like it is BC can be exchanged for stable currencies to buy things. If those stable currencies did not exist BC would be useless for them also.
Circumventing regulations is like half the point of crypto... either you use it to circumvent regulators, or you hold it while the price goes up because of the people who are circumventing regulators.
I think Bitcoin has become a typical fiat asset ouroboros now, because the people who actually want to circumvent regulators are using Monero (which is why Monero is banned in most countries), while the Bitcoin price is supported almost entirely by speculation and a little bit by people doing only-slightly-shady things with crypto who haven't noticed everyone else moved to Monero.
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.
It's the same scheme. You had to purchase Data Credits to send on Helium too, there was no input revenue because no one was choosing to use it but it's largely the same as the scheme behind the Helium network. 1 DC/24 Bytes sent and successfully delivered.
> 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.
I guess it depends on the authoritarian government, but a sufficiently powerful one will get the app taken down or get the bluetooth features it relies on disabled (like for airdrop in China) :/
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.
Indeed! Advanced countries will and have blocked apps.
For a more extensive discussion on censorship resilient mesh networking, see IETF Internet Standard draft from 2012 [1]. After the Arab Spring there was global hope. Great to see revival of this topic today. Mesh networking is 1990s. The lesson from decades ago was that mesh networking can't be the killer use-case. Users need a reason to install this and allow it to drain the battery while looking for nearby nodes. Mesh networking never broke through the glass ceiling.
Blocking apps is real. Even Amazon killed a side-loaded app [2].
Yeah the change they made was to auto shut off airdrop after 10 mins. It's just that it happened to roll out in China around the same time that many apps were banned and protesters were reported as using airdrop to pass messages.
But I mostly agree - they rolled it out worldwide later on because once you reason it through, disabling it when it's not actively used turns out to be the better default.
But it would only really work well in a small area, such as a couple friends communicating at a demonstration, where there are a lot of people who may be motivated to participate in a particular area.
If there is a low density area between two people, a message could take a long time to show up. A message from NYC to LA is effectively relying on the messaging being cached on a phone in NYC, that person flying to LA, and then continuing the journey.
Though demonstration organizers could run around with QR codes making it easy for everybody to install the right app to communicate with each other during the demonstration. As long as people can side-load things on their phones, this should be possible without any way to stop it unless you deploy radio jammers. (Which is then the logical next step for police equipment in so minded states.)
Yeah, I used an older version of a bluetooth messaging app like this. We wish it had been available in the times of Tahrir Square, but it was actually helpfull onetime when my bus stopped at a rural Ethiopian bus stop, my girlfriend ran into the bathroom but was taking too long and I was able to warn her that the bus was getting ready to leave.
Wireless internet is getting better, but when you really need something like this, you really need it.
Nation states can use the baseband radios to track/monitor you, so it's best to leave your phone at home. You can't disable or observe baseband from the higher level OS.
FWIW what people call "baseband" in the context of this particular security flaw is what everyone (including those people) call "cellular modem" in every other context.
On a Pinephone you can turn it off with a physical power switch.
If you really wanted to, on most other phones you could desolder it and throw it in the garbage. You'd need to already have custom firmware on the main CPU (or should I say "application processor" to fit in with the people who say "baseband processor") so it wouldn't crash or lock up when booting.
A little bit less destructive (in case you want to use your cellphone as a cellphone later) would be replacing the antenna with a dummy load.
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.
I don't think this is relevant. Free communication of people is the last thing regimes like those that govern Gaza need. My money on that local authorities will literally execute people for simply having such apps on their phones.
By "regimes that govern Gaza" I presume you're talking about Likud? They are the ones dropping bombs, but they don't have boots on the ground, so they can't inspect everyone's cellphone and catch people for having the wrong apps installed.
> 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.
Yes, you could have a peer-to-peer connection with bluetooth as the transport layer.
But that's not the vision. The vision is an out-of-the-box bluetooth mesh network, like what you have when you connect to an IP network with Reticulum.
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.
IPFS used to be a real solution, we used it as the base layer for the decentralized marketplace OpenBazaar and it worked fairly well for that. I haven’t followed it in a few years though.
I think of IPFS as a cross between HTTP and BitTorrent. Like BitTorrent it can seek a given dataset by some kind of hash, no matter where it's hosted; like HTTP it's more suitable for collections of small files.
In practice, it takes upwards of a whole minute to locate a file it's never seen before, so it's not terribly useful. It's better than nothing, but it's not terribly useful.
It's still cool that someone tried. IPFS is one in a long line of ideas that didn't really work. Occasionally some of these ideas have massive success, like the Internet, and Bitcoin.
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 think that money would only be used to send messages, as a way to prevent excessive spam. There needs to be some limitation. In whatsapp it's unique number or phones. Once you send too much spam from one number, it's burned. If you have anonymous network, how do you otherwise prevent from making new accounts for sending spam? If it is invite-only network, then it's pretty small problem.
I don't think relaying messages would require that much power and as you said, "You join the mesh because you want to use it yourself".
LN is an onion routed network, and has some privacy - notably, sender privacy, as the sender does not need to be known to the recipient. The recipient however is not private, but there have been proposals for rendevouz routing which could also anonymize them.
LN payments are based on Sphinx[1], but they don't leverage the full capabilities of it. Sphinx only allows for single-use replies.
The proposals for bidirectional anonymity involve using HORNET[2], which builds on Sphinx (specifically, it uses Sphinx's single-reply message to establish a HORNET connection), and enables sender-receiver anonymity and bidirectional transfer beyond single-reply messages.
It has also been proposed to include the use of TARANET[3] to prevent deanymization via traffic analysis.
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 think there are other difficult scenarios as well, and that you might underestimate the size of an island. There are isolated cities, e.g. Perth with 2M inhabitants, and practically nothing around it.
One option --but it might require some centralization-- is that people announce they're going to travel, and stash a bunch of messages. If the sender can provide information about the geographical destination, that could help.
About monetization: remember what money did to the internet. But the above option would practically invite some form of payment. Thinking of Perth, that would lead to a kind of "Mad Max meets Johnny Mnemnonic".
Building the map of what nodes are where is definitely a hard challenge and why most mesh networks have just resorted to flood broadcasting with occasional replays instead of trying to build actual routing in then adding 'mesh tunnels' over the internet like Meshtastic's use of MQTT to link geographically disparate clusters of nodes. It's better with static nodes where you don't have to constantly rebuild your routing tables but gets tough when you mix in mobile nodes and another level when you add intermittent connections like Australian cities, best solution is probably long range backhaul nodes purpose built to link those in the end.
I'd recommend building simulations before you spend time on implementing any strategy. You could also looks up random graph theory. There might be some usable results wrt. connectivity.
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.
Bitcoin Lightning requires realtime communication with every node in the route. If you can communicate with enough nodes to negotiate passing a message, you could also just send the message.
So painful when people recommend bitcoin lightning. Its technically interesting... but complete nonsense to pay like $50 just for one "hop" of the payment chain. It would be an upfront cost of hundreds to get a payment chain you planned on spending fractions of a penny per day/week/month
Hm? As I understood it, you lock up some money, and then secretly agree to reallocate it with the Lightning protocol, and then eventually get it back in the latest allocation. So it costs $50 and then you get $50 back - or $60 or $40.
This is an interesting thing when financial institutions do it between themselves. It's completely useless as a consumer-facing payment system. Consumers aren't going to plan in advance how much money to lock up, that's just stupid.
I assume you're not referring to the transaction fee because last I heard, it's not currently $25.
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).
Delta Chat can already run on top of iroh [0]. No need to find some other server implementation - it can already do "truly" P2P - devices can end up running their own STUN and TURN servers, etc.
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
The central smart contract is on the blockchain and can only be used if the internet is up. That's why you haven't solved anything here.
Your proposal is that since Alice and Bob can't communicate in real-time, either directly or indirectly, Alice does an interaction with a smart contract to lock some value and then Bob does an interaction with the same smart contract to unlock some value.
We can view the smart contract as some shared algorithm between Alice and Bob (if they are running their own nodes) or we can view it as something outside of them both (perhaps they are RPC customers of Infura). If Alice and Bob are running their own nodes, however those nodes manage to communicate with each other is a way they could just send the message to each other and not need a blockchain. And if they're both able to communicate with Infura, they could also swap Infura for Gmail and send each other a message the normal way (or if they can really only reach Infura for some reason, they can put their messages on the blockchain). But we are talking about designing systems that can work in scenarios where direct communication like this is impossible, and messages have to be forwarded hop-by-hop over a span of hours. You can't design a system for slow networking, that assumes the existence of a separate fast network just to run the payment system.
All nodes running a blockchain have to be in low-latency contact with each other. If you try to run Bitcoin in a network with multi-hour latency, you'll never reach consensus on which blocks are in the chain. You'll be hard-forking all over the place. You'd have to slow it down to, like, one block per week, but then it's far too slow to be useful for payments.
If a blockchain exists in such an environment, it exists on a tightly-coupled cluster of nearby nodes. And that cluster is pretty much the same as a single central node, from the perspective of the network. You don't gain anything by making it a cluster (except for redundancy, as usual).
More familiar than you can imagine. The fact that you think smart contracts are what are needed to solve a decentralized communications problem suggests that you've learnt a new hammer and everything now looks like a nail to you.
Please check the parent comment which I replied to, this is a solution to “how to implement a robust micropayment system” in this context, not how to solve a “decentralized communications problem”.
Well, there's the "Given the intended use-case, that would not work." part which very much means the payment system is in the context of the intended use case.
>I like the idea, I just don't know how to implement a robust micropayment system that does not require a lot of messages back and forth for a transaction. Given the intended use-case, that would not work.
My reply is: here is the system that will work. Very simple. Keep in mind that multiple use cases and applications were mentioned, so I don’t see an issue for such an economic model to support at least some of the use cases.
It doesn't work for this use case, as they tried to explain, as it breaks the entire point of the system as a messaging platform that doesn't require the internet.
The message is encrypted in layers, with each forwarder only able to decrypt their part (like an onion).
As the message is forwarded peer-to-peer, each forwarder appends some kind of proof-of-forwarding.
When the recipient finally receives and decrypts the message, they unlock the contract using a code embedded in the message. This triggers micropayments to all the forwarders.
Do forwarders need to interact with the blockchain (i.e., create/update a smart contract) when forwarding?
If so, wouldn’t that require each forwarder to have internet access at the time of forwarding—which breaks the idea of fully offline Bluetooth relaying?
Or is all the blockchain interaction deferred to the recipient, who proves the path the message took and triggers all payments at once?
How relevant is this in the context of the mesh networks under discussion?
How resilient are those protocols to attacks on the integrity of the network, when most (or signicant part) of the nodes are controlled by a bad actor and deliberately operate in a mode that prevents the functioning of the network?
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.)
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 ?
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).
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.
“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.
You don't really need to. In IOU systems you extend credit to someone you know, based on ones reputation or credit score. How back in the day your local milk man would just keep a tab of what you owe.
In a way everyone has something to barter: you owe the milk man, your employer owes you. Identities form a web of trust in the physical world.
But how would you eventually reconcile and settle balances?
Would all payments be just non-fungible bilateral agreements? So if I paid the milkman for some milk, but there was no good or service I could later provide to him, he would be unable to take my payment to the butcher to buy some meat (unless the butcher was also willing to enter into a new bilateral agreement with me)?
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.
Bluetooth LE which most smartphones support today is quite a bit different from Bluetooth classic. It typically runs at 1 or 2 Mbps and can trade bandwidth for error correction to get some impressive range. For example, this guy got 1.6 miles at 8dbm transmission power. https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/pos...
The audio codec on ble is more modern too.
> “You can't even hear a ok quality music further than 20 metres away”
That smells like the SBC codec running on Bluetooth classic to me. Very different tech.
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.
This sounds perfect for my use case. I'm a mountain biker who doesn't mind setting up hosting infra. It's fairly common when mountain biking to unintentionally get separated by line-of-sight or more than 75M even among very similarly skilled riders. Even on straight easy trails, just the dust cloud generated by the rider ahead can cause you to back off significant distance if it's dusty.
I've used these[0] in the past and they worked ok. I lost the pair I bought when traveling and thought using the plethora of radios I have with me anyway on my phone with an earbud headphone would be much better replacement. Would be great for group rides to just send an app link instead of suggesting they all buy $100 hardware.
Honestly I think a well marketed and polished commercial app would have both Sena and Cardo[1] both quite existentially scared.
App will be held down by the hardware. Smartphones are not meant to transmit with the necessary power, and you also don't get direct access to the radio, so you can't run custom protocols like Sena/Cardo, but you must transmit over the actual bluetooth or actual WiFi.
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...
In most of the supermarkets down here, couple of miles from M25. I mean, outside, so its probably considered third-world country, but no, no need to reduce the argument ad absurdum.
Or 2 metres from the window a mile from Hammersmith. If not for WiFi calling I'd have to leave my phones on the windowsill.
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.
You can't. Smartphones are Class 2 devices (weak), and you must use radio the way firmware let's you.
Purpose-built hardware is Class 1 (much stronger, 100 mW/20dBm vs 2.4mW/4dBm), and they can use sophisticated protocols to keep the connection stable. And that's Bluetooth.
If they're not playing Bluetooth but go general ISM, they can emit whole 1W on 2.4GHz or 915 MHz.
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.
You can do a surprising amount with a low throughput connection though. I've been playing with Google's Lyra V2 codec - it chews up a fair bit of CPU, but 3.2kbps over a CodedPhy link sounds fine.
When I last had a university workshop where 20 people in a room worked on a bluetooth protocol I also noticed bluetooth is quickly saturated with many participants. Hopefully that changed in the last 15 years since...
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.
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.
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/).
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.
I dunno, that still sounds like a perfect use case for a third-party app like the one this post is about. I'm not sure government crackdowns are a core enough experience that it needs a first-party app from Apple.
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.
I dunno, I bet if it was widespread people could come up with applications. Like, telling people doesn’t necessarily leave a record, so you could talk about tomorrow’s plans and then send a summary text so everyone has a record and all the details.
“Coded PHY” Bluetooth has a range of up to a kilometer! Once you add mesh forwarding, you could probably cover quite some distance on moderately busy hikes.
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.
“With iOS xx, now you can message your loved ones even without any cell or Wi-Fi signal from up to a mile away! Simply make sure you already have an iMessage conversation with them started while you still have signal.”
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.
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.
The 30% also covers refunds, legal stuff (not stuff IN your app, but regarding the sale of it), taxes, GDPR and much more.
The infrastructure running the app store probably also isn't cheap.
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 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.
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.
I could answer "iOS may be shitty but it doesn't phone home every touch and your health data stays local". I really don't want to argue abour iOs vs Android. I used both. They are both shit made to lock their users in an ecosystem that solely benefits Google or Apple. I really couldnt care more about arguing which is worse, I would just want the market to allow something better than both for me, the user.
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.
Flooding does work for sending individual messages from user A to user B at a small enough scale, but it gets progressively less efficient as the network grows, and at some level it will collapse.
Flooding works if there is not too much hops between the sender and the recipient. For indoor IoT, it is very rare to have more than 3 hops and the data rates are extremely low and messages are just few bytes (on/off light, temperature).
It would only take 4 people at 5 hops apart trying to exchange photos of less than a megabyte to completely saturate a network of hundred devices.
It depends on how often they're exchanging those photos, but it doesn't depend on the number of hops, or even the number of nodes, just the total number of publishers and the bandwidth desired by each publisher. In flooding every message gets transmitted (eventually) by every device, so the bandwidth available for the average publisher is the bandwidth of the slowest device divided by the number of publishers, regardless of how many hops or nodes there are.
No, because messages have a TTL precisely to avoid continuously flooding of the entire network, or messages looping, etc. Without this, all the links would quickly become saturated, as would the caches, and the network would collapse.
Ideally, the TTL should be as low as possible in order to preserve maximum bandwidth and not hit nodes far from the transmitter.
The Bitchat documentation indicates that the maximum TTL is 7. There is also mention of gateways on the internet to enable long-distance communication.
In the case of IoT devices, their location is generally fixed and the gateway or hub is placed in the centre in order to limit the TTL, save bandwith, limit wakeup time. Some more advanced mesh network protocols use flooding only for announcements and network mapping in order to avoid this problem. This allows it to define preferred routes, set up an acknowledgement system, replay, etc.
Not all flooding protocols have TTLs, and there are non-TTL ways to prevent messages looping in flooding protocols. Possibly what you're saying is correct specifically pertaining to Bluetooth, which I don't know anything about.
Interesting. I looked at https://www.bluetooth.com/mesh-directed-forwarding/ and it seems like "Bluetooth Mesh Directed Forwarding" is an improvement over "Bluetooth Mesh Managed Flooding" for this scenario? It got added in v1.1 of the spec.
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.
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.
As much as I like the idea of people working on peer-to-peer networks, delay tolerant network, if I'm within Bluetooth range, it's quicker to chat with the person I'm talking to than to go through a messaging app.
That technology is interesting, but it is probably not a good usecase. There are potentially lots of interesting things you could do with smart watches and bike computers, such as uploading activities without direct connection to a phone or sharing routes with nearby participants, etc.
Use cases where you may not necessarily have a phone or adequate network coverage.
We can communicate in more ways than just with words. Would be great to FINALLY have a sensible, low-friction, secure way to transfer files to people. It's 2025 and that's still not a solved problem.
You probably don't need a decentralised, delay-tolerant network to send a photo to the person in front of you.
It's even very likely that this will be much less efficient than a direct Wi-Fi or Bluetooth connection or an AirDrop.
What would be the use case? Send the picture to someone at the other end of the lecture theatre? It's likely that there would be a phone network or Wi-Fi available.
A crisis or emergency situation where networks are down? There isn't much population density or movement to propagate the data.
This debate is not new, many teams have worked on wireless ad hoc networks, some with very encouraging results. The real problem is what the use cases are.
That's why I personally think that the use case should be related to travel, transport, sport or vehicle-to-vehicle communication. Situations involving movement and loss of connectivity.
> Send the picture to someone at the other end of the lecture theatre? It's likely that there would be a phone network or Wi-Fi available.
Now you're back to using a centralised system using a network you know nothing about, operated by someone you don't know.
> direct Wi-Fi or Bluetooth connection or an AirDrop
AirDrop is not cross platform AFAIK. Direct wifi or bluetooth aren't the easiest to work with for non-technical users.
> A crisis or emergency situation where networks are down? There isn't much population density or movement to propagate the data.
Why not? Do emergencies only occur when people are few and far between? I think I'm misunderstanding what you're saying.
> That's why I personally think that the use case should be related to travel, transport, sport or vehicle-to-vehicle communication. Situations involving movement and loss of connectivity.
That's certainly a valuable use case, but probably not something that bitchat would be useful for.
the use case is really decentralized communication. sure connecting to wifi is easy and accessible, 4g is pretty much unlimited, but what if you just want to share files/photos directly with a group of people without having to traverse the web/someone else's hw/sw? this is basically like a detached, private web. most of the time, you probably dont care if meta has your files, but for those that just dont like centralized services, this is great. think of it like an extremely private network, why not?
I'm not against the idea, but it has already been tested with Firechat, Bridgefy, etc. during the protests in Hong Kong in 2019.
It doesn't work very well from a technical and practical point of view. Just having the app on your phone could be enough to get you charged in a totalitarian state.
So it's interesting, but it's not the use case that will democratise this type of ad-hoc network. For example, it is easier to implement end-to-end encryption on an existing infrastructure.
There must be a use case where there is no network connection, enough network participants, and that can accommodate a significant transmission delay.
You don't need to be close to send a message, just close to someone on the network so you can connect, the message will be relayed hoping through the network
This is something I've wanted for ages. I go to some event with the family - in London for example or to an airshow - and there's a huge crowd for one reason or another which overloads the mobile network and makes your phone useless. You can lose people who are just a few metres away.
I am glad it's public domain - I don't think I really want to invest any effort in getting non-techy people to try and use something that might go away one day and be irreplacable. OTOH, I need Android as well so....
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.
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've tried a couple of apps like that with use case of communicating during festivals with next-to-none wifi/cell service with a big group of people. None of them worked.
Fingers crossed for this one
Boggles my mind how we all have cellphones capable of forming a massive (global?) wireless mesh network that can't be shutoff/censored (without jamming). Get rid of ISPs.
Get rid of all these garbage social media (government honeypots) platforms that leak all your data every other weak.
Use Zero-knowledge proofs for authentication into distributed web apps.
Use BitTorrent file system to distribute data to prevent a single point of failure where all your data is leaked.
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.
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.
There are scalable reliable multicast protocol designs that don't require publishers to track subscriber lists, but you're right that the approach I suggested above would require that.
Baseband access limitations. External RF/SDR solves for this if you’re seeking long haul RF capabilities, but admittedly requires non native/external hardware.
this looks great for most use cases. most interception has been ruled out by the simple protocol for rooms, where the remaining attack appears to be just to clone the users keys, where it's more viable to attack the phones than the protocol, which is the point.
the spitball questions I would ask might be, a) how do you handle a theoretical timing attack where the time to respond to a room scan could yield whether a given device is a member of a known room, (the paralellism?) and b) does the GCM counter IV/nonce value cluster around rooms, so the counter for a given room will be in a shared range?
not dealbreakers or anything, this is simple and cool for its purpose, but design consideration wise, what's the thinking on those scenarios?
This is my very youth toy project that never came to be, always dreamed of something this local when I used to be more at festivals as an introvert and stuff, good times, and awesome to see someone actually was able to pull it of.
My wife and I have been using Berkanan (an iOS app) for many years for this purpose. It's not very good - unlike literally every other chat app, it presents conversations in reverse chronological order, and the interface is janky. But it gets the job done when there's no WiFi (airplanes, though this is becoming less of a problem) or cell service (crowded venues).
I really don't see the relevance of this app. We already know that Bluetooth (BLE) is short range.... so is this equivalent to speaking to people a hundred feet away from you in an encrypted manner? So use case is only for protests I assume?
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...
Why Bluetooth which has pretty bad range when most phones have a wifi module built in? Is there not a mode on the module that could function similarly?
Very cool, I've often thought that such a short-range chat would be fun on an airplane. Not practical, but it could be neat to chat with the group in the air.
hope this does well. We see people trying again and again like FireChat or Berty it seems that it works for a bit with some devices but then Apple & Google make updates and the app dies.
In general mobile app development seems to be very maintanence heavy
This particular application isn't, but at the end of the README you get a section on how to port to Android, and the protocol is open as well. So it's a matter of investing the effort on your side.
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
Cryptocurrency transfers are irreversible, publicly verifiable and pseudonymous. For a privacy focused application, these attributes make crypto a better choice than USD and the traditional banking system.
Only pseudonymous so far as you never accidentally link yourself to a wallet then everyone can know your entire transfer/spending history. It gets people all the time just look at the investigations into various alt coin rug pulls or other fraud.
Irreversible is also not a good thing just ask anyone who had their NFTs stolen during that craze. If someone hacks my bank account or skims my card and transfers the money out the bank can reverse a lot of those transactions. Irreversibility wipes out decades of consumer protection advances.
> Only pseudonymous so far as you never accidentally link yourself to a wallet then everyone can know your entire transfer/spending history
See Monero
That's not enough to get people to actually use Monero though given it's got 1/10th the transaction volume of BTC and that's just counting the directly on chain transactions for BTC not those happening on the lightning network. Being off most of the exchanges also makes it difficult for most people to consider using since it's disconnected from the normal market precisely because it's impossible to do KYC to the satisfaction of regulators.
> For a privacy focused application, these attributes make crypto a better choice than USD and the traditional banking system.
So is cash. What we really need are ways of scanning a piece of fiat currency that instantly transfers that money to an account while then disabling the physical copy from the registry as valid. That's how silly I see crypto for anything other than illicit transactions
USPS will happily exchange your cash for a money order without an ID as long as it’s under a certain amount, if you’re willing to take the risk you can mail the money order and transfer reasonably sized checks fully anonymously, there are good reasons large transfers of cash probably shouldn’t be anonymous
If you’re really paranoid, you can mail cash directly if you’re willing that risk. I’m guessing the number of grandparents sending $5 for birthdays is getting smaller, but I’ve seen first hand the number of people willing to send cash to avoid having checks/credit card charges for specific places. There is no more anonymous method of payment than cash regardless of what cryptoBros tell you. This isn’t X-files where wanting to believe is enough
>There is no more anonymous method of payment than cash
Very much depends. Cameras, fingerprints, banknote ids, cell tower/GPS or just people seeing you.
How?
Irreversible is bad because mistakes happen. I lost ~$1,000 in a bad transfer because of a typo.
Publicly verifiable -- not good because I don't want the public knowing what I buy.
Pseudonymous is the worst of both. Is it or is it not me? them?
I am thinking digital cash using pub keys on a network run from space on something like starlink sats.
> I lost ~$1,000 in a bad transfer because of a typo.
Was the option of doing a much smaller amount available to validate the account before following up with the full transfer? I've never understood not doing a test transfer first.
You can still make a mistake after the test transfer.
Or you can mistakenly think the test transfer worked as intended.
Not to mention that the necessity of "do a test transfer" already shows how massively broken the process is
Or maybe that "broken" design is just the result of the actual goal of decentralized P2P...
Advice: next time pay attention before sending, all wallets ask for confirmation prior to sending, for what is it worth. Always double check, or triple check.
and then what?
I just got sent real estate documents because the sender used my uncommon firstNameLastName@ gmail, but because they had a typo of the last name it landed in my inbox.
Are we talking about cryptocurrencies? Because they are not based on e-mail.
In fact, I have no idea how your comment is relevant to losing money.
You accidentally got someone else's document. How is that relevant to losing money?
As a reminder, you said: "I lost ~$1,000 in a bad transfer because of a typo.". How can you lose ~$1,000 because of someone else's typo in which an e-mail landed in your inbox?
[flagged]
Handing someone a $1 is irreversible if they won't give it back. All transactions are anonymous and private when using a physical dollar. Crypto has the primary advantage of allowing you to launder money by converting the "Coin" in criminal friendly countries to a fiat currency (dollars) that actually buys stuff. Especially useful when hackers hold your data ransom. Usually what people mean by not like "traditional banking system" is unregulated/lawless.
People who don't like traditional banking system just want a system where they have more money. If they actually wanted to fix fairness etc creating a new system is not a way, you can make the old system fairer like you can make a new unfair one
The old system is a centralized one where there is one entity in charge which gets to set the level of fairness, unless you mean the meta-system whereby anyone can create a new system where they will be the dictator.
Nobody ever addresses the money laundering issue or wash trading that goes on that gives Bitcoin the illusion of liquidity.
>".... one entity in charge which gets to set the level of fairness"
Exactly what is unfair about the current system? The way we insure fairness is with laws and regulation. A system without those will suffer - well - lawlessness.
How is it centralized? The vast majority of dollars only exist as bits in computers in multiple banks all over the world. Doesn't get more distributed than that. Not only that - if you don't like dollars trade it for Euro's or Yen - you can pay your rent, mortgage and buy things with them also.
Other benefits of the current system. If someone steals my credit card I'm only on the hook for $50. My transactions are confirmed in a matter seconds pretty much anywhere in the world. I AutoPay many of my bills. If I set up automatic payments with Bitcoin I wouldn't be able to sleep at night.
There are problems that Bitcoin could help solve - it just isn't replacing currencies. I see a technology in search of a problem.
If you don't think the government is corrupt, I don't know what to tell you. You can keep on using your "fair" government currency (which the government prints by the hundred billion and gives to its billionaire friends) for everything, I'll be over here wishing for alternatives to Bitcoin.
Do you even hold significant government currency, or do you only hold the layer-2 bank currency, and stocks?
Yes my entire retirement is in "gov't currency" called US dollars and Stocks.
I asked for specific evidence or instances of corruption or unfairness. Making an accusation (gov't is corrupt) without evidence or example and saying something is true repeatedly is not a substitute for actual evidence. There are many documented cases of money laundering and wash trades with Bitcoin. These same activities are done using fiat currencies, but in the US at least BT (before Trump), they were illegal and people doing it were subject to criminal investigation. I do agree that there are many gov't policies that have lead to inequities in the distribution of the money that should be addressed.
Bitcoin will only make a fixed number of Bitcoins but they forked Bitcoins into 2 separate coins years ago which some might consider as printing more Bitcoin since everyone got a copy of their existing coins. New ShitCoins are minted to scam people on a regular basis. If anything the barriers to printing too much money are lower with Crypto because it is so easy to make a new coin type. Have you invested in any NFT's lately? What about coin front running? [0]
[0] https://www.reuters.com/world/americas/argentina-main-stock-...
Thinking Crypto is not subject to corruption is very naive.
>"If you don't think the government is corrupt, I don't know what to tell you. " If you cannot explain of give examples then I have to assume you don't really know - it is your opinion. I am sure people living in certain deeply corrupt countries - Russia comes to mind - like Bitcoin because their countries currencies are unstable and access to other currencies is limited. That said the reason they like it is BC can be exchanged for stable currencies to buy things. If those stable currencies did not exist BC would be useless for them also.
Most crypto, no.
The one to look at for that is Monero: the closest thing to private(anonymous) digital cash that I've found (so far).
Circumventing regulations is like half the point of crypto... either you use it to circumvent regulators, or you hold it while the price goes up because of the people who are circumventing regulators.
I think Bitcoin has become a typical fiat asset ouroboros now, because the people who actually want to circumvent regulators are using Monero (which is why Monero is banned in most countries), while the Bitcoin price is supported almost entirely by speculation and a little bit by people doing only-slightly-shady things with crypto who haven't noticed everyone else moved to Monero.
Where's the API for sending and receiving USD?
https://www.frbservices.org/financial-services/wires
https://achdevguide.nacha.org/
[dead]
Many such cases with crypto. Moderately good idea powered by a token becomes a Ponzi.
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.
In helium there was no input revenue. OP mentions payment to send. This is a very different scheme.
It's the same scheme. You had to purchase Data Credits to send on Helium too, there was no input revenue because no one was choosing to use it but it's largely the same as the scheme behind the Helium network. 1 DC/24 Bytes sent and successfully delivered.
>>I think it would be interesting if someone could invent a stable coin cryptocurrency with low overhead that enabled some of these use cases
We are thinking about this and building in this direction with Paygo.wtf
https://x.com/0x_Osprey/status/1925299005191577921
> 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.
If your country shuts off Internet access for demonstrations this would work great.
I guess it depends on the authoritarian government, but a sufficiently powerful one will get the app taken down or get the bluetooth features it relies on disabled (like for airdrop in China) :/
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.
Indeed! Advanced countries will and have blocked apps.
For a more extensive discussion on censorship resilient mesh networking, see IETF Internet Standard draft from 2012 [1]. After the Arab Spring there was global hope. Great to see revival of this topic today. Mesh networking is 1990s. The lesson from decades ago was that mesh networking can't be the killer use-case. Users need a reason to install this and allow it to drain the battery while looking for nearby nodes. Mesh networking never broke through the glass ceiling.
Blocking apps is real. Even Amazon killed a side-loaded app [2].
[1] https://www.ietf.org/archive/id/draft-pouwelse-censorfree-sc...
[2] https://torrentfreak.com/amazon-remote-disables-piracy-apps-...
Airdrop works fine in China, actually, if you leave it open you will be harassed by unwanted drops in public transport. E-sims are not allowed.
Yeah the change they made was to auto shut off airdrop after 10 mins. It's just that it happened to roll out in China around the same time that many apps were banned and protesters were reported as using airdrop to pass messages.
But I mostly agree - they rolled it out worldwide later on because once you reason it through, disabling it when it's not actively used turns out to be the better default.
wait timeout... airdrop is disabled in china?!
Was a bit more subtle than "disabled" really. See: https://www.engadget.com/apple-china-airdrop-limit-everyone-...
I think you could reasonably argue that the measure limits Airdrop spam.
But it would only really work well in a small area, such as a couple friends communicating at a demonstration, where there are a lot of people who may be motivated to participate in a particular area.
If there is a low density area between two people, a message could take a long time to show up. A message from NYC to LA is effectively relying on the messaging being cached on a phone in NYC, that person flying to LA, and then continuing the journey.
Though demonstration organizers could run around with QR codes making it easy for everybody to install the right app to communicate with each other during the demonstration. As long as people can side-load things on their phones, this should be possible without any way to stop it unless you deploy radio jammers. (Which is then the logical next step for police equipment in so minded states.)
People are supposed to scan a sketchy QR code to side load an app? That sounds like a security nightmare.
Those working against the demonstrators could send people out with QR code to infect the phones will malware for their own means.
[dead]
Yeah, I used an older version of a bluetooth messaging app like this. We wish it had been available in the times of Tahrir Square, but it was actually helpfull onetime when my bus stopped at a rural Ethiopian bus stop, my girlfriend ran into the bathroom but was taking too long and I was able to warn her that the bus was getting ready to leave.
Wireless internet is getting better, but when you really need something like this, you really need it.
If your country shuts off internet access they are probably going to jam bluetooth and wifi at any large demonstration, too.
Nation states can use the baseband radios to track/monitor you, so it's best to leave your phone at home. You can't disable or observe baseband from the higher level OS.
FWIW what people call "baseband" in the context of this particular security flaw is what everyone (including those people) call "cellular modem" in every other context.
On a Pinephone you can turn it off with a physical power switch.
If you really wanted to, on most other phones you could desolder it and throw it in the garbage. You'd need to already have custom firmware on the main CPU (or should I say "application processor" to fit in with the people who say "baseband processor") so it wouldn't crash or lock up when booting.
A little bit less destructive (in case you want to use your cellphone as a cellphone later) would be replacing the antenna with a dummy load.
That is what https://berty.tech is for.
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.
I don't think this is relevant. Free communication of people is the last thing regimes like those that govern Gaza need. My money on that local authorities will literally execute people for simply having such apps on their phones.
By "regimes that govern Gaza" I presume you're talking about Likud? They are the ones dropping bombs, but they don't have boots on the ground, so they can't inspect everyone's cellphone and catch people for having the wrong apps installed.
> 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.
Its best for places like football games or festivals, where the traditional network gets overrun
If you go to a football game or a festival to frantically keep messaging, better stay at home.
Spoken like someone who's never lost their pal at a festival
And doesn't see the potential sexy use-cases...
You are not getting laid by showing off your Bluetooth mesh chat app. Go to horny jail bonk
Internet don't work well in huge crowds - stadiums or mass protests. In second case govmt tend to block internet as well
[dead]
This is already mostly done.
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.
Yes, you could have a peer-to-peer connection with bluetooth as the transport layer. But that's not the vision. The vision is an out-of-the-box bluetooth mesh network, like what you have when you connect to an IP network with Reticulum.
exactly! using your phone which knows when you are going to toilet, and shares that with advertisers, for "super secret communications" ? makes no sense.
(YES APPLE DOES THAT TOO)
USA is in war with china right now. Companies and governments have different priorities in war.
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.
[1] https://meshtastic.org/ [2] https://meshmap.net/
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.
IPFS used to be a real solution, we used it as the base layer for the decentralized marketplace OpenBazaar and it worked fairly well for that. I haven’t followed it in a few years though.
IPNS, on the other hand...
I think of IPFS as a cross between HTTP and BitTorrent. Like BitTorrent it can seek a given dataset by some kind of hash, no matter where it's hosted; like HTTP it's more suitable for collections of small files.
In practice, it takes upwards of a whole minute to locate a file it's never seen before, so it's not terribly useful. It's better than nothing, but it's not terribly useful.
It's still cool that someone tried. IPFS is one in a long line of ideas that didn't really work. Occasionally some of these ideas have massive success, like the Internet, and Bitcoin.
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.
[1] https://ncmesh.net/learn/#coverage
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.
If I was looking for a thing that is fascist proof I'd add Briar to the list: https://briarproject.org/how-it-works/
They have been around for longer and have some interesting thoughts in there.
> Relaying devices earn a micro-payment
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
Bitmessage tried this. Defunct now I think.
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 think that money would only be used to send messages, as a way to prevent excessive spam. There needs to be some limitation. In whatsapp it's unique number or phones. Once you send too much spam from one number, it's burned. If you have anonymous network, how do you otherwise prevent from making new accounts for sending spam? If it is invite-only network, then it's pretty small problem.
I don't think relaying messages would require that much power and as you said, "You join the mesh because you want to use it yourself".
imagine building a lightning client into this.
Lightning network depends on… the internet… so if both clients are on the internet why not just send messages over that?
Privacy?
"Just encrypt things" might be your reply. TOR folks have been fighting an uphill battle for ages with that as their main weapon.
LN is an onion routed network, and has some privacy - notably, sender privacy, as the sender does not need to be known to the recipient. The recipient however is not private, but there have been proposals for rendevouz routing which could also anonymize them.
LN payments are based on Sphinx[1], but they don't leverage the full capabilities of it. Sphinx only allows for single-use replies.
The proposals for bidirectional anonymity involve using HORNET[2], which builds on Sphinx (specifically, it uses Sphinx's single-reply message to establish a HORNET connection), and enables sender-receiver anonymity and bidirectional transfer beyond single-reply messages.
It has also been proposed to include the use of TARANET[3] to prevent deanymization via traffic analysis.
[1]:https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
[2]:https://arxiv.org/pdf/1507.05724v1
[3]:https://ar5iv.labs.arxiv.org/html/1802.08415
eCash would be better, but someone needs to be connected to the mint.
Yeah, it’d be horrible UX
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 think there are other difficult scenarios as well, and that you might underestimate the size of an island. There are isolated cities, e.g. Perth with 2M inhabitants, and practically nothing around it.
One option --but it might require some centralization-- is that people announce they're going to travel, and stash a bunch of messages. If the sender can provide information about the geographical destination, that could help.
About monetization: remember what money did to the internet. But the above option would practically invite some form of payment. Thinking of Perth, that would lead to a kind of "Mad Max meets Johnny Mnemnonic".
Building the map of what nodes are where is definitely a hard challenge and why most mesh networks have just resorted to flood broadcasting with occasional replays instead of trying to build actual routing in then adding 'mesh tunnels' over the internet like Meshtastic's use of MQTT to link geographically disparate clusters of nodes. It's better with static nodes where you don't have to constantly rebuild your routing tables but gets tough when you mix in mobile nodes and another level when you add intermittent connections like Australian cities, best solution is probably long range backhaul nodes purpose built to link those in the end.
I'd recommend building simulations before you spend time on implementing any strategy. You could also looks up random graph theory. There might be some usable results wrt. connectivity.
Areas with censorship will simply ban such services and make it a crime to participate.
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.
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).
Technically viable.
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.
How would the payment work?
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.
Bitcoin Lightning requires realtime communication with every node in the route. If you can communicate with enough nodes to negotiate passing a message, you could also just send the message.
So painful when people recommend bitcoin lightning. Its technically interesting... but complete nonsense to pay like $50 just for one "hop" of the payment chain. It would be an upfront cost of hundreds to get a payment chain you planned on spending fractions of a penny per day/week/month
Hm? As I understood it, you lock up some money, and then secretly agree to reallocate it with the Lightning protocol, and then eventually get it back in the latest allocation. So it costs $50 and then you get $50 back - or $60 or $40.
This is an interesting thing when financial institutions do it between themselves. It's completely useless as a consumer-facing payment system. Consumers aren't going to plan in advance how much money to lock up, that's just stupid.
I assume you're not referring to the transaction fee because last I heard, it's not currently $25.
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 does routing work?
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?
This is a problem solved multiple times in the past.
Look up "distributed peer to peer" e.g. kademlia
Kademlia relies on an already existing all-to-all mesh (the internet). Nobody has created an actual mesh routing protocol which works very well.
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.
Would it work: yes, could it be disrupted: also yes.
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
Delta chat does this, without the micropayment.
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).
1: https://github.com/neilalexander/yggmail
Delta Chat can already run on top of iroh [0]. No need to find some other server implementation - it can already do "truly" P2P - devices can end up running their own STUN and TURN servers, etc.
[0] https://delta.chat/en/2024-11-20-webxdc-realtime
Delta Chat can transfer messages using a Bluetooth Mesh Network? That's new to me.
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
To make this work you need to be able to connect to the public blockchain, which of course requires internet access.
Absolutely, to deposit and withdraw. But relay can be done without the Internet.
The central smart contract is on the blockchain and can only be used if the internet is up. That's why you haven't solved anything here.
Your proposal is that since Alice and Bob can't communicate in real-time, either directly or indirectly, Alice does an interaction with a smart contract to lock some value and then Bob does an interaction with the same smart contract to unlock some value.
We can view the smart contract as some shared algorithm between Alice and Bob (if they are running their own nodes) or we can view it as something outside of them both (perhaps they are RPC customers of Infura). If Alice and Bob are running their own nodes, however those nodes manage to communicate with each other is a way they could just send the message to each other and not need a blockchain. And if they're both able to communicate with Infura, they could also swap Infura for Gmail and send each other a message the normal way (or if they can really only reach Infura for some reason, they can put their messages on the blockchain). But we are talking about designing systems that can work in scenarios where direct communication like this is impossible, and messages have to be forwarded hop-by-hop over a span of hours. You can't design a system for slow networking, that assumes the existence of a separate fast network just to run the payment system.
All nodes running a blockchain have to be in low-latency contact with each other. If you try to run Bitcoin in a network with multi-hour latency, you'll never reach consensus on which blocks are in the chain. You'll be hard-forking all over the place. You'd have to slow it down to, like, one block per week, but then it's far too slow to be useful for payments.
If a blockchain exists in such an environment, it exists on a tightly-coupled cluster of nearby nodes. And that cluster is pretty much the same as a single central node, from the perspective of the network. You don't gain anything by making it a cluster (except for redundancy, as usual).
To claim payment for services too. You've created a new problem that does nothing to solve the original problem.
I gather you aren’t familiar very well with smart contracts, are you?
More familiar than you can imagine. The fact that you think smart contracts are what are needed to solve a decentralized communications problem suggests that you've learnt a new hammer and everything now looks like a nail to you.
Please check the parent comment which I replied to, this is a solution to “how to implement a robust micropayment system” in this context, not how to solve a “decentralized communications problem”.
Well, there's the "Given the intended use-case, that would not work." part which very much means the payment system is in the context of the intended use case.
The full comment quoted:
My reply is: here is the system that will work. Very simple. Keep in mind that multiple use cases and applications were mentioned, so I don’t see an issue for such an economic model to support at least some of the use cases.It doesn't work for this use case, as they tried to explain, as it breaks the entire point of the system as a messaging platform that doesn't require the internet.
I'd like to better understand steps 3 and 4.
The sender deposits a fee into a smart contract.
The message is encrypted in layers, with each forwarder only able to decrypt their part (like an onion).
As the message is forwarded peer-to-peer, each forwarder appends some kind of proof-of-forwarding.
When the recipient finally receives and decrypts the message, they unlock the contract using a code embedded in the message. This triggers micropayments to all the forwarders.
Do forwarders need to interact with the blockchain (i.e., create/update a smart contract) when forwarding?
If so, wouldn’t that require each forwarder to have internet access at the time of forwarding—which breaks the idea of fully offline Bluetooth relaying?
Or is all the blockchain interaction deferred to the recipient, who proves the path the message took and triggers all payments at once?
it's a real life application where a Blockchain based solution does actually make sense, believe it or not.
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.
There have been incidents where governments disabled routing to specific services or the Internet entirely to hinder demonstrations.
to give a example: https://en.m.wikipedia.org/wiki/2019%E2%80%932021_Jammu_and_...
i'm not sure if in this case "only" the 4G network was shut off, but IMO it still serves as a good reminder of when such an event might happen again.
also: https://ooni.org/reports/
That is why I added "large-scale" and "long-term"
How relevant is this in the context of the mesh networks under discussion?
How resilient are those protocols to attacks on the integrity of the network, when most (or signicant part) of the nodes are controlled by a bad actor and deliberately operate in a mode that prevents the functioning of the network?
Absolutely viable.
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.
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.)
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 ?
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!
that was basically Rumble an app I developped 10 years ago: https://github.com/Marlinski/Rumble
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).
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...
They relied only on scanning nearby id-s, without communication.
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.
https://ditto.live
“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.
How do you solve double spending?
You don't really need to. In IOU systems you extend credit to someone you know, based on ones reputation or credit score. How back in the day your local milk man would just keep a tab of what you owe.
In a way everyone has something to barter: you owe the milk man, your employer owes you. Identities form a web of trust in the physical world.
But how would you eventually reconcile and settle balances?
Would all payments be just non-fungible bilateral agreements? So if I paid the milkman for some milk, but there was no good or service I could later provide to him, he would be unable to take my payment to the butcher to buy some meat (unless the butcher was also willing to enter into a new bilateral agreement with me)?
Music festivals or similarly congested public events would be good use cases
If you are going to do a payment system all other things come second.
Not inspired by FireChat?
Get Uber drivers/taxis, truck drivers, ups/amazon delivery people etc. As your relay devices (and gives them extra cash for driving around)
> or is it just a neat academic toy
The Internet was a neat academic toy at one point for whatever that's worth :-)
I believe that's called sneakernet. See reticulum for that.
Well it's a tough problem even before you start adding money to it.
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 costs energy.
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.
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.
Sounds like a solution looking for a problem.
basically, a user friendly and publicly accessible variant of APRS for ham radio?
Kind of, with every node also acting as a digipeater with some logic on top to avoid messages endlessly echoing through the network.
[dead]
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.
Bluetooth LE which most smartphones support today is quite a bit different from Bluetooth classic. It typically runs at 1 or 2 Mbps and can trade bandwidth for error correction to get some impressive range. For example, this guy got 1.6 miles at 8dbm transmission power. https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/pos...
The audio codec on ble is more modern too.
> “You can't even hear a ok quality music further than 20 metres away” That smells like the SBC codec running on Bluetooth classic to me. Very different tech.
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.
I'll try this app because Briar never worked between any of my devices (all Androids)
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.
If it's open source, I would love to help.
I will give your app a try.
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.
This sounds perfect for my use case. I'm a mountain biker who doesn't mind setting up hosting infra. It's fairly common when mountain biking to unintentionally get separated by line-of-sight or more than 75M even among very similarly skilled riders. Even on straight easy trails, just the dust cloud generated by the rider ahead can cause you to back off significant distance if it's dusty.
I've used these[0] in the past and they worked ok. I lost the pair I bought when traveling and thought using the plethora of radios I have with me anyway on my phone with an earbud headphone would be much better replacement. Would be great for group rides to just send an app link instead of suggesting they all buy $100 hardware.
Honestly I think a well marketed and polished commercial app would have both Sena and Cardo[1] both quite existentially scared.
[0]: https://www.sena.com/en-us/product/pi/ [1]: https://cardosystems.com/
App will be held down by the hardware. Smartphones are not meant to transmit with the necessary power, and you also don't get direct access to the radio, so you can't run custom protocols like Sena/Cardo, but you must transmit over the actual bluetooth or actual WiFi.
They're not really a competition.
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.
Totally missed this news. EU will mandate it indeed
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 mean it is in most of the UK. Maybe not in remote areas of Scotland or Wales.
In most of the supermarkets down here, couple of miles from M25. I mean, outside, so its probably considered third-world country, but no, no need to reduce the argument ad absurdum.
Or 2 metres from the window a mile from Hammersmith. If not for WiFi calling I'd have to leave my phones on the windowsill.
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?
For this use case, old fashioned radio is a lot more reliable.
Quite likely, but then you need to carry that radio. And probably still carry a phone in case you split up and want to communicate.
You raised reliability issue, you've got a solution, now you're moving a goalpost and raising a convenience argument.
Decide which one is it.
PS Motorola talkabout T62 or T42 - small, light, reliable. Retevis h777: sturdy, reliable. You can just drop them in the bag.
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.
You can't. Smartphones are Class 2 devices (weak), and you must use radio the way firmware let's you.
Purpose-built hardware is Class 1 (much stronger, 100 mW/20dBm vs 2.4mW/4dBm), and they can use sophisticated protocols to keep the connection stable. And that's Bluetooth.
If they're not playing Bluetooth but go general ISM, they can emit whole 1W on 2.4GHz or 915 MHz.
They're not really alike.
I would love to use it to talk to my girlfriend when we go bike riding. I was shocked by the price tag for all the motorcycle helmet comms systems.
If you're looking at the premium segment then yeah, when you're going out with your several mates and need to be able to hear every one of them.
For one rider to one rider you can get a very decent set well under $100 (Lexin b4fm, FredConn, even Thokwok is well reviewed).
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.
Bluetooth to reach and reliably hold a high throughout connection to the device across the house?
I don't think so.
You can do a surprising amount with a low throughput connection though. I've been playing with Google's Lyra V2 codec - it chews up a fair bit of CPU, but 3.2kbps over a CodedPhy link sounds fine.
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.
When I last had a university workshop where 20 people in a room worked on a bluetooth protocol I also noticed bluetooth is quickly saturated with many participants. Hopefully that changed in the last 15 years since...
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.
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)
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.
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/).
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.
I dunno, that still sounds like a perfect use case for a third-party app like the one this post is about. I'm not sure government crackdowns are a core enough experience that it needs a first-party app from Apple.
They happen regularly in the USA and Europe now.
Government shutdowns of the internet happen "regularly" in the USA? Name one time.
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.
When would you want to peer over third party networks while a direct connection is possible?
Maybe you want to have a local conversation about Winnie the Pooh?
Hiking, Airplane, stadia (here in India the tower capacity get exhausted), underground metro etc
Hiking? Probably not very useful since you must be within Bluetooth range and you can whisper to your chat partner.
If you're hiking in the remote area youre much better off with LoRaWAN or amateur radio transceivers anyway.
I dunno, I bet if it was widespread people could come up with applications. Like, telling people doesn’t necessarily leave a record, so you could talk about tomorrow’s plans and then send a summary text so everyone has a record and all the details.
“Coded PHY” Bluetooth has a range of up to a kilometer! Once you add mesh forwarding, you could probably cover quite some distance on moderately busy hikes.
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.
“With iOS xx, now you can message your loved ones even without any cell or Wi-Fi signal from up to a mile away! Simply make sure you already have an iMessage conversation with them started while you still have signal.”
When you're sufficiently outdoors with friends and/or family
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.
Apple added support for this 10 years ago
https://developer.apple.com/documentation/multipeerconnectiv...
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.
It would be trivial to be disabled by iParents
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'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.
The 30% also covers refunds, legal stuff (not stuff IN your app, but regarding the sale of it), taxes, GDPR and much more. The infrastructure running the app store probably also isn't cheap.
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.
> the damage will be somewhat limited if it can't use private APIs.
That's a runtime feature, it has nothing to do with the App Store.
App Store only allows apps not using those runtime features
...which is enforced at a system level. The App Store is not mandatory for giving users control over app entitlements.
> 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.
OP was referring to apps downloaded from the app store.
you can't get a build hash from a downloaded app to then compare to a source build.
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.
Android may be shitty but it allows you to install an APK you downloaded from god knows where, and that's enough of a deal-making feature for me.
I also own a Linux phone, but I don't use it. Maybe one day someone will create one that's actually usable...
That was not the point of the discussion.
I could answer "iOS may be shitty but it doesn't phone home every touch and your health data stays local". I really don't want to argue abour iOs vs Android. I used both. They are both shit made to lock their users in an ecosystem that solely benefits Google or Apple. I really couldnt care more about arguing which is worse, I would just want the market to allow something better than both for me, the user.
> 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".
> Apple spends billions of dollars vetting their store for high quality apps.
Rofl. And citation needed.
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.
> 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.
Sure but it's an commendable effort by a CEO.
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.
I guess his commits were done on GitHub.com then?
Is there a link to the TestFlight itself?
Wasn’t sure if a random TestFlight link would be safe/wise to share, so shared original source.
https://testflight.apple.com/join/QwkyFq6z
https://testflight.apple.com/join/QwkyFq6z
Oops!
https://blog.technitium.com/2015/05/technitium-bit-chat-rele...
I had released that 10 yrs ago lol.
I read that name as “bitch at”. I thought maybe it was one of those GPS collars for finding your runaway dog.
I assumed it was a subtle nod to an old irc client https://en.m.wikipedia.org/wiki/BitchX
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.).
“Did not work at all for my male dog. One star”
Same but I thought it was a place to yell and complain at people
bruh...
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.
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?
Search for “BLE coded PHY”.
The S8 coded mode with 125kbps rate is the long distance one. Support for it in phones is not widespread, sadly.
Thanks! I didn't realize that was the key phrase.
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.
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.
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.
Heltec MeshPocket is another. A powerbank and LoRa device.
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.
the special hardware's cheap enough that if they can't be bothered, then they're not serious about it.
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.
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.
Flooding does work for sending individual messages from user A to user B at a small enough scale, but it gets progressively less efficient as the network grows, and at some level it will collapse.
Flooding works if there is not too much hops between the sender and the recipient. For indoor IoT, it is very rare to have more than 3 hops and the data rates are extremely low and messages are just few bytes (on/off light, temperature).
It would only take 4 people at 5 hops apart trying to exchange photos of less than a megabyte to completely saturate a network of hundred devices.
It depends on how often they're exchanging those photos, but it doesn't depend on the number of hops, or even the number of nodes, just the total number of publishers and the bandwidth desired by each publisher. In flooding every message gets transmitted (eventually) by every device, so the bandwidth available for the average publisher is the bandwidth of the slowest device divided by the number of publishers, regardless of how many hops or nodes there are.
No, because messages have a TTL precisely to avoid continuously flooding of the entire network, or messages looping, etc. Without this, all the links would quickly become saturated, as would the caches, and the network would collapse.
Ideally, the TTL should be as low as possible in order to preserve maximum bandwidth and not hit nodes far from the transmitter.
The Bitchat documentation indicates that the maximum TTL is 7. There is also mention of gateways on the internet to enable long-distance communication.
In the case of IoT devices, their location is generally fixed and the gateway or hub is placed in the centre in order to limit the TTL, save bandwith, limit wakeup time. Some more advanced mesh network protocols use flooding only for announcements and network mapping in order to avoid this problem. This allows it to define preferred routes, set up an acknowledgement system, replay, etc.
Not all flooding protocols have TTLs, and there are non-TTL ways to prevent messages looping in flooding protocols. Possibly what you're saying is correct specifically pertaining to Bluetooth, which I don't know anything about.
Interesting. I looked at https://www.bluetooth.com/mesh-directed-forwarding/ and it seems like "Bluetooth Mesh Directed Forwarding" is an improvement over "Bluetooth Mesh Managed Flooding" for this scenario? It got added in v1.1 of the spec.
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.
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?
As much as I like the idea of people working on peer-to-peer networks, delay tolerant network, if I'm within Bluetooth range, it's quicker to chat with the person I'm talking to than to go through a messaging app.
That technology is interesting, but it is probably not a good usecase. There are potentially lots of interesting things you could do with smart watches and bike computers, such as uploading activities without direct connection to a phone or sharing routes with nearby participants, etc.
Use cases where you may not necessarily have a phone or adequate network coverage.
We can communicate in more ways than just with words. Would be great to FINALLY have a sensible, low-friction, secure way to transfer files to people. It's 2025 and that's still not a solved problem.
You probably don't need a decentralised, delay-tolerant network to send a photo to the person in front of you. It's even very likely that this will be much less efficient than a direct Wi-Fi or Bluetooth connection or an AirDrop.
What would be the use case? Send the picture to someone at the other end of the lecture theatre? It's likely that there would be a phone network or Wi-Fi available. A crisis or emergency situation where networks are down? There isn't much population density or movement to propagate the data.
This debate is not new, many teams have worked on wireless ad hoc networks, some with very encouraging results. The real problem is what the use cases are.
That's why I personally think that the use case should be related to travel, transport, sport or vehicle-to-vehicle communication. Situations involving movement and loss of connectivity.
> Send the picture to someone at the other end of the lecture theatre? It's likely that there would be a phone network or Wi-Fi available.
Now you're back to using a centralised system using a network you know nothing about, operated by someone you don't know.
> direct Wi-Fi or Bluetooth connection or an AirDrop
AirDrop is not cross platform AFAIK. Direct wifi or bluetooth aren't the easiest to work with for non-technical users.
> A crisis or emergency situation where networks are down? There isn't much population density or movement to propagate the data.
Why not? Do emergencies only occur when people are few and far between? I think I'm misunderstanding what you're saying.
> That's why I personally think that the use case should be related to travel, transport, sport or vehicle-to-vehicle communication. Situations involving movement and loss of connectivity.
That's certainly a valuable use case, but probably not something that bitchat would be useful for.
the use case is really decentralized communication. sure connecting to wifi is easy and accessible, 4g is pretty much unlimited, but what if you just want to share files/photos directly with a group of people without having to traverse the web/someone else's hw/sw? this is basically like a detached, private web. most of the time, you probably dont care if meta has your files, but for those that just dont like centralized services, this is great. think of it like an extremely private network, why not?
I'm not against the idea, but it has already been tested with Firechat, Bridgefy, etc. during the protests in Hong Kong in 2019.
It doesn't work very well from a technical and practical point of view. Just having the app on your phone could be enough to get you charged in a totalitarian state.
So it's interesting, but it's not the use case that will democratise this type of ad-hoc network. For example, it is easier to implement end-to-end encryption on an existing infrastructure.
There must be a use case where there is no network connection, enough network participants, and that can accommodate a significant transmission delay.
You don't need to be close to send a message, just close to someone on the network so you can connect, the message will be relayed hoping through the network
I would agree although I can see a few applications of the tech that could be helpful.
Consider if at a large conference where enough participants are able to create a mesh and then leave geo tagged messages and send beyond BT range.
If there was a way to piggyback on top of the airtag network we could do a lot more.
This is something I've wanted for ages. I go to some event with the family - in London for example or to an airshow - and there's a huge crowd for one reason or another which overloads the mobile network and makes your phone useless. You can lose people who are just a few metres away.
I am glad it's public domain - I don't think I really want to invest any effort in getting non-techy people to try and use something that might go away one day and be irreplacable. OTOH, I need Android as well so....
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.
Isn't Briar all JVM? AFAIK that can't really run on iOS at all since Apple disallows foreign JITs; unless they compiled Briar to native.
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 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?
> Use case? You're in the middle of a protest. Where to next?
Hopefully, not in prison.
[dead]
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.
Is it Bit Chat or Bitch At?
I’m assuming that it’s Bitch At since with a ~30ft range you’ll be able to see who you’re bitching at
Nice double entendre for sure.
Or like the old chat client BitchX
Bitch At. Same as Bitch Ute.
Yes
[dead]
Depends if you're messaging your friends or your girls.
"Area Codes".
I've tried a couple of apps like that with use case of communicating during festivals with next-to-none wifi/cell service with a big group of people. None of them worked. Fingers crossed for this one
Checkout Meshtastic nodes you can get them pretty cheaply at 30-40 USD each and get way better ranges than BTLE.
Thank you!
How does this differ from FireChat? https://en.wikipedia.org/wiki/FireChat
Firechat is defunct and hasn't been updated in ~7 years which is a pretty big issue.
good question. but FireChat never took off for some reason(s).
Boggles my mind how we all have cellphones capable of forming a massive (global?) wireless mesh network that can't be shutoff/censored (without jamming). Get rid of ISPs.
Get rid of all these garbage social media (government honeypots) platforms that leak all your data every other weak.
Use Zero-knowledge proofs for authentication into distributed web apps.
Use BitTorrent file system to distribute data to prevent a single point of failure where all your data is leaked.
I could go on and on.
related: https://en.m.wikipedia.org/wiki/Secure_Scuttlebutt
Scuttlebutt is another decentralized peer to peer messaging platform
Since its so niche people should probably collaborate to get one of these solutions out into adoption. Coding stuff is super fun though...
Best name since expertsexchange.com and penisland.net !
TherapistFinder might want a word
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.
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.
There are scalable reliable multicast protocol designs that don't require publishers to track subscriber lists, but you're right that the approach I suggested above would require that.
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.
How about HaLow?
this looks great for most use cases. most interception has been ruled out by the simple protocol for rooms, where the remaining attack appears to be just to clone the users keys, where it's more viable to attack the phones than the protocol, which is the point.
the spitball questions I would ask might be, a) how do you handle a theoretical timing attack where the time to respond to a room scan could yield whether a given device is a member of a known room, (the paralellism?) and b) does the GCM counter IV/nonce value cluster around rooms, so the counter for a given room will be in a shared range?
not dealbreakers or anything, this is simple and cool for its purpose, but design consideration wise, what's the thinking on those scenarios?
This is my very youth toy project that never came to be, always dreamed of something this local when I used to be more at festivals as an introvert and stuff, good times, and awesome to see someone actually was able to pull it of.
I'm relatively new to programming and aware of who Jack Dorsey is, but isn't this quite impressive for a single programmer to build?
Without the help of LLMs, this would have been much more difficult.
It’s a good example of what someone can accomplish when they understand how to work effectively with them.
one programmer and 20 AI agents probably
Anybody know when the next batch of beta invites goes out or how to get one ?
My wife and I have been using Berkanan (an iOS app) for many years for this purpose. It's not very good - unlike literally every other chat app, it presents conversations in reverse chronological order, and the interface is janky. But it gets the job done when there's no WiFi (airplanes, though this is becoming less of a problem) or cell service (crowded venues).
Title should include "for the apple eco system"
This is a really exciting project! I love how it makes each message feel more valuable, like modern-day letters, but more convenient.
Anyone else read it as "Bitch at"?
Who is nothankyou1? That guy is the real developer, dorsey just added some nonsense commits like a true manager.
The coolest thing about this is apparently it’s written by Jack Dorsey, billionaire founder of Twitter/Square. https://x.com/jack/status/1941989435962212728
Cool to see he still gets his hands dirty in code.
It's not though, it's written by someone called nothankyou1 https://github.com/jackjackbits/bitchat/graphs/contributors
The commits, viewed outside of GitHub, have:
He used a bogus `user.email` git config value, which GitHub matched to the nothankyou1 account.Yeah I noticed this too! The profile picture looked familiar.
This looks nice, but isn't this just a duplicated effort to make the subsets of the Reticulum network?
https://github.com/markqvist/Reticulum/
For days I’ve been reading this bit chat…today I finally noticed the pun
I really don't see the relevance of this app. We already know that Bluetooth (BLE) is short range.... so is this equivalent to speaking to people a hundred feet away from you in an encrypted manner? So use case is only for protests I assume?
Imo any kind of p2p mobile app is DOA without background activity on iOS.
But i'm also firmly in conviction that p2p is the future, so i don't know how we get there. regulators getting on Apple's ass again?
The serval project had worked on a similar app but now using Wi-Fi. https://github.com/servalproject/batphone
I know it's supposed to be BitChat, but once you notice BitchAt, it's kind of difficult to unsee it...
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...
You don't need TK invent another transport protocol: https://github.com/markqvist/Reticulum
> Looks to be a little IRC-inspired with the usage/commands.
This is listed as a dedicated "feature" in the README: "IRC-Style Commands"
I would love to see phone manufacturers start working on add LoRa to phones.
There's also https://github.com/meshenger-app/meshenger-android for generic LAN (without groups/peer discovery).
Why Bluetooth which has pretty bad range when most phones have a wifi module built in? Is there not a mode on the module that could function similarly?
Looks like we have a new mesh comms solution every two weeks or so.
Funny, I had a similar idea in 2010, from which nothing followed of course:
https://imgur.com/a/VWiDBO3
This is one of those ideas that everyone has had.
Very cool, I've often thought that such a short-range chat would be fun on an airplane. Not practical, but it could be neat to chat with the group in the air.
If we could bridge over Meshtastic, this would be so good.
Why such a rude name "BitchAt"? At what?
BitChat.
It took me like 12h to see the wordplay in the name.
i thought during the hong kong protests they used firechat, never heard of bridgefy:
https://techcrunch.com/2025/07/07/jack-dorsey-working-on-blu...
Be cool if he added reed Solomon to do raid over the packets and send the replicas through multiple routes
When will the Android release be ready?
Reminds me of nntp, from back when the Internet wasn't 'always on' or fully connected.
NNTP is alive and well, as is USEnet.
https://www.theregister.com/2023/08/30/usenet_revival/
hope this does well. We see people trying again and again like FireChat or Berty it seems that it works for a bit with some devices but then Apple & Google make updates and the app dies.
In general mobile app development seems to be very maintanence heavy
Is the Web Bluetooth API good enough to do mesh stuff?
So we could have localhost or offline websites doing this.
Is this the real Jack Dorsey? I see he even has commit/push access to repos at Block
It is
Too bad it's not cross-platform which makes any real use pretty limited.
This particular application isn't, but at the end of the README you get a section on how to port to Android, and the protocol is open as well. So it's a matter of investing the effort on your side.
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.
Meh Apple only. Non starter in Europe.
But perhaps I could give briar another try.
As a fun project, why not. But this is just another problem which can be solved by radio bought from aliexpress.
No wait, let's reinvent the wheel again :)
In case of war or something, internet is down, decentralized Bluetooth messaging app is your last problem.
IRL you will be using unencrypted radio, yes doesn't make sense. But already proven in the UA war.
Try using encrypted radio on the frontline and you will get suicide drones or artillery shell on your position, pretty quickly ;-)
let's convert this one to kotlin multiplatform...
why not just use meshtastic and you get longer range too?
Meshtastic requires a separate transceiver.
More of this please. Bring back peer to peer
"Can I get your bitch at?"
I will Woof it to you
.
Bridgefy is another player in the sparse, offline messaging space.
Now someone build it on the AT protocol and call it bitchAT
bitch@
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
[flagged]
Management-tier grasping at technical language, reads like CSI dialogue.
[flagged]
Is this actual programmer output or is this just what Claude gives you with a certain prompt?