Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

github.com

Post reply on HN
Print view View original

241–250 of 457 posts

Re: Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

#241

Post by Fokamul »

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 ;-)

Re: Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

#242

Post by immibis »

moneywaters wrote: post #96

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 messag…

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.

Re: Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

#243

Post by immibis »

repeekad wrote: post #218
Aurornis wrote: post #201

Earlier quoted context omitted.

> 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…

> 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

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.

Re: Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

#244

Post by immibis »

ijustlovemath wrote: post #193
Dr4kn wrote: post #109

Earlier quoted context omitted.

If your country shuts off Internet access for demonstrations this would work great.

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.

Re: Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

#245

Post by immibis »

myself248 wrote: post #205
moneywaters wrote: post #96

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 messag…

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…

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).

Re: Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

#246

Post by wildzzz »

N19PEDL2 wrote: post #206
moneywaters wrote: post #96

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 messag…

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 c…

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.

Re: Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

#247

Post by immibis »

yetihehe wrote: post #107
moneywaters wrote: post #96

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 messag…

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.

Re: Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

#249

Post by johnisgood »

pizzafeelsright wrote: post #234
deweller wrote: post #223

Earlier quoted context omitted.

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.

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.

[flagged]

Re: Bitchat – A decentralized messaging app that works over Bluetooth mesh networks

#250

Post by clarkmoody »

bee_rider wrote: post #236
moneywaters wrote: post #96

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 messag…

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…

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.
Post reply on HN