The underlying concept behind this isn't much different from https://webtorrent.io/ (I am pretty sure this could've been built on top of the webtorrents protocol). I don't believe there are any insurmountable problems. Security, reliability etc have all been solved before.

But there's still no way you can make this faster than traditional CDNs (at the minimum you'll need an extra round trip to check for peers). As a matter of fact if my torrenting speed is any indication, it will be abysmally slow.

You probably won't be penny pinching over bandwidth cost when every 100ms of page load time costs you 1% in sales. http://blog.gigaspaces.com/amazon-found-every-100ms-of-laten...

This is an idea I've had for websites such as Wikipedia where consumer funding is the main source keeping it alive.

This could be great for a small niche of applications, but even for those, these points are still important.

Particularly on the consumer end, turning my device into a provider as well as a consumer of data is typically not my intention. It's forced seeding on all clients in a torrent sense, which not everyone wants to be a part of. Or for that matter, can be. In a world of data caps, turning my phone, tablet, or hotspot connected devices into a CDN has moral and fiscal implications that have to be considered.

From what i've heard from people managing the hosting and development of Wikipedia, this (using a P2P hosting solution) is mentioned very often, but very impractical to put in real world use. Hosting Wikipedia is quite cheap: most of the content is text and images, which lends itself very well for caching. Making sure people can edit it at high frequency and the transition to mobile use are far more complex, and not the things that P2P distribution would solve.

Exactly. Non profit organizations could benefit most of all here saving on infrastructure.

Security and reliability could probably be sorted using the Thin Client. For security could that not be done by validating the checksum of client received against some expected value only available on the real server? In terms of reliability you could say if not received after a very short amount of time, get from real server. Bandwidth I agree with you on for today because you don't know if someone is paying per MB or how it's working on their end. Under some scenarios you could cost someone real money. In a time when bandwidth is next to free for every one everywhere it may no matter but we're not there yet.

I don't think anyone is going to use this stuff any time soon in production but I do think the general idea is one that a lot of people have thought about and it's nice to see someone take a wack at it.

> Security : how do you guarantee that a client peer is not tinkering with the code it distributes further?

You could make a system involving digital signatures (EdDSA), but then "how do you trust which public key?" type questions mean this doesn't improve much.

If I'm understanding this right, you could include the public key in the web page itself, served over HTTPS. There's still a webpage being served from your server. It just delegates most of the resources to be accessed over webrtc.

Maybe Subresource Integrity[1] would be of interest.

[1] https://www.w3.org/TR/SRI/

Security: Sign every chunk served. Clients tampering with the chunks will invalidate the signatures. Not perfect, but not intractable.

If they built it as an Ethereum miner that ran in the browser, all of these problems would be solved (at some performance cost).

The homepage only talks about enabling viral spreading inside a corporation. In this context Bandwidth is not a problem anymore, and Security is greatly improved (while not full, there is a higher trust into machines inside the company)

For CDN-style content, IPFS is a much better route. This seems like a proof of concept really.