Two futures: Centralized versus Distributed Web

#1

Like most forward thinkers of our era, I have always regarded the Cloud as the antithesis of privacy.

But in the recent weeks, while architecting a content plataform for a client, I started to have some insights about the benefits of the Cloud. For example:

The centralized nature of the Cloud allows for security patches to be instantly deployed and enforced across the entire network. In contrast, clients of a Distributed Web are patched in a best-effort manner.

This led me to a crossroad…

If software is an ever evolving medium and software security is the engine of privacy, does not the Cloud, architecturally wise, offer the most privacy-potential a priori?

Which led me to this…

Perhaps the problems we see in the centralized model of the Cloud are not attributes of the architecture but attributes of implementations and services.

From this thought onward, I can easily increase the net benefits of the Cloud by adding up every other advantage of its architecture, like availability, cost, quality of service and ease of use.

If we contrast that with the gigantic amount of work that still needs to be done on the Distributed Web’s suite of technology to make it market-proof, the Cloud is clearly the best choice for any project that needs a robust, scalable and profitable model from day one.

That being said, I know that this is a bias that is product of the status quo. Big-tech uses every form of capital at its disposal to spread, evolve and make the Cloud model the only model. One example of that are browsers not having a pervasive and complete API for offline storage, which leads developers to gravitate towards centralized solutions, by pure lack of options.

However, the Cloud model can be a faster solution for the “network freedom” problem, if only we choose to build on the Cloud architecture without inheriting the legacy and undesirable service models that orbits around it.

What do you think? Can the Cloud model be the future of privacy? What am I missing?

#2

This is a very interesting topic @jonsecchis!

Privacy/security is one aspect of this debate, but there’s also availability, speed, and safety (not losing your data) that come into play.

Cloud applications are notoriously slow. We’ve become used to that, but early computers were able to perform some interactions faster that some present applications that work on the cloud. There was a narrow window of quick interactions between slow hard disks and cloud apps.

That alone and the costs these waiting times have for cognition should get us thinking about ways in which we can host the data near the devices where it’s used.

Personally, I’m a newbie in this topic. I’m trying to walk the path of making Lotu a PWA that bets on local data, synchonised between devices with CRDTs (I’m experimenting with Automerge).

And so far it’s being a minefield. I love the work that the decentralised web people are putting into this but all my past experience (and large parts of the tech stack I’m used to) is conspiring against this effort.

For once, I chose PWAs because I’m building a scrappy build the plane as you fly tool. I want a simple set up that allows me to roll small changes in minutes without bothering too much the lovely people who want to help me out test this. And also because when you’re a band of one and most of your past experience is on the Web, I don’t want to distract myself from working on what matters (if I was a Swift developer I’d probably do things very differently).

And I chose local data, because of clearly saying “I don’t want to lock you in”, but mainly because I want speed (instant changes) and interoperability between applications (I have the gut feeling that saving the data locally in publicised formats opens the door for mashups without too much formality as when you use server APIs).

But boy, it’s so hard. Sometimes I feel I’m working on a Frankestein. Allowing you to reference a local file in a Web App or to connect to a local machine from a Safari page in IOS are crazy rides, and the architecture always turns out to be more convoluted that I’m comfortable with.

In the future I’d love to see ways in which we can use remote served apps which work with local data and continue to operate when the network is off. The role I’d like to see the cloud play is that of places from which to broadcast programs and safe-keep local personal data, end-to-dnd encrypted. I know some people say this can also be done by peers in a fully decentralised Internet. Why not, all I say is, I’d like to start with storing the data locally, which I see as the number one priority.

#3

I think https://remotestorage.io/ addresses this really well. I integrate it with all of my apps to enable “local-first but cloud sync too”, and since it’s an open protocol + potentially self-hosted the data is not locked in. Also, the idea of each app writing to a personal storage is like a free built-in API.

#4

Hey @rosano, welcome!

By the way, I’m a big fan of your projects at https://rosano.ca/ (love https://hyperdraft.rosano.ca/en/write/ a note repository that operates like Notational Velocity).

Thanks for the pointer. I spent some time looking at this after finding your local-first apps, but I think I need to give it another look now.

1 Like
#5

From a privacy perspective, I don’t think the web stands a chance in comparison to local or distributed systems.

  1. A server always means there is at least one other party involved that you need to trust, often more than one. That is, if you intend to communicate with another party, at least one other party in addition to that, facilitating the communication in some way or another. Even if they offer E2E encryption, they still get metadata, and you might not be able know for sure if they actually implement E2E properly.
  2. Moving bits around is/will be more expensive than computing things locally. The speed with which computers still gain more compute power (CPU, GPU, other specialized chipsets) makes local computation cheaper and more efficient (in speed, energy-efficiency, cost, etc.) faster than dealing with latency and energy requirements for transferring bits to other computers for computation. Unless you need data that is stored somewhere else, in many cases it is already more efficient to compute locally, or it will be soon.
  3. Look at the web. It’s a mess. Security is one aspect, but all the tracking infrastructure probably plays a larger role with regards to privacy at this point. There’s tons of money poured into finding ever more ways to track and target you on the web, amidst all the counter measures some browser vendors try to introduce. The easier way to avoid this is to not play the game and do stuff locally, or fully distributed with peers you trust.

That all being said, there will always be use cases where classic centralized server systems will be the best fit. So I don’t think they’ll go away. I do hope we will find our way back to a more distributed internet, basically improved versions of the very early internet services that were designed to operate in a decentralized fashion.

So — as if often is when somebody comes with an A vs. B thesis — the answer is: both. :wink:

#6

Wow! That’s kind thank you. I’m surprised you found it as I haven’t tried to publicize it much. I will develop it more soon. I use it extensively every day.

I think the project needs some help with communication… When you look at the site it doesn’t give you a sense of how it feels to use it. Best way is to try any of the apps. Feel free to ask on their forums if you have questions.

There is also Tim Berners-Lee’s SOLID project which has similar objectives of ‘bring your own data storage’ + ‘optionally self-hosted’, and I think the people at https://fission.codes are thinking about these ideas as well. I tried SOLID but I think it’s still early to be used for a serious app. remoteStorage seems to place more value on local-first and ‘anonymous mode’ (not needing to sign in before using the app) and it’s likely more stable (been around for at least ten years).

Ideally there would be some kind of local network solution, as you were describing with your PWA, so that it would be possible to synchronize between without going through a server or the Internet.