That’s our approach with Beaker. We use peer-to-peer systems as much as possible, and then plug in servers as minimally as possible.
If I'm making a new system or setting policy for a government or other high-security minded client (like a political campaign, military contractor, activist group, or private intelligence corp) I need off the shelf stuff with zero known attack surface OR I need to individual vet every single offering within that protocol suite. This is why you can email members that work for The Government of Ontario, but they won't click on links to non-whitelisted places. The attack surface when clicking a link is fucking huuuuuge (pdf 0days anyone?), while the attack surface for loading an email is much smaller.
There are a ton of interesting web-replacements that hackers are playing around with right now, but the one that wins for the next web is the one that lets stupid people do whatever they want without worrying. In my opinion, 3rd party means worrying, and in an ideal world it would go away.
The irony of this whole thing is that I'm actively arguing against my own long-term interests. A structural change of the kind I advocate for would dramatically reduce the profitability of being in either data science or cybersecurity; both fields I have a foot in. But I don't care.
Securing the flow of information between people is too important to humanity's long term survival.
I think one other area that the Web hasn't tapped into enough is using protocol/scheme identifiers to introduce strong guarantees to URLs. You can compose schemes with a '+', so I think if you wanted an "on click guarantee" that a site is going to have certain security properties, you might try something like:
http+safe://.../ dat+safe://.../
And then the site would load in a "safe mode" which, like the "uninstalled" mode, is extremely limited in what it can do.
We’re not there yet, but Mozilla is making a very positive step in that direction, and hopefully other browser vendors will follow. If I were creating a new protocol, I would be doing it now, to “skate where the puck is going” as they say.
Everyone is a server is pretty much the opposite of "serverless". The article is just illustrating the migration path from traditional web assets from centralized servers and how you can use them in the distributed web.
A real life use case would be something like:
You want to build a financial tracking app in the distributed web. But your bank is the central source for your data. With the method shown in the article you could request the api endpoint from bank.com inside your p2p/Beaker app then load that data into local storage/a dat archive/memory and use it to track your data. Think mint but without giving your bank credentials to a 3rd party.