Discuss PR proposed/0018-launcher-as-rest-server/0018-launcher-as-local-rest-server.md

[happybeing]

I'm not sure if this is the place to start this off but can't find any discussion so far - maybe because this is still a PR? Sorry if I'm jumping the gun :-)

The scheme seems very sound and versatile and well thought out (although I can't comment on implementation as a RESTful server as I don't know the details of this).

I have some observations that relate to earlier proposals, including a couple from myself. These are not criticisms, but things I want to mention as relevant or state for clarification:

• Dynamic Web Apps/Sites: I think that it would be possible to extend this approach to provide for dynamic website support in a similar way to that proposed in my RFC PR SAFE browser plugin URL handling / dynamic HTML on client side. The purpose of that would be to allow a single URL to specify both the HTML file needed for rendering something, and the data object(s) it will render. For example, in the case of a blog these would correspond to the HTML that renders a blog post (e.g. the URL for blogpost.html) and the particular blog post content (e.g. a URL containing a post-id). I suggest that we consider if there are any things needed to ensure this could be added in a backwards compatible manner, and whether it is worth including from the start if it is not too onerous to do so - unless of course an alternative scheme is available, or we make a decision not to support this kind of web application. I'm assuming we do want to, but am not aware of MaidSafe's thinking on this kind of application/website.
• Invalid URL Handling: this scheme, using a TLD of ".safenet", would I think make it impractical to have a SAFE style URL that defaults to a real but conventional website address as in the forum discussion SAFE URL: use a real internet domain such as safenetwork.net because that would require us to own and enable ".safenet" as a real TLD which I think is not feasible due to cost (~$200k I think).
• TLD Vulnerability: related to the preceding point, what do we think about the possibility that someone (e.g. a government agency) might choose to register the ".safenet" TLD as a means to snoop on users visiting SAFE URLs without the RESTful server installed/running, or to set up a rival domain space that confuses users, and so on. A way to avoid this would be for the MaidSafe Foundation to register the ".safenet" TLD, but that would be expensive and I would think difficult for the Foundation to justify.
• safe://" format URLs: As I understand it this scheme alone would not allow support of "safe:" style URLs because a browser without a special extension would treat them as a search string and not invoke the RESTful server. If at some point we provide browser plugins or extensions that can intercept "safe:" URLs and forward them to the RESTful interface they could be supported, but the "cost" of doing this would be confusion through multiple URL formats which would need to be considered.

[dirvine]

Great stuff Mark, @rossmuir is looking to get more community involvement in RFC's so this is the place. Please do push discussion on these to get them as good as they can be. Feel free to poke, debate and help improve.

[hitman401]

@theWebalyst thanks for summing up your views.

Dynamic Web Apps/Sites, can be supported. With this approach, you can relate it to how the normal web works. For fetching dynamic contents you can make XHR requests to the api and get the data as needed. Exposing api for StructuredData will facilitate in creating your own data types on the network to play with. But for this cycle the development is restricted to NFS and DNs apis. If this is something that many devs wants in the first version itself, then we will try to serve the APis for structured data handling.

Invalid URL Handling, the suggestion you have made is good for a discussion. The TLD's can be compromised and converted to something like safenetwork.io/happybeing, safenetwork.io/blog.happybeing/, safenetwork.io/drive.happybeing/. But wont the TLD make it more readable happybeing.safenet, blog.happybeing.safenet? Would be good to know what others have to say about this.

[happybeing]

Thanks @krishnaIndia :-)

For fetching dynamic contents you can make XHR requests to the api and get the data as needed

This is important, but on its own wouldn't solve the problem I try to address in my RFC, which is how to supply a URL that describes two things: 1) the URL of the HTML page, and 2) the URL that contains the content to be rendered by the page (ie the location of the dynamic part of the page, such as the content of a blog post, in addition to the HTML "scaffolding" that surrounds it). You may have considered this but I can't see it in the RFC.

What I'm saying is needed is a way to pass the address of dynamic content in addition to the HTML, so for example the RFC gives this example HTTP request:

HTTP GET /v1/dns?domain=maidsafe&service=www&path=index.html

This I understand corresponds to the following URL typed into the browser:

http://maidsafe.safenet

So I think we also need to know that the launcher will allow parameters to be passed, which can then be picked up and used by the HTML (e.g. "index.html" in the above).

For example, suppose I have the following URL typed into a browser address bar:

http://blog.maidsafe.safenet/?postid=23

This allows an identifier or URL to be included as part of the browser URL, which is needed in order to tell "index.html" what data it is to access and render - such as the content of a blog post (or any arbitrary dynamic content for any page). At that point, I agree, an XFR request could be used to obtain the content.

The Launcher would need to know that "?postid=23" is not part of the SAFE URL, and can be ignored. Once the SAFE resource has loaded (e.g. maidsafe/blog/index.html) the HTML it contains will load into the web browser and its scripting will be able to access the value of postid through the JavaScript API of the browser, and then can make a subsequent XFR request to obtain the content corresponding to the blog post identified by postid=23.

Is that what you are catering for? If not, I don't understand if or how you're planning to support this kind of functionality.

[hitman401]

The Launcher would need to know that "?postid=23" is not part of the SAFE URL

This should be supported by default 😄 The URL on the browser won't be altered, the proxy will handle the changes internally and send the response back.

[vinipsmaker]

The Launcher would need to know that "?postid=23" is not part of the SAFE URL

This should be supported by default 😄 The URL on the browser won't be altered, the proxy will handle the changes internally and send the response back.

But this means that we're reserving some fields that the user won't be able to use like domain.

[happybeing]

his should be supported by default 😄 The URL on the browser won't be altered, the proxy will handle the changes internally and send the response back.

Ok thanks, please can you document this so we can see what the scheme is and pick up things like reserved values as @vinipsmaker points out. Thanks 😄

The Need for Speed!

I think for such sites to be workable, we need to be sure this is reasonably responsive and my feeling is that it will be slow because the post content access cannot start until index.html has loaded on the client and client side script executes.

For this reason, I suggested in my RFC that we consider the local backend interface (in this case it would be the launcher, previously it was the browser plugin), could be designed to understand
certain URL parameters and initiate access for them at the same time as for the HTML.

This would mean reserving some parameter values for prefetch-able URLs, what would be available more quickly when requested by the client script. Again, this is in my RFC but not referred to here yet 😄

I think it is important we do as much as we can to match existing web technologies for load times and responsiveness from the start - and this seems a relatively simple thing to do.

EDIT: We should also consider the implications for HTML pages which routinely contain multiple includes. Ideally we want these to be prefetch-able too. Allowing multiple pre-fetchable URLs to be specified with multiple parameters could solve this (e.g. ?prefetch1=blah&prefetch2=blahblah etc.)

[happybeing]

Structured Data Support

If this is something that many devs wants in the first version itself, then we will try to serve the APis for structured data handling.

It would help anyone trying to develop applications that need more than file storage to have early access to SD, so I vote for having this in the first launcher or very soon after. I would not want it to delay the first launcher, but it is important enough to try and include it if possible.

[hitman401]

But this means that we're reserving some fields that the user won't be able to use like domain.

@vinipsmaker, No we are not reserving any value here.

Only restrictions so far are, .safenet tld should be used for requests from browser. say vinipsmaker.safenet. This request will be handled by the proxy server and will be redirected to the local RESTFul server to fetch the file from the network.
So the vinipsmaker.safenet request will be translated by the proxy to invoke the RestFull API (HTTP GET /v1/dns?domain=vinpsmaker&service=www&path=index.html) for fetching file. The fetched file is served back to the browser.

Only reserved hostname will be api.safenet, the requests to api.safenet will be considered as direct RESTFul api calls and the proxy will simply redirect it to the local server (Nothing gets modified)

[hitman401]

it is important enough to try and include it if possible.

Sure @theWebalyst , will try to complete the estimate for the present plan and then try to squeze the SD Api if possible.

[vinipsmaker]

But this means that we're reserving some fields that the user won't be able to use like domain.

@vinipsmaker, No we are not reserving any value here.

Only restrictions so far are, .safenet tld should be used for requests from browser. say vinipsmaker.safenet. This request will be handled by the proxy server and will be redirected to the local RESTFul server to fetch the file from the network.
So the vinipsmaker.safenet request will be translated by the proxy to invoke the RestFull API (HTTP GET /v1/dns?domain=vinpsmaker&service=www&path=index.html) for fetching file. The fetched file is served back to the browser.

Only reserved hostname will be api.safenet, the requests to api.safenet will be considered as direct RESTFul api calls and the proxy will simply redirect it to the local server (Nothing gets modified)

Sorry, I haven't read the whole proposal, so I'm not in position of judging what it can and can not do. But I'd love if you can elaborate a bit further. When I commented "fields like domain", I meant fields on the query string (miscommunication on my part).

If the proxy intercepts maidsafe.safenet and converts to \dns\file?service=www&domain=maidsafe&file=index.html, then it looks to me that the query string fields domain, file and service are being reserved and cannot be used by the user/developer. For instance, what happens if the user types maidsafe.safenet?domain=mycustomvalue?

[afck]

Implemented.