Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Could this technology be used to create a "shadow" internet/network/messaging service where devices connect and communicate directly with each other. This way governments can't just block internet access or services during demonstrations.


> this technology

XMPP over Zeroconf (https://xmpp.org/extensions/xep-0174.html) has already existed for many years and at least previously has been trivial to enable on Ubuntu (I haven't tried it recently).


Requires an underlying network infrastructure to communicate over. Not quite the same as disparate peer to peer wireless mesh.


It works with ad-hoc wifi with no other infrastructure requirement or Internet connection, just the same as AirDrop. What more do you require to meet your definition of "disparate peer to peer wireless mesh"?


I think the point is that most clients probably don't configure the ad-hoc network for you? Or do they?


I thought we were talking about enabling technologies, rather than specific clients, and that it's a given that a suitable and widely deployed client doesn't currently exist. I consider automatic configuration of an ad-hoc network to be a relatively trivial client implementation detail :)


> I consider automatic configuration of an ad-hoc network to be a relatively trivial client implementation detail

Your statement may be tongue-in-cheek, but this sort of attitude is why we don't have this deployed on devices en-masse. Non-technical users want something that just works with one tap, not something that requires them to manually set up an ad-hoc WiFi network every time they want to use it.


Sorry, I don't think I was clear. I'm saying that the technology exists and is capable and established. I had intended to acknowledge that client implementations and UX is exactly what we're missing. I'm not apologizing for that; I accept that this is the current state of affairs and that it is the sole reason we don't have this widely today.

My original point was simply that the technology exists, and pointing out that there isn't a decent client doesn't negate my point.

It is unfortunate that our ecosystem is arranged such that a decent client hasn't happened.


But Google doesn't want to allow wi-fi ad-hoc networking: https://web.archive.org/web/20160315070543/https://code.goog...


A government - or even just a sufficiently motivated individual - can trivially jam all phone, wifi, bluetooth etc communication.

Or they could just 'listen in' to record the signatures of all detected phones, so they can work out and identify who is in the crowd etc.

Military systems use frequency hopping etc and would be a more difficult target. But doubtless motivated governments could hamper their use in crowds too. Here's a fun comment I just found when I googled that: https://www.quora.com/Is-noise-jamming-an-AESA-radar-possibl...


Absolutely, but I can ask a bit more nuanced question.

In any society, there is state-"friendly" communication and state-"unfriendly" communication. Also there are state-"essential" communications like state-propoganda [1]. Is it possible to build communication networks that allow for secure and anonymous state-unfriendly communication, such that trivially jamming it also jams state-friendly and state-essential communications?

As you might realize, a yes answer to this question is sufficient for protestors communication needs. Not the harder question of completely unblockable communications - which as we know is impossible. Of course, in the real world, the answer to my question might not be a "yes/no" but a resource-tradeoff.

[1] which every country in the world democratic or dictorial engages in. If you don't agree, please read Manufacturing Consent.


I don't believe so. I think the state would be comfortable denying phone and wifi usage to protesters congregating in public places, and the state has plenty of 'state-essential' communication mediums like loudhailers, billboards, riot police beating their truncheons against their shields etc, to fall back on.

That air-drop does work in the Hong Kong protests really just says that the state wasn't really prepared, but they probably will be next time.

Although, really, China is so far ahead in the practical application of face recognition and making protesters disappear or arranging counter-riots etc that I guess airdrop is not really where they think the fight goes?


> I think the state would be comfortable denying phone and wifi usage to protesters congregating in public places

I don't entirely agree. It's a resource tradeoff scenario where the state has to expend political-capital (because they are also blocking people living nearby) to prevent the protestors from communicating. In fact, the protestors in Hong Kong have been protesting in different neighborhoods so non-protestors can see first hand the brutality of the state.

I agree with your larger point though that communication jamming is probably a minor point right now in the Chinese state's gameplan for dealing with these protests.


For what it’s worth, I have been able to get the Yggdrasil Network (https://yggdrasil-network.github.io) to peer over AWDL, allowing nearby Macs to mesh without even being connected to the same Wi-Fi network, or any network at all.

It’s not perfect - there are trade offs, like how the wireless performance is reduced somewhat when AWDL is active due to channel hopping and how AWDL expects a single node to play the role of clock sync source. It’s also not very well tested yet.

However, it works and in theory it allows an infrastructure-free IPv6 mesh network to be built ad-hoc.


Any chance you could throw together a quick blog post on this? Or maybe a quick gist; doesn't have to be polished.


Sure thing - I threw this together over the last hour or so: https://yggdrasil-network.github.io/2019/08/19/awdl.html


Thanks, that was an educational read. Much appreciated.


I would be very interested to learn more about this if you have any pointers.


Happy to help where I can. What would you like to know?


FireChat.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: