Welcome @dyates You have it in a nutshell I think. There is little point in scenarios 1 to 3 IMO, though people are no doubt going to attempt them anyway. My my reason is that if you just build a bridge from a today’s broken web/internet (insecure, unstable, censor-able, hackable, DDoS’able etc.), you miss out on the purpose of SAFE (a secure, anonymous, decentralised alternative internet). [edit:] notwithstanding @sam_uk’s suggestion which is a great idea. I’m wrong as usual Most people here at the moment are interested in using SAFE to create a better alternative, rather than to bolt it onto the existing internet.
The plan for websites and web apps which live on SAFE is for MaidSafe to produce a browser plugin that gives access to the API.
The SAFE Browser Plugin will work seamlessly alongside the existing web, with a SAFE resource being accessed with a “safe:” prefix rather than “http:”, so “safe:blog.dyates” typed into the browser would retrieve your personal blog on SAFE. Or “safe:dyates/homepage” would retrieve the “index.html” file from a directory in your public SAFE storage, called “homepage” etc. An early version exists and can be played with (see MaidSafe Dev Update 31st August 2015).
You may be wondering, ok that works for a static website, but what about dynamic? This is still being worked on. I initiated a project (http://safepress.io) to provide the client side and help develop the way of working for this along with the community, and MaidSafe of course.
I had some preliminary thoughts on how this might work (see: SAFEpress Outline Design and RFC: SAFE browser plugin URL handling - dynamic HTML on client side) but these are stalled awaiting developments on the implementation of SAFE “Structured Data” which it appears might mean the network can do some of the backend processing after all (previously it looked like only REST style CRUD operations would be possible, but it seems we’ll have a way to enumerate documents too).
So part of SAFEpress is intended to figure out and provide a framework (Javascript+Plugin) to do the traditional backend stuff in the client, and the other to provide an interface frontend designers can use without caring about the backend. We’re stalled at the moment, as the initial SAFEpress volunteers have gone quiet, including myself (!) - I’ve been both too busy and awaiting details about Structured Data to continue with thinking much about the backend. We have a task list though, which anyone can work on, or add to on Trello, see: Trello There’s a good overview of SAFEpress at http://safepress.io with links to all the SAFEpress tools and resources, including a Google group for SAFEpress discussions.
EDIT: By the way Daniel, your English is excellent, and even those who are not so fluent are welcome and flourish here. And if you wish, you can add yourself to the Introduce Yourself topic.