How does a mobile phone sync dats? The main drawback I see currently with beaker is their is no mobile version (for iPhone)
Mobile devices are slower, have less memory, and must consume less power than desktop, laptop, or server devices. To achieve good battery life they really need to be in an almost-off state most of the time. Add to this the fact that cellular data plans limit bandwidth and cellular networks are a lot slower than most land-line networks and you also have to be very efficient with the use of bandwidth.
This means that decentralized systems that rely on peer to peer participatory propagation of data or distributed compute just don't work well on mobile. Anything with P2P data propagation will use too much data plan and run the radio too much, shortening battery life, while anything with distributed compute will destroy battery life and turn your phone into a pocket hand warmer.
Mobile devices really are thin clients. I call them "dumb terminals for the cloud." Since the cloud is mainframe 2.0, mobile devices are the "glass TTY" (e.g. VT100) 2.0.
The best solution is probably not to fight the nature of mobile devices as thin clients but to tether them to stationary devices. But which stationary devices? Laptops are themselves mobile and are off half the time, and most people (myself included) no longer own desktops. I have a personal server but I'm a geek and a huge minority. Most people just do not own an always-on device.
Farming this out to random always-on devices is a security nightmare or at best is no better than the vertically integrated silo-ed cloud.
I see only three solutions:
(1) Create a niche for a personal always-on server type device and successfully market one to the end user. It would have to be open enough to allow the server side of 'apps' to be installed. Many have tried to do this but nothing has caught on.
(2) Create a mobile device that's designed to be a "real computer." With 5G coming the bandwidth for this might be on the way, but you'd also have to contend with battery life and heat dissipation. One avenue would be to split the CPU in two: a high-power burstable CPU and a low-power slow always-on CPU. Require the always-on parts of decentralized services to run there and as a result to be very optimized. The problem is that a mass-market mobile device is a huge undertaking. Another route might be to sell a snap-on case that carries an extra battery and also includes a mini-server CPU, RAM, storage, etc. This would make your phone a bit bulkier but if there are benefits / killer apps it could catch on.
(3) Solve the security problems inherent in appointing random stationary nodes to serve random mobile devices. This would probably involve a major innovation like fast scalable fully homomorphic encrypted virtual machines or really tough security enclave processors.
Maybe regulation can solve some of the problems with the current systems, but the idealist in me really wants to see provably transparent (open source) and secure solutions which don't require trust in the hardware so we can still make use of modern, efficient (federated) server farms without having to giving up control over our data.
It's actually worse than doubling. The nature of distributed systems means that participating in resources consumed normally triples resource consumption at least. I'm not aware of any approach to decentralization of services like Facebook, Twitter, etc. that would merely double it.
Your typical desktop or laptop has a lot of resources to spare. Your typical mobile device has none. Mobile promotes a client/server mainframe/dumb-term architecture for fundamental technical reasons.
The other problem is that we're in an era where it's very hard to market anything if you're not Google, Amazon, or Apple, and those firms have negative interest in promoting any form of decentralization.
> The mobile revolution is and has been by far the most powerful driver of centralization in the last 10-15 years.
Many of us who were active users of Skype in its earlier days (mid-2000s) might remember Skype's first attempt at a mobile client. They took all the distributed P2P goodness of the desktop client and tried to have that run on the mobile environment.
The result was sadly a smartphone app that was slow and rapidly drained your battery. For those of us with many Skype group chats open, the mobile client was basically unusable.
So Microsoft/Skype had to go back and rethink the mobile client. To your points in your reply... they made it a "thin client" with all the power in the centralized servers.
As they did that, it seemed from the outside that they determined over time that maintaining a desktop P2P source code and a mobile thin-client/server source code didn't make sense. And so ultimately the desktop P2P was abandoned and everything became client/server. (Which is the case now - Skype on your desktop is basically a wrapper for a web client.)
And so... the quest for a good mobile user experience wound up being one of the drivers for centralizing one of the original decentralized P2P apps. [1]
Good analysis!
[1] Yes, there were, I'm sure, many other contributing factors, including the issues around the supernodes that led to one of the major outages. And yes, I do realize that Skype, even its earliest form was NOT a completely-decentralized communications app. They did have a centralized mechanism for logins / authentication and also for PSTN gateways and other services.