I'd use a mobile-sized computer with no radios, just ethernet, USB (for a keyboard) and HDMI (monitor).
Putting both in one package? just asking for troubles.
41–50 of 102 posts
I'd use a mobile-sized computer with no radios, just ethernet, USB (for a keyboard) and HDMI (monitor).
Putting both in one package? just asking for troubles.
This is just... weird. We have centralized services for a lot of reasons, but one of them is that they're more reliable than decentralized systems. Phones get lost, stolen, drowned, and crushed. People drive through tunnels or into mountains without cell signal. Batteries die. It seems patently absurd to think that a P2P network of handsets is somehow going to replace The Datacenter, on any timescale.
Google said in 2011 that a single Google search uses about 0.3Wh of power. A typical mobile phone battery has a capacity of about 12Wh. Peer-to-peer systems are almost always less efficient than client-server systems, often by a large factor. You do the math as to whether a peer-to-peer internet based on mobile phones is even remotely viable.
https://www.nytimes.com/2011/09/09/technology/google-details...
This is an idea that keeps coming back every 2 years or so. While it is enticing to think about, these ideas never manifest into anything. With most decentralized projects there usually hasn't been a big enough financial incentive to execute them.
Meanwhile Twitter could spend money like crazy for years on end because their goal was cornering the market. They can afford to operate at a loss of millions per year, whereas John Q Developer can spend a few hours a week in his free time. It's a very lopsided situation.
I noticed that the word "battery" doesn't appear anywhere in this post. Isn't conserving battery power one reason why we delegate so much to central services? That said, I think the wireless routers that a lot of us have in our homes could play an important role in this kind of decentralized Internet. They'd need to have more computing power than many wireless routers do, but that's OK because they're already plugged…
It seems like at this point we're describing "running a server at your house." I've been playing with this with a Raspberry Pi for a Plex server (could have gone cloud but why not just tape a Pi to the wall next to my router?), I think the idea has a lot of merit.
Keeping all those radios powered on and transmitting/receiving for mesh network servicing/upkeep is going to burn through battery pretty quick :(
Author here.... I'm actually really interested in what we can do about the battery situation. The vision I laid out is clearly more battery intensive than your average phone is today. I do have some ideas about breaking apart the compute and display components, allowing the compute (and wireless) to go in a bag (or something) and connect up to a hefty battery while the human interface components are lighter weight.
Earlier quoted context omitted.
Mesh networks unfortunately scale really poorly [1]: O(1/sqrt(N)). You really need a fat backbone to turn the topology into something more like a hypercube. [1] https://pdos.csail.mit.edu/papers/grid:mobicom01/paper.pdf
...for static ad hoc networks. GPS-based geographical routing would be a dynamic, constantly changing optimized mesh.
In practice who knows what kind of communication patterns you would get. Applications would probably evolve around the long distance limit if it existed, but it's hard to imagine not having backbone links. Most likely the meshes would stay relatively localized (and I believe there exist a number of regional wireless mesh networks out there serving real customers).
Keeping all those radios powered on and transmitting/receiving for mesh network servicing/upkeep is going to burn through battery pretty quick :(
Author here.... I'm actually really interested in what we can do about the battery situation. The vision I laid out is clearly more battery intensive than your average phone is today. I do have some ideas about breaking apart the compute and display components, allowing the compute (and wireless) to go in a bag (or something) and connect up to a hefty battery while the human interface components are lighter weight.
I have certainly noticed that USB charging ports have become commonplace in the past few years. Maybe it could become equally common to see wireless charging pads ubiquitously in public spaces? They aren't as energy-efficient as a wired charging solution, but you don't need to remember to bring a cable, and they can be neatly hidden in various kinds of furniture. The hardware isn't inherently that expensive, especially if it is standardized.
Portable "repeater" units with storage, compute, and larger (swappable?) batteries than fit in a phone might be another alternative. It could fit the same kind of use case that cellular tethers for laptops do today, except with a different purpose. Downside here is needing to bring an extra device with you for long excursions.
This is not a new idea. Apple already emphasises that they do all the machine learning on your own device and no data is sent to the cloud. But this approach only works well for a small class of problems. For other types of problems you need to look at data wholistically at a large scale in order to see patterns and you need a cloud service. But more importantly we know that complex services break once in a while. If…
[1] https://medium.com/syncedreview/federated-learning-the-futur...