Disagree. To quote myself from above:
In summary, I think the browser should be the app, not the site. As for working like cookies and subdomains, I agree (as mentioned). Just my opinion.
Please, if possible, get rid of //. I have been annoyed of these for more than 20 years.
2 Likes
I donāt like the idea of the SAFE browser to be built using javascript as its a hell of an ugly language and prone to lots of subtle nasty bugs but from what I see the community has decided so I will also support this proposal:(. I still think modding TOR browser should have been the way forward but from what I can see nobody has made a proposal for modding TOR, isnāt there anybody with the skills and the free time to just mod TOR browser? this way we would use a battle tested code base and not some new fancy eyecatching browser that will probably just die when the hype around js will dieā¦
1 Like
I see the lines blurring between any launcher and the browser. If the browser exposes sites to the API, what difference is there to that than any launcher? (other than perhaps that it doesnāt expose APIs on a local port? Which is also couldā¦)
Controlling read/write on a domain basis by the browser would negate spoofing app authorization by a safesite which you noted above.
I think the main thing I donāt see is, why would a SAFE browser limit the use of the SAFE APIs to directories controlled by the browser itself when it doesnāt need to? If we have a permission system for access (which makes a lot of sense), why would we force the apps to be sandboxed?
This would prevent an app developer (App on a mobile for example) having a native app experience, but also offering similar things through a safesite, as their data wouldnāt be accessible (without directly accessing any launcher).
If then thereās a permission system in the browser/launcherā¦ And thereās no way of spoofing your domain. What advantageous do we get by limiting SAFE access?
5 Likes
This is kind of self-answering. To rephrase: āIf we are going to sandbox, why sandbox?ā I am saying the permission system is enough, so donāt force a sandbox per se. But they are one in the same IMO. Open or close the permission system as much as you want, not sure what that has to do with the launcher or treating sites as separate apps. I donāt mind if you allow sites to access areas outside of themselves when granted that permission by the userā¦I was just giving suggestions for āsite-specificā storage.
Nobody said limit access absolutely. Just put permissions around it, no big deal how open you make it so long as the user gets to opt in at a granular level, and I would never have suggested otherwise. Again, please donāt confuse a suggestion for how you are going to handle site-specific data (something which you should also support) with a requirement to ONLY do that.
Also, although it goes without saying, āpermission system in the browser/launcherā kinda muddles the point. There is no real permission system in the launcher from my perspective.
3 Likes
Cool, thanks for clarifying!
Heh, yeh, it does a wee bit, eh 
Thanks for bearing with me!
This threadās really helping me get my ideas in check for an initial implementation. If other devs (@whiteoutmashups youāre building things, no?) Have thoughts on any of this or other SAFEBrowser things. Iām keen to hear them!
3 Likes
Nice work again team. Sounds exciting changes!
Firefox 48 released today now runs mulitprocess and is the first production release of Rust from them. Is the Rust implementation a direction of interest. Shipping Rust in Firefox - Mozilla Hacks - the Web developer blog
8 Likes
Yeh I read that! Super interesting. I do need to get down to learning Rust one of these days.
4 Likes
Thatās cool, more evidence that Rust has a bright future. Right now though there are hardly any jobs (in the freelance or full-time sense of the word) for Rust. So, Iām building my C++ skills (as the nearest thing) in order to move out of wannabe to paid developer status, with Rust work as a future milestone.
5 Likes
I was hoping to join this discussion couple of days before itself . But few issues from the launcher kept me busy for more time than I expected. Apology for joining the discussion very late 
Do correct me in places where my understanding is wrong. Here are my questions
1. Brave or Beaker
Looks like both Brave and Beaker take a similar approach. Do you reckon this will be a major hit for maintainability?
2. CORS vs API exposure
I do like the approach of providing the APIs as JS functions injected into the browser window under a safe (some common) namespace, which applications can use to make requests. I am sure this can also be easily catered in mobile and other platforms too. This will also help in having a standard approach across web platforms.
If people want to use standard browsers, then the same can also be catered using browser specific extensions AFIK as a workaround.
Managing the updates (version changes) between launcher and the browser can be a bit tricky. Needs some more thought on how to manage those. This is trivial at this point of time.
3. Permissions
My thoughts would be to leave the permission mechanism to launcher itself. Most of the sites/forums/blogs allow to read through the public content without any sign up, Only when we decide to post/comment we are required to authorise. So in such cases the app should be treated as a new authorisation granted by the user. Whether it is a standalone application or a web application, the user should be able to manage the permissions granted ideally from one place.
Also if browser is treated as an app and if it is going to make the requests with its own authorised token on behalf of web apps, it would make it difficult to audit the origin of requests (Every log would simply say it is from Browser app).When the app reward mechanism are in place, it would make it even difficult to identify the applications. Or we would have to cater for platform specific implementations, which is not an ideal approach.
I am using the word app because SAFE sites wont need any authorisation to read public content which the browser can provide straight forward.
I might be missing some use cases, please do point me in the right direction if I am wrong here.
7 Likes
Iām looking at beaker for POC, and refining whatās needed to then implement this in Brave. Beakerās code base is a lot smaller, so should make it much quicker to get started and productive and get an initial browser for testing implementation details.
I think once the basics are underway, and custom protocol is working in Brave (this is the main blocker as it is right now), we could/should move main development there.
Youāre right that maintaining both is probably not needed. So I think we could make this call further down the line once weāve established what we want from a browser.
On which, Iād want to produce a set of functionality that you could easily hook into any browser or extension for a browser (the joy of working with JS browser implementations means the code should be really portable). Allowing for:
safe:protocol handling- SAFE API access
For 2. Iām leaning away from creating more protocols as described in the initial proposal and more towards (as you note) the idea of simply injecting the api as a global variable for SafeSites to access in the browser. Seems cleaner and simpler to me.
@Krishna_Kumar I see the latest launchers have a much more standalone API setup: https://github.com/maidsafe/safe_launcher/tree/master/app/api which is great!
Do you think we can look at extracting those into their own lib, that would then be a browser/launcher dependency? This should go some way to easing versioning for all dependencies.
I think some official lib for this would be a great step and useful tool for SafeSite devs (and weād expose this in the safe global in browsers).
Iām happy to fire in with setting this up if you all see value there. Not sure what your plans are at this stage thoughā¦
Also I snagged safe-js on npm, as a lib extracting the APIs from the old launcher, with this kind of aim in mind. Iāll happily give that up to replace with something more official 
Yeh, the more I think about this the more I think the browser should just be passing through requests to the API. Though when you have the API built into the browser, then the question of permissions (read/write) might become more pertinent. I would leave this aside for now though as itās a more general launcher/permissions question and not browser specific.
But if the browserās simply passing on to a launcher, to avoid spoofing of Auth/App Iām leaning towards the idea of limiting SafeSite auths via the domain (so sites no longer add a name to their auth objects, this is always handled by the browser, eg). @Krishna_Kumar can you see any problems with this approach?
5 Likes
Perhaps allowing other (elevated) apps to proxy authentication requests would be beneficial? The browser could then auth against the launcher when started, with web apps then auth via browser (to launcher). This could streamline UX, but keep launcher integration.
2 Likes
This is an internal module used by launcher and this is the actual ffi interface being exposed as an module. It is used by the REST server of launcher to make the calls according to the API being invoked. Maintaining this one to be backward compatible can be tough since it a low level api, but the HTTP REST APIs should be backward compatible and should support the older versions (at least the last version). It should be launcherās responsibility to make sure the APIs are backward compatible to best possibilities.
SAFE Browser is tool which is facilitating the data exchange between web apps and launcher. Ideally the data exchange between the app and launcher should also follow the common approach just like standalone applications. I mean, it would be good if the launcherās REST api is used just like all other applications for data exchange.
This is a great suggestion. I donāt see a problem with this approach. Probably we might need to think a little more on the practical use cases in regards to this. For example, I have a stand alone application with name myapp. But the public name myapp is not available. At present the launcher creates the app directory based on the name of the application. Say, if I create a different public name, my web app and standalone app will behave like two different applications. This is not a blocker, we can find workarounds or even revisit the authorisation payload. All I am trying to say is that, we need to think more use cases and see how best we can cater. I would also wish to explore few more options that can help us better here. I will post here, if I have an alternate plan (will try).
5 Likes
Forget the app I want the music!
Iāll just make my note that I disagree with this approach. I think the browser is an app and has different use cases than other apps. This includes different permission requirements (the launcher doesnāt have a permission system so why are we talking about it?), different API needs (the launcher is REST HTTP for everyone, why shouldnāt a JS environment provide an idiomatic wrapper especially since some things might need to be stored?), user preference storage requirements, etc. I really hope the launcher doesnāt get inundated with browser-specific needs. It already contains a proxy and the ability to be called from inside a browser which are very bad things IMO (and easily could have been separate apps). Also, it is way easier (and more performant in some cases) in node to handle streaming HTTP bytes than it is from browser-based JS and XHR. But of course if you provide an idiomatic JS API calling a callback w/ uint8arrays or whatever. This is just an example of how providing your API/abstraction layer for your needs can help.
Also, I really think the concept of āofficialā is going a bit too far. I donāt think you want one official browser, one official JS API lib, etc.
Just my personal opinions. I say whatever the community prefers should obviously prevail.
2 Likes
This is definitely bad and we are also not for this approach. I hope, @joshuef was taking about the browser injecting API to the window so the web apps can use to make API calls to the launcher (No proxy).
We are on the same process as you have quoted,
Inject the APIs to the browser window object. When an API is invoked, the SAFE browser would make a request to the REST server directly (nodejs) and pass the response back via a callback.
Will wait for @joshuef to correct if my understanding was wrong.
2 Likes
Sorry I confused things here by firing through the updated launcher code instead of the demo app. Unhelpful, I realise. I think I hadnāt yet had my coffee 
that day.
What I wanted to look at/point to was the demo app and itās use of the REST APIs (which has not changed). I was meaning that it might be a good move to use a single lib across any SAFE API utilising js-based app. (So demo app & the browser as it would be). As updating a single dependency should simplify maintenance, and also provide a useful, always-up-to-date, library for app devs.
Thereās been a couple of community versions aiming for this: (from @eblanshey safenet and myself with safe-js (linked above). Both are not up to date with latest API changes. Is there a plan for something like this from safe-core, @Krishna_Kumar ?
1 Like
Apologies, for slow replies the last days. My home internet has died Waiting on a technician and replying via my phone now.
Correct!
It doesnāt have oneā¦ yet. Itās good to chuck around ideas though as perhaps changes can be made that work for many situations and are desirable (I agree, it shouldnāt be updated with browser specific requestsā¦). Right now Iām just exploring options and hoping for feedback .
My point with permissions is that in the end, if the browser incorporates some launcher functionality (like access to SAFE network directly / reproducing API access; and this is looking quite far ahead) it is another version of the launcher. And as there could be many different versions of ātheā launcher if read/write perms is a desirable patter, at all, then should that be applied somehow in the launcher API?
As I understand, you note it sounds too browser specific. That seems like one reason not to then.
I wonder if it is too browser specific? You may want to prevent apps from writing willy-nilly to SAFE and using up your SAFEcoins. So perhaps itās something to consider for the launcher. (This is however getting off topic from the browser, scope. And probably deserves itās own thread / to be in the correct thread if there is one).
All Iām suggesting (badly worded in my post above) is if Safecore are maintaining and updating the API, and also writing software (demo app) to interact with that, it would be good if they utilised some library that could be easily integrated into other applications and would definitely be updated when the API changes.
It doesnāt have to be āofficialā, or Maidsafe produced. Iām just keen on there being something that can be consumed by app developers that will be as up to date as possible, and wondering if thatās a plan so farā¦
As for an āofficialā browserā¦ well right now the RFP was for this to be part of safe ācoreā, and so should definitely be maintained alongside any API changes. Iām perhaps using the phrase badly, when I just mean those bits of code that would be updated alongside core network changes, not that thereās one ācondonedā browser.
My ideal though, is to produce code / implementation patterns that could be utilised in any js-app (or browser / extension etc), so hopefully increasing the number of options of SAFE access we get to choose from.
1 Like
Yes! We completely agree here. (I recommend using Promises instead of callbacks, but close enough)
Also @joshuef, I have GitHub - cretz/safeclient.js: JS Client to the SAFE Launcher API but it is not updated for the latest version. As for the API you expose to the browser, I say just make it idiomatic to webapps (instead of matching 1:1 with the safe API, though it may end up being that way). And when you document it, any browser created can make an implementation.
Meh, I say once you have an app you can do a lot. I will say, now that the credential count has been reduced, I have strongly considered bypassing the safe launcher altogether for my ākillerā app and just statically linking the maidsafe libs. But I wont harp on that here.
2 Likes
I was just looking at what the calls are like to the maidsafe libs and it looked relatively straightforward. The two interfaces (rest and lib) looked closely aligned (as payload remains in json, from scanning the code).
As you need the library present for the launcher to function, it seems like a reasonable option to link directly to it. I assume the motivation to provide a REST API is to just make it easier?
It would be interesting to hear what the team recommend here and why.