[HN Gopher] Bitchat - A decentralized messaging app that works o...
___________________________________________________________________
Bitchat - A decentralized messaging app that works over Bluetooth
mesh networks
Author : ananddtyagi
Score : 647 points
Date : 2025-07-07 00:05 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ChrisMarshallNY wrote:
| 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.
| ajr0 wrote:
| 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...
| ChrisMarshallNY wrote:
| IOS/Apple Bluetooth is an interesting place.
|
| Backrounding is kinda klunky. I think it's deliberate, as
| that's a real security vector.
| vips7L wrote:
| 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.
| ckcheng wrote:
| 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...
| ChrisMarshallNY wrote:
| 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.
| encom wrote:
| >Universal App
|
| For Apple only. In what way is this universal?
| 1ark wrote:
| It is Apple terminology for an app that supports both iPad
| and iPhone.
| ChrisMarshallNY wrote:
| 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.
| toast0 wrote:
| 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.
| syntaxing wrote:
| 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.
| eternityforest wrote:
| 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#
| syntaxing wrote:
| 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.
| eternityforest wrote:
| 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?
| syntaxing wrote:
| Any line of sight stuff can be tough. Another one is
| standard 433 radio but difficult since its such a noisy
| environment.
| myself248 wrote:
| 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.
| syntaxing wrote:
| 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.
| K0balt wrote:
| 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...
| kragen wrote:
| That's extremely surprising to me too. I would have expected
| BLE to reach a few meters, not kilometers. How can I learn
| more?
| Aurornis wrote:
| 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.
| kragen wrote:
| Thanks! I didn't realize that was the key phrase.
| imoverclocked wrote:
| 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.
| estsauver wrote:
| 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.
| RenThraysk wrote:
| Heltec MeshPocket is another. A powerbank and LoRa device.
| fragmede wrote:
| the special hardware's cheap enough that if they can't be
| bothered, then they're not serious about it.
| cmiller1 wrote:
| Is it Bit Chat or Bitch At?
| Izmaki wrote:
| Depends if you're messaging your friends or your girls.
| esafak wrote:
| "Area Codes".
| unixhero wrote:
| Or like the old chat client BitchX
| shawnlower2 wrote:
| Yes
| jrflowers wrote:
| I'm assuming that it's Bitch At since with a ~30ft range you'll
| be able to see who you're bitching at
| colordrops wrote:
| Nice double entendre for sure.
| brikym wrote:
| Bitch At. Same as Bitch Ute.
| lxgr wrote:
| 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.
| dzhiurgis wrote:
| I'd much rather Apple allow running something like this (open
| source) myself rather than use their "just trust me bro" store.
| OsrsNeedsf2P wrote:
| 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.
| noman-land wrote:
| 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.
| woleium wrote:
| But, sadly, as evidenced by apple's share price, not
| enough people.
| pjerem wrote:
| 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.
| immibis wrote:
| 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...
| thejazzman wrote:
| 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.
| pjerem wrote:
| Also, the store is fulfilled with _billions_ of shitty
| apps.
| 8fingerlouie wrote:
| 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.
| bigyabai wrote:
| > 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.
| aguacaterojo wrote:
| > 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
| __MatrixMan__ wrote:
| > 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.
| Tokumei-no-hito wrote:
| 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.
| dzhiurgis wrote:
| 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".
| TiredOfLife wrote:
| > Apple spends billions of dollars vetting their store for
| high quality apps.
|
| Rofl. And citation needed.
| apetresc wrote:
| 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?
| darknavi wrote:
| Airplane
| woleium wrote:
| and the reason they probably cite as why they don't,
| children with no sim or wifi.
| darkwater wrote:
| It would be trivial to be disabled by iParents
| nabeards wrote:
| 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.
| dewey wrote:
| 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.
| lxgr wrote:
| 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.
| dewey wrote:
| 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.
| lxgr wrote:
| "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."
| __MatrixMan__ wrote:
| 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/).
| Buttons840 wrote:
| 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.
| __MatrixMan__ wrote:
| 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.
| c22 wrote:
| When would you want to peer over third party networks while a
| direct connection is possible?
| reaperducer wrote:
| _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.
| ImPostingOnHN wrote:
| When you're sufficiently outdoors with friends and/or family
| vishnugupta wrote:
| Hiking, Airplane, stadia (here in India the tower capacity
| get exhausted), underground metro etc
| subscribed wrote:
| 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.
| lxgr wrote:
| "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.
| bee_rider wrote:
| 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.
| 3eb7988a1663 wrote:
| Maybe you want to have a local conversation about Winnie the
| Pooh?
| ileonichwiesz wrote:
| 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.
| sunnybeetroot wrote:
| Apple added support for this 10 years ago
|
| https://developer.apple.com/documentation/multipeerconnectiv.
| ..
| trklausss wrote:
| 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.
| rendx wrote:
| There's also https://github.com/meshenger-app/meshenger-android
| for generic LAN (without groups/peer discovery).
| halfmatthalfcat wrote:
| 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.
| eternityforest wrote:
| 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.
| kragen wrote:
| 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.
| eternityforest wrote:
| 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.
| kragen wrote:
| 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.
| dzhiurgis wrote:
| How about HaLow?
| potamic wrote:
| Using the phone's RF modem itself would be the ideal choice.
| Why aren't there any userspace applications over this?
| toomuchtodo wrote:
| Baseband access limitations. External RF/SDR solves for this
| if you're seeking long haul RF capabilities, but admittedly
| requires non native/external hardware.
| DeepYogurt wrote:
| More of this please. Bring back peer to peer
| BluSyn wrote:
| 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.
| syntaxing wrote:
| Is there a link to the TestFlight itself?
| joshuaturner wrote:
| https://testflight.apple.com/join/QwkyFq6z
| Nicksil wrote:
| https://testflight.apple.com/join/QwkyFq6z
| BluSyn wrote:
| Wasn't sure if a random TestFlight link would be safe/wise to
| share, so shared original source.
| suck-my-spez wrote:
| Interestingly only a few commits were written by his account.
| Almost all were from https://github.com/nothankyou1
| jasonvorhe wrote:
| He doesn't use personal identifiers on any of his devices,
| afaik.
| suck-my-spez wrote:
| I guess his commits were done on GitHub.com then?
| lossolo wrote:
| > 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.
| IncreasePosts wrote:
| Is this actual programmer output or is this just what Claude
| gives you with a certain prompt?
| motohagiography wrote:
| 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?
| kyawzazaw wrote:
| How easy it is to use for non-technical people?
| ChrisMarshallNY wrote:
| This looks like a nerd's tool, but I suspect we'll start seeing
| more GUI-friendly versions, shortly.
| babuloseo wrote:
| why not just use meshtastic and you get longer range too?
| int_19h wrote:
| Meshtastic requires a separate transceiver.
| Jotalea wrote:
| 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.
| btbuildem wrote:
| 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...
| subscribed wrote:
| You don't need TK invent another transport protocol:
| https://github.com/markqvist/Reticulum
| dewey wrote:
| > Looks to be a little IRC-inspired with the usage/commands.
|
| This is listed as a dedicated "feature" in the README: "IRC-
| Style Commands"
| monkaiju wrote:
| 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?
| dbworku wrote:
| Everything old is new again... Repo description reminds me of the
| Shortwave app from the 2010s.
| https://medium.com/@alonsoholmes/wtfbeacon-how-shortwave-wor...
| alternatex wrote:
| 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.
| brikym wrote:
| "Can I get your bitch at?"
| seanlinmt wrote:
| 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?
| darkwater wrote:
| > Use case? You're in the middle of a protest. Where to next?
|
| Hopefully, not in prison.
| sardine5 wrote:
| 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)
| Karrot_Kream wrote:
| 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
| sardine5 wrote:
| 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.
| roshin wrote:
| 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)?
| sardine5 wrote:
| 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...
| IshKebab wrote:
| I mean it is in most of the UK. Maybe not in remote areas
| of Scotland or Wales.
| toast0 wrote:
| 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?
| jappgar wrote:
| For this use case, old fashioned radio is a lot more
| reliable.
| toast0 wrote:
| 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.
| wickedsight wrote:
| 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.
| master-lincoln wrote:
| 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...
| nullify88 wrote:
| 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.
| subscribed wrote:
| Bluetooth to reach and reliably hold a high throughout
| connection to the device across the house?
|
| I don't think so.
| sardine5 wrote:
| 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.
| dfc wrote:
| 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.
| kaiken1987 wrote:
| 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.
| LWIRVoltage wrote:
| 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!
| sardine5 wrote:
| It's AES128 encrypted with a key derived from the group
| password.
| subscribed wrote:
| I'll try this app because Briar _never_ worked between any of
| my devices (all Androids)
| summm wrote:
| 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)
| numpad0 wrote:
| 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.
| cpeth wrote:
| 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.
| sardine5 wrote:
| 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.
| cpeth wrote:
| 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/
| sardine5 wrote:
| 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.
| lhoff wrote:
| 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.
| sardine5 wrote:
| 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)
| driverdan wrote:
| 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.
| jusling wrote:
| How does this differ from FireChat?
| https://en.wikipedia.org/wiki/FireChat
| kragen wrote:
| Technical whitepaper:
| https://github.com/jackjackbits/bitchat/blob/main/WHITEPAPER...
|
| Presumably that is the key to getting out of the Apple ghetto.
| Tepix wrote:
| 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.
| Beretta_Vexee wrote:
| 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.
| kragen wrote:
| 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.
| max_ wrote:
| Is this the real Jack Dorsey? I see he even has commit/push
| access to repos at Block
| jdmoreira wrote:
| It is
| moneywaters wrote:
| 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?
| littlecranky67 wrote:
| 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.
| hashworks wrote:
| There have been incidents where governments disabled routing
| to specific services or the Internet entirely to hinder
| demonstrations.
| littlecranky67 wrote:
| That is why I added "large-scale" and "long-term"
| derhuerst wrote:
| 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/
| Ray20 wrote:
| 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?
| jacobgkau wrote:
| > 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.
| bryant wrote:
| > 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.
| Dr4kn wrote:
| If your country shuts off Internet access for demonstrations
| this would work great.
| xyzzy123 wrote:
| 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.
| synctext wrote:
| 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-...
| thenthenthen wrote:
| 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.
| ChicagoBoy11 wrote:
| wait timeout... airdrop is disabled in china?!
| al_borland wrote:
| 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.
| teiferer wrote:
| 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.)
| al_borland wrote:
| 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.
| ijustlovemath wrote:
| 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.
| immibis wrote:
| 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.
| zikduruqe wrote:
| That is what https://berty.tech is for.
| out_of_protocol wrote:
| Internet don't work well in huge crowds - stadiums or mass
| protests. In second case govmt tend to block internet as well
| notfish wrote:
| Its best for places like football games or festivals, where
| the traditional network gets overrun
| miroljub wrote:
| If you go to a football game or a festival to frantically
| keep messaging, better stay at home.
| benbristow wrote:
| Spoken like someone who's never lost their pal at a
| festival
| bravoetch wrote:
| And doesn't see the potential sexy use-cases...
| zawaideh wrote:
| 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.
| Ray20 wrote:
| 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.
| cyberax wrote:
| 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.
| adrianN wrote:
| Areas with censorship will simply ban such services and make it
| a crime to participate.
| alternatex wrote:
| Not inspired by FireChat?
| yetihehe wrote:
| 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?
| jakeinsdca wrote:
| imagine building a lightning client into this.
| rlt wrote:
| Lightning network depends on... the internet... so if both
| clients are on the internet why not just send messages over
| that?
| teiferer wrote:
| Privacy?
|
| "Just encrypt things" might be your reply. TOR folks have
| been fighting an uphill battle for ages with that as
| their main weapon.
| webXL wrote:
| eCash would be better, but someone needs to be connected to
| the mint.
| t43562 wrote:
| 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.
| yetihehe wrote:
| 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".
| immibis wrote:
| 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.
| BiteCode_dev wrote:
| Delta chat does this, without the micropayment.
| linuxandrew wrote:
| 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
| shakna wrote:
| 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
| hashworks wrote:
| Delta Chat can transfer messages using a Bluetooth Mesh
| Network? That's new to me.
| out_of_protocol wrote:
| > 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
| krunck wrote:
| Bitmessage tried this. Defunct now I think.
| notfish wrote:
| 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.
| tgv wrote:
| 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.
| iSnow wrote:
| 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.
| fragmede wrote:
| it's a real life application where a Blockchain based
| solution does actually make sense, believe it or not.
| kosolam wrote:
| 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
| glitchc wrote:
| To make this work you need to be able to connect to the
| public blockchain, which of course requires internet
| access.
| kosolam wrote:
| Absolutely, to deposit and withdraw. But relay can be
| done without the Internet.
| glitchc wrote:
| To claim payment for services too. You've created a new
| problem that does nothing to solve the original problem.
| kosolam wrote:
| I gather you aren't familiar very well with smart
| contracts, are you?
| glitchc wrote:
| 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.
| kosolam wrote:
| 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".
| atoav wrote:
| 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.
| hackpelican wrote:
| 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?
| 4gotunameagain wrote:
| This is a problem solved multiple times in the past.
|
| Look up "distributed peer to peer" e.g. kademlia
| immibis wrote:
| Kademlia relies on an already existing all-to-all mesh (the
| internet). Nobody has created an actual mesh routing
| protocol which works very well.
| hummuscience wrote:
| Get Uber drivers/taxis, truck drivers, ups/amazon delivery
| people etc. As your relay devices (and gives them extra cash
| for driving around)
| mschuster91 wrote:
| basically, a user friendly and publicly accessible variant of
| APRS for ham radio?
| akrymski wrote:
| 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.
| econ wrote:
| If you are going to do a payment system all other things come
| second.
| snickerer wrote:
| 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.
| Calwestjobs wrote:
| 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)
| Calwestjobs wrote:
| USA is in war with china right now. Companies and
| governments have different priorities in war.
| RiverCrochet wrote:
| > 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.
| Aurornis wrote:
| > 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.
| repeekad wrote:
| > 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
| deweller wrote:
| 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.
| pizzafeelsright wrote:
| 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.
| dylan604 wrote:
| > 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.
| MangoToupe wrote:
| You can still make a mistake _after_ the test transfer.
| rtkwe wrote:
| 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.
| dylan604 wrote:
| > 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
| altruios wrote:
| 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).
| immibis wrote:
| 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.
| 01HNNWZ0MV43FF wrote:
| Where's the API for sending and receiving USD?
| greyface- wrote:
| https://www.frbservices.org/financial-services/wires
|
| https://achdevguide.nacha.org/
| 0xOsprey wrote:
| We built this and it's live on devnet currently:
| https://paygo.wtf
|
| More details here if interested:
| https://x.com/0x_Osprey/status/1925299005191577921
| clarkmoody wrote:
| Many such cases with crypto. Moderately good idea powered by
| a token becomes a Ponzi.
| miketery wrote:
| In helium there was no input revenue. OP mentions payment to
| send. This is a very different scheme.
| rtkwe wrote:
| 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.
| 0xOsprey wrote:
| >>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
| simondanerd wrote:
| 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/
| rtkwe wrote:
| 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
| sneak wrote:
| 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.
| myself248 wrote:
| 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.
| immibis wrote:
| 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).
| N19PEDL2 wrote:
| 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.
| wildzzz wrote:
| 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.
| kiernan wrote:
| "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?
| concats wrote:
| Sounds like a solution looking for a problem.
| bullen wrote:
| 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
| huslage wrote:
| 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?
| teiferer wrote:
| 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.
| teiferer wrote:
| 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.
| bee_rider wrote:
| 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...
| clarkmoody wrote:
| 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.
| beefnugs wrote:
| 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
| immibis wrote:
| 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.
| immibis wrote:
| 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.
| immibis wrote:
| 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.
| 0xdeadbeefbabe wrote:
| Well it's a tough problem even before you start adding money to
| it.
| snickerdoodle12 wrote:
| 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.
| smartscience wrote:
| 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.
| marto1 wrote:
| > or is it just a neat academic toy
|
| The Internet was a neat academic toy at one point for whatever
| that's worth :-)
| Marlinski wrote:
| 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).
| hiatus wrote:
| > 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...
| poisonborz wrote:
| They relied only on scanning nearby id-s, without
| communication.
| DennisP wrote:
| 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.)
| elpakal wrote:
| https://ditto.live
| zhynn wrote:
| 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!
| rlt wrote:
| 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.
| nelsonfigueroa wrote:
| Yeah I noticed this too! The profile picture looked familiar.
| b33f wrote:
| It's not though, it's written by someone called nothankyou1
| https://github.com/jackjackbits/bitchat/graphs/contributors
| greyface- wrote:
| The commits, viewed outside of GitHub, have:
| Author: jack <no@no.no>
|
| He used a bogus `user.email` git config value, which GitHub
| matched to the nothankyou1 account.
| tschillaci wrote:
| This is a really exciting project! I love how it makes each
| message feel more valuable, like modern-day letters, but more
| convenient.
| geek_at wrote:
| Title should include "for the apple eco system"
| po1nt wrote:
| If we could bridge over Meshtastic, this would be so good.
| xvilka wrote:
| Too bad it's not cross-platform which makes any real use pretty
| limited.
| trklausss wrote:
| 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.
| tonnydourado wrote:
| Anyone else read it as "Bitch at"?
| thinkingemote wrote:
| Is the Web Bluetooth API good enough to do mesh stuff?
|
| So we could have localhost or offline websites doing this.
| ManuelKiessling wrote:
| Funny, I had a similar idea in 2010, from which nothing followed
| of course:
|
| https://imgur.com/a/VWiDBO3
| IshKebab wrote:
| This is one of those ideas that everyone has had.
| PeterStuer wrote:
| Reminds me of nntp, from back when the Internet wasn't 'always
| on' or fully connected.
| t43562 wrote:
| 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....
| wjholden wrote:
| 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.
| FerkiHN wrote:
| When will the Android release be ready?
| christophilus wrote:
| I read that name as "bitch at". I thought maybe it was one of
| those GPS collars for finding your runaway dog.
| delbronski wrote:
| bruh...
| kinow wrote:
| 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.).
| brightbeige wrote:
| "Did not work at all for my male dog. One star"
| avtar wrote:
| I assumed it was a subtle nod to an old irc client
| https://en.m.wikipedia.org/wiki/BitchX
| fluidcruft wrote:
| Same but I thought it was a place to yell and complain at
| people
| uptown wrote:
| Bridgefy is another player in the sparse, offline messaging
| space.
| rofiko wrote:
| .
| molszanski wrote:
| 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
| Beretta_Vexee wrote:
| 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.
| pizzafeelsright wrote:
| 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.
| elric wrote:
| 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.
| Beretta_Vexee wrote:
| 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.
| elric wrote:
| > 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.
| user9999999999 wrote:
| bitch@
| HumblyTossed wrote:
| I would love to see phone manufacturers start working on add LoRa
| to phones.
| thunkshift1 wrote:
| Who is nothankyou1? That guy is the real developer, dorsey just
| added some nonsense commits like a true manager.
| Fokamul wrote:
| 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 ;-)
| bad_haircut72 wrote:
| 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...
| rightbyte wrote:
| It took me like 12h to see the wordplay in the name.
| alexnewman wrote:
| Be cool if he added reed Solomon to do raid over the packets and
| send the replicas through multiple routes
| ramon156 wrote:
| Now someone build it on the AT protocol and call it bitchAT
| scirob wrote:
| 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
| franciscojs wrote:
| Looks like we have a new mesh comms solution every two weeks or
| so.
| jdelman wrote:
| 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).
| felishiagreen12 wrote:
| I never thought I'd be one of those people who gets scammed but
| it happened I lost a significant amount in crypto and tried
| everything I could to recover it Then I came across Recovery
| Expert and honestly, I had doubts But working with their team
| changed that They didn't just talk big they delivered No upfront
| fees clear communication and a serious commitment to getting my
| funds back Their blockchain knowledge and expertise did play a
| huge part in all this It felt like someone finally cared enough
| to help without playing games If you're in the same situation I
| recommend Recovery Experts without hesitation It's rare to find a
| genuine recovery company in this space and I'm grateful I did. If
| you've lost your assets you can reach them via email
| (recoveryexpert326@gmail com)
| DonHopkins wrote:
| Best name since expertsexchange.com and penisland.net !
| johnnyfiveplus wrote:
| 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?
| roadtoswe wrote:
| 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?
___________________________________________________________________
(page generated 2025-07-07 23:00 UTC)