I guess that the issue of trust or compromised other machines is solved for you.

I think that you have two approaches, which basically both amount to the same solution you already have, the (i)frame-based approach. The alternative to using (i)frames is to use HTTP redirects to the final (client) URLs and possibly to have a (very) dynamic DNS so you have some control over the caching and clients:

• The main server is both, the HTTP and DNS server for your domain (sadarax.com for example)
• All clients get a dynamic DNS entry and register themselves by GETting an URL crafted specially for them. Say client1.sadarax.com and client2.sadarax.com, while your main server is www.sadarax.com.
• All clients have a complete mirror of the website (provided by rsync) or the central server knows which clients have which resources available.
• The main server serves all "main" HTML pages but other, heavy URLs on the pages, like images, point to client1.sadarax.com or client2.sadarax.com, either randomly or whoever has the image available.
• Optionally, the clients could also completely host the site and proxy-cache all requests using Squid or a custom Perl webserver. That way you would trickle down only the requested parts of the website.

With that setup, you can distribute the website but still maintain central control over all clients by DNS because all adresses resolve through your central DNS server and should a client drop out or go rouge, you can simply update the DNS entry for that client to point to another IP address or your central server.

Also see the Fast Flux Networks for something quite similar to what you want, even though there, most of the content again comes from a central, "mothership" server.