←back to thread

778 points ananddtyagi | 1 comments | | HN request time: 0.604s | source
Show context
moneywaters ◴[] No.44487086[source]
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?

replies(42): >>44487111 #>>44487126 #>>44487137 #>>44487162 #>>44487174 #>>44487219 #>>44487306 #>>44487401 #>>44487416 #>>44487875 #>>44487918 #>>44487994 #>>44488076 #>>44488351 #>>44488419 #>>44488612 #>>44488911 #>>44488986 #>>44489072 #>>44489735 #>>44489867 #>>44489897 #>>44489908 #>>44490304 #>>44490306 #>>44490405 #>>44490521 #>>44490567 #>>44490746 #>>44491021 #>>44491277 #>>44491800 #>>44491846 #>>44492206 #>>44492341 #>>44493200 #>>44493256 #>>44494750 #>>44494963 #>>44499945 #>>44515267 #>>44523816 #
iSnow ◴[] No.44487994[source]
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.
replies(2): >>44488104 #>>44488216 #
kosolam ◴[] No.44488216[source]
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
replies(2): >>44489694 #>>44495820 #
glitchc ◴[] No.44489694[source]
To make this work you need to be able to connect to the public blockchain, which of course requires internet access.
replies(1): >>44490742 #
kosolam ◴[] No.44490742[source]
Absolutely, to deposit and withdraw. But relay can be done without the Internet.
replies(2): >>44491122 #>>44505444 #
1. immibis ◴[] No.44505444[source]
The central smart contract is on the blockchain and can only be used if the internet is up. That's why you haven't solved anything here.

Your proposal is that since Alice and Bob can't communicate in real-time, either directly or indirectly, Alice does an interaction with a smart contract to lock some value and then Bob does an interaction with the same smart contract to unlock some value.

We can view the smart contract as some shared algorithm between Alice and Bob (if they are running their own nodes) or we can view it as something outside of them both (perhaps they are RPC customers of Infura). If Alice and Bob are running their own nodes, however those nodes manage to communicate with each other is a way they could just send the message to each other and not need a blockchain. And if they're both able to communicate with Infura, they could also swap Infura for Gmail and send each other a message the normal way (or if they can really only reach Infura for some reason, they can put their messages on the blockchain). But we are talking about designing systems that can work in scenarios where direct communication like this is impossible, and messages have to be forwarded hop-by-hop over a span of hours. You can't design a system for slow networking, that assumes the existence of a separate fast network just to run the payment system.

All nodes running a blockchain have to be in low-latency contact with each other. If you try to run Bitcoin in a network with multi-hour latency, you'll never reach consensus on which blocks are in the chain. You'll be hard-forking all over the place. You'd have to slow it down to, like, one block per week, but then it's far too slow to be useful for payments.

If a blockchain exists in such an environment, it exists on a tightly-coupled cluster of nearby nodes. And that cluster is pretty much the same as a single central node, from the perspective of the network. You don't gain anything by making it a cluster (except for redundancy, as usual).