Mozilla + NSF: A $2 Million Prize to Decentralize the Web

From reading the challenge it sounds like they’re mostly looking for wireless solutions involving both hardware and software. I’m not sure about the hardware piece, but IPFS seems well suited to software requirements for the first challenge – or the “Off-the-Grid Internet Challenge”.

Links:
https://blog.mozilla.org/blog/2017/06/21/2-million-prize-decentralize-web-apply-today/

3 Likes

Hiya!
I actually already had a post written up proposing adapting IPFS to do exactly what they describe here, by incorporating a mesh network architecture like in MeshKit.

The question becomes “what are the nodes, cause it drains people’s batteries too fast”, to which I say one simple thing:
Fully functional Cell Phones are common E-waste.

Imagine that, when you upgrade your cellphone, you could use a one-buttonpress OS program (glorified script) on your laptop to overwrite the phone’s OS/data with a stripped-down android that would dedicate all storage space to its IPFS node, not bother with an interactive interface, and regularly check a IPNS addr to try to pull the latest “official IPFSmeshnode release”. You now could have your old phone function as a public access wifi/bluetooth-driven IPFSmesh node, you just need power.

So if you can find somewhere to plug in your old, now-wiped phone and leave it behind- whether that’s intentional in your own house or in public plugs on the outside of govt buildings or on the spare plug near the AC unit behind the recently-built Starbucks in your neighborhood- you’ve contributed to the public, distributed internet rather than contributed to piles of burning E-waste wherever your phone would have otherwise ended up.

Here’s the original post w/ more exploration of the reasons why you would want to do this, and the technical problems I’d anticipate:

Hello!
Recent events such as the Turkish blocking of Wikipedia, frequent spontaneous failures of social media sites during times of critical need for oppressed populations like in the US, and newly announced conservative UK Govt plans to censor “sources of harm” underline an immediate compelling need for a decentralized internet architecture for the sourcing for data.
In addition, with the growing trend of failures of existing infrastructure to serve oppressed populations globally, the legalization of ISPs selling user data in the US, and constant threats to Net Neutrality, the need for a democratized internet infrastructure for node-to-node connectivity becomes visible.

IPFS is, of course, very well suited to decentralize the sourcing of data, but as is it is entirely dependent on existing hardware owned & operated by ISPs.

Mesh Networks like FireChat, however, provide the opportunity (when at sufficient density) to side channel around existing, possibly impaired or untrustworthy internet infrastructure. Handing off content from node to node with no expected heirarchy can even allow internet access within Temporary Autonomous Zones, creating subnetworks with intermittent contact to the grander internet yet which can be continuously used locally with no additional infrastructure necessary beyond regular cell phones.

  1. Are there any ongoing efforts to spin up an IPFS implementation for mesh network architectures, i.e. based off OpenGarden’s MeshKit? How could I participate in such a project?

  2. What problems would a nonheirarchical mesh network architecture pose for the IPFS algorithm? I am just a screb at IPFS, but here’s the ones I’d guess at from my out-of-date understanding.

I’m guessing the DHT table usage- with a multitude of concurrent requests going out at increasing distances, prioritizing locally- needs to change, as long-range connections do not necessarily exist. Does this result in categorical collapse of the algorithm?

In addition, I’m unsure how the inter-node market of data would interact with single nodes temporarily acquiring access to the larger internet and bringing it back to the sub-mesh? I’d expect during regular use of the closed-off local network most nodes would end up knowing the complete list of unsatisfied desired chunks across the network as a whole, and so in the temporary connection to the grander internet would greedily request all desired chunks in addition to those of regular use. This influx may be counterbalanced somewhat by the potential outflux of updates from within the sub-net.
However, upon returning that node to connect to the sub-net, it would be arriving with the chunks desired by all other nodes on that subnet. How would this sudden highly-concentrated content injection influence the network?

  1. Such a mesh network must have sufficiently broad deployment in order to see use. What efforts exist & obstacles remain for deploying ipfs nodes on cell phones assuming the deployment could be modified to use a meshnetwork for requests?

  2. The birth of simple, dirt-cheap, and small computers with built-in wifi present potential for the creation of “IPFS leeches”, that when plugged in to a power supply could simply on-their-own act as nodes for such a mesh network and for the IPFS network. Could an IPFS node be run on stripped-down version of Android on old phones? What about things like the 7$ computer chips w/ Wifi that are being built today?

1 Like

Note, btw, that the above proposal does not tackle distant communication, between dense-enough areas.

The above yields dense town-scale subnetworks of free internet via meshnet, but connecting the diff subnetworks together is an additional, unsolved problem. However, due to the structure of IPFS, that problem becomes “connect any node in set A to any node in set B”; on doing so (and assuming the flat architecture problem gets solved in IPFS that i mentioned before), would allow distant jumps to naturally fit in with the network.

I, personally, would advocate that this is a better use of the AM and FM-radio spectrums than how they are currently being used. One could imagine a second, larger-distance-scale meshnet of the different ham radio stations of each town or city requesting & passing IPFS chunks to each other, for further local distribution. This semi-federated architecture would rely on the local network to pass around regular/commonly shared sites (like IPFS is designed to do) and by only reaching out to distant locations once for any given address, dramatically cut down on long-distance traffic, thus hopefully fitting within the lower transmission rate of AM/FM radio. UPDATE: Ham radio currently sees use transmitting info like video, this would essentially just be a new ham radio protocol.

It also is a well-understood technology capable of being built with very very low technological proficiency & far more accessible resources relative to fiberoptic trunk lines; is already commonly deployed in many, many small towns, does not require intervening cabling (instead relying on EM propogation), and is seeing little current effective use (srsly, who uses actual radio these days). A starter Ham radio setup can be acquired by a single individual in the USA for around $300, making the establishment of such nodes a very reasonable task to gain access to distant internet.

This problem would involve the adaptation of IPFSmesh network protocols for use by ham radio stations to transmit to/from each other via encoding the IPFS requests instead as broadcasts.

I personally would be extremely interested in tackling such an endeavor.

There’s also Freifunk in Germany, and they’ve come pretty far with their local mesh nets (using modified routers/repeaters with specialized firmware). One of the problems is connecting the different Freifunk networks, e.g. Berlin’s with Hamburg’s etc. (At least, that was a problem last time I looked roughly a year ago.) At any rate, adapting IPFS for smaller scale mesh networks, whether ham radio or Freifunk, would be an interesting development.

EDIT: in Berlin at least they seem to be going for microwave-based connections for longer distances, which imho could be used to connect regional meshnets.

4 Likes

Disclaimer: I’m more of an IPFS enthusiast than an expert, but I enjoy thinking about this stuff.

I’m glad to hear others have already been thinking about this.

While it’s technically possible to run IPFS on Android devices, it doesn’t look ready for widespread use yet. Though as you said if the devices are just going to be plugged in and communicating over wifi (or some other radio) then the power draw and data usage concerns aren’t as relevant. The FireChat/MeshKit functionality looks much further along on mobile devices, but maybe that’s something IPFS on mobile devices could someday integrate with (or maybe build in similar mesh functionality on mobile devices).

Even with disconnected wifi mesh networks (I don’t know much right now about trying to use AM/FM spectrum for connecting computers), one of the things that came to mind while reading the challenge is that people have already built decentralized chat on top of IPFS (i.e., Orbit chat, examples at chat.ipfs.io and orbit.chat).

There even seems to have been some work on getting maps in IPFS. If whatever devices are used in this challenge were to cache some high-value IPFS applications like chat and maps while the internet was up, then when the long-distance links go down anyone around them in the same local mesh network should be able to have access to those applications and data. Given that both chat and maps are example services in the challenge that’s encouraging for IPFS.

It really seems like a lot of the work on the software side has already been done on this, what I’d imagine is needed is project management from a team that can put all of the pieces together (along with the hardware).

Maybe it’s naïve, but with Mozilla involved in the challenge it might be a good opportunity to show the value of IPFS and could maybe even spur native adoption at the browser level.

Hey! so I kinda lost today- did none of the work I was supposed to do- but here’s what I found:

A) MeshKit/Opengarden stuff and almost everything else is closed-source.

HOWEVER, batman-adv is open source, has been part of the official linux tree since 2.6.33, and:

  • supports connections via Bluetooth or Wifi (of course)
  • has 2 different node runmodes
    • master: integral to the network, higher power draw, constantly talking to each other, propogates data along
    • slave: essentially a leech- only ever demands things from the nearest master, not constantly polling/talking
  • master nodes can also be a “gateway” to connect the batman-adv net to more regular internet architecture (for example, your local Starbucks wifi or willing civillian participants)
  • is still seeing active development (with nightly builds)

note that because it is already in the official linux tree, Any Android version since Honeycomb (so 3+) should support it? I think it may depend on how the binary was built? (my knowledge of OS stuff is limited)

Architecture

SO this naturally lends itself to a 2-node-type mesh network:

  1. The Actual IPFS network, consisting of all the nearly-ewaste phones, which is using a libp2p setup that employs batman-adv in master (and potentially gateway, depending on the node location) mode; this forms a public local internet infrastructure of “BatMaster” meshnodes running real IPFSnodes on leftover consumer hardware. note that the libp2p modification would hopefully be cut down in magnitude-of-change because addressing in a batman-adv net apparently can be done with regular addressing means, according to the readme:

It emulates a virtual network switch of all nodes participating. Therefore all nodes appear to be link local, thus all higher operating protocols won’t be affected by any changes within the network. You can run almost any protocol above batman advanced, prominent examples are: IPv4, IPv6, DHCP, IPX.

  1. the actual, in use phones of users, whose batman-adv node is in slave mode, and which actually have a very simplistic IPFS-handling daemon that just requests from or pushes to the nearest BatMaster IPFSnode (which batman-adv facilitates)

While this network is local-only, one can imagine employing any of a multitude of long-distance connection technologies- ham radio across a range of frequencies/distances, or direct laserlight point-to-point connections, or anything- where each end of it can simply slot into the local batnet as another BatMaster node running an IPFSnode with tweaked routing preferences to ensure minimum unnecessary radio bandwidth consumption.

#Deploying:
Note, btw, that if Android is truly able to run batman-adv, this makes the process to turn an undesired phone into a BatMaster node:

  1. verify batman-adv is on it, installing a corresponding prebuilt android setup over it if necessary
  2. run batman-ctl on it to set it up appropriately (this could be an app, potentially)
  3. get the suitable IPFS daemon on it running our batman-adv-capable libp2p (this is a small tweak from the already existing android app)
  4. designate all the phone’s storage space for the node, purge old crap, etc
  5. plug in via charger into spare power outlets (maybe put it in a plastic baggie so it doesnt get wet :stuck_out_tongue: )

This would also mean that BatSlave nodes on user phones/laptops would need:

  1. have batmam-adv and setup using batman-ctl
  2. Install an app that takes ipfs intents and requests them from BatMaster nodes

Is this all?

Also, would anybody in the core IPFS devs team have perspective on the feasibility of doing a libp2p integration with batman-adv? This seems like incredibly low-hanging fruit with absolutely immense potential societal impact that is leagues more open (and trustworthy, and non-corruptible or non-controllable) than the for-profit meshnet-making groups I can find that would be likely to participate? From looking at the libp2p repos, I’m guessing @whyrusleeping , @daviddias and @lgierth would have he know-how to do this (hope it’s ok for me to tag y’all)

2 Likes

OK but due to the vulnerability of digital broadcast signals, AM/FM radio is not a waste of spectrum. Precipitation and wind make mincemeat of digital signals whereas the analog signal presents significantly less disruption under the same conditions. Maybe that’s one reason only 15% or less of TV viewers rely upon over-air digital broadcast. More channels at the price of interruption.