Looks like you are talking about a "distributed data system", where the OP (and me) were heading to the idea of a "personal website with social functions".

Those are very nearly the same thing.

Most websites and online services (and I've engineered several of them) are basically:

1. An application engine, which is a fancy term for "database wrapper script". Much of this can be dispensed with if you build a largely static site, though access control and some scripted / scheduled events are likely still necessary. This talks to ...

2. A data tier. Often multiple levels of caching and / or distributed data and or map reduce and / or nosql and / or database. Again, largely dispensible in a static site.

3. A lot of front-end caching and load balancing. The less content you actually have to serve, the better.

It's better to think of a personal cloud + feed syndication (pretty much my formulation as well, BTW) as a cache-tier seed. That is, whatever kit you're running pumps data out to a distributed caching framework (think DNS or bittorrent). If a request cannot be met from cache, or it's expired, then your origin gets a request. But if it can be, you're serving content without actually taking the hit. And if the caching is demand-responsive, then you actually have the situation where you get better at serving data the more requests there are. A DDoS would simply result in more caching peers feeding your data.

You also get the benefit that should your residential (or colo) link go down your cached data remain accessible online.

Law of large numbers says that any given user is going to have relatively little traffic, but when the vast searchlight of the Internet Hive Mind takes an interest in you, you're swamped. So the sensible thing to do is to set up nodes such that the serve both as origin for their own data and as chache peers for other nodes.

And I've got some sense of how activity levels distribute across users in social networks:

https://ello.co/dredmorbius/post/nAya9WqdemIoVuVWVOYQUQ

It's also possible that there might be a value in providing more robust caching services for others on a wider scale.

The remaining question is: what are the enabling technologies to make all of this happen?

∙ Reasonably inexpensive hardware.

∙ Reasonably inexpensive and reliable Internet connections.

∙ Zero-configuration software.

∙ Sufficiently compelling value proposition.

∙

As for your fridge running a Web server, you'd be amazed at what does. I've found all sorts of nutty stuff scanning networks, and a webserver is a trivially simple piece of software (there are kernel-space webservers and have been for over a decade).

The truth is that hardware costs are falling massively. The $35 Raspberry Pi has served 1,000 Web requests per second. A terrabyte MicroSD card will fit on your thumbnail. Power draw is around 5W.

https://www.jeremymorgan.com/blog/programming/raspberry-pi-w...
https://plus.google.com/+GuidoStepken/posts/9LGGyKASb8q

What you permit past your network firewall is your call, but my point is that we already are polluted with server-capable computers. The question is how to harness them.

As to the "providing this as a service" aspect: not everyone will, can, or wants to run their own server, no matter how zero-maintenance they are.

So, if your neighborhood school, or church, or community organization, or retail center, or local ISP, or other entity, wants to take care of doing this, and can handle user request by literally having them show up at the door, well, then all the better. It's not that you have to use a service such as this. But if that works for you, so much the better and power to you. My point as that this is an option, and that there might be ways to tie this to other reasonable but revenue-positive activities.