SAFE Browser – Feedback

Here is some feedback for @joshuef from @Krishna and the rest of the MaidSafe team :slight_smile:


1: It would be useful to make the “New tab” page more relevant to SAFE Network users. For example:

  • replacing the links in the top right corner (“Feedback & Discussion”, “Report Bug” and “Help”) with links specific to the SAFE Network and SAFE Browser (e.g. (you could link to a specific topic about SAFE Browser) and In SAFE-only mode, maybe http:// links should open in an external browser?
  • replacing the default favorites by safe:// websites (e.g. safe://diy.yvette/)
  • removing the “Dat Archives” link and the “Share Files” button

2: It would be advantageous for the browser to check whether SAFE Launcher is running when it starts.

3: It would be great if the browser could register a protocol handler with the operating system, so that safe:// can be opened by default with SAFE Browser

Application packaging

1: Please add the new SAFE Network logo, SVG version available here:

Comments from Francis:

The SAFE Network logo has been added in the last update.

In macOS it doesn’t look great because it shows up as a square (because of the white background). I’m thinking it could look good to have the SAFE Network logo in white and contained within a blue circle.

the current version is probably fine for now. someone who is good at graphics design could submit a better version of the application icon. in the browser “New tab” page it looks fine.

2: The packaged application should follow the naming convention (e.g. safe-browser-v0.3.0-win-x64)

Right now the names look like this:

  • SAFE.Beaker.Browser-0.3.0.dmg

The naming of the packages should be different and follow the convention from SAFE Launcher, SAFE Demo App, etc. And the application name could be made shorter (e.g. “SAFE Browser” instead of “SAFE Beaker Browser”).

  • safe-browser-v0.3.0-osx-x64.dmg

Also, when unzipping a file such as, the name of the folder should be safe-browser-v0.3.0-win-x64 instead of win-unpacked.


1: Please consider parsing and returning the responses from the APIs. At present it returns the entire response object of the fetch-isomorphic module

For example, the response can be:

  Status: 200,
  Headers: {
  Body: JSON or Buffer or Uint8Array

Comments from Krishna:

This is a mere example. Wanted to ensure that we can have a simple and clear response object.

This has to be designed with some thought put in. We might not even need a http response like structure. Can simply be the result itself.

If the response is JSON, then just the body of the response should do. ( resolve(obj) )

For operations like PUT and POST where there is no result returned, there won’t be any return value. ( resolve() )

Since the library is promised based, this approach can be useful.

If we are projecting the injected APIs as ajax equivalent then returning a simple response object is fine. But if the APIs are designed to be used as helper functions then returning the result object directly is preferred. This is just my opinion

Sometimes there is both a header and a body (e.g.

Yes, this is a case in which the binary data is streamed.

First the headers are sent and only after that the data is written from server.

If we are supporting streaming of data via callbacks, then the first data received in the callback can be the headers (metadata) of the file and then the actual contents can be sent via the callback.

This is just one approach.

2: Please consider improving the errors returned from the APIs and/or make them consistent so that the same response format can be used. The only difference will be to invoke Promise.reject and pass the response. This will improve the information that can be derived from the error messages at run time, since the status code and text are returned as a part of message string.

3: Please consider making the tokenKey in authorise function in safe-js mandatory for apps to pass, instead of setting a default value.

Comments from Krishna:

There is a bigger issue with this one IMO.

Consider App A on one tab is using a TOKEN = ‘auth_token’ to store and retrieve its auth token using the present local storage option provided in safe-js.

Another application can also use a same token name. This will also result in overriding the token and also to easily extract other applications authorisation token.

If App A chooses to randomly generate a token key, then for when the same application is opened in another tab a new authorisation request will have to be sent. This seems like a workaround but it would become an annoying UX

Suggestion from Francis:

maybe the name of the token could be generated by safe-js based on the value of so apps wouldn’t have the option to use another name, the token name would be generated by the browser based on the subdomain and the domain name of the current page (e.g. safe://blog.example/post.html would generate a token key called “blog.example”). and retrieving the token would also be based on (so you can’t retrieve a token from another site). do you think that would make sense?

Comment from Krishna:

I think so. But I am not sure, whether safe-js will be able to read the tab from which the request is originating. Can check with Josh

4: Streaming APIs like file read should be sent via callback instead of waiting for the entire content to download. It would be great if you could make this change.

Comment from Krishna:

Not able to think of a better alternative to callbacks. If there is a better alternative then it would make it even better.

5: Have not tested audio/video streaming using html5 controls. Based on the code, in safe_protocol registration it is only translating the URL scheme. In case of default video controls of HTML5, they use range headers for streaming.


Quick comment…

maybe the name of the token could be generated by safe-js based on the URL of the page?

I’m not sure I understand this fully, but if I do then this seems to require only one URL per app. It might be useful to encourage (enforce?) exactly one subdomain per app, but not one URL per app.

Apologies if I have the wrong end of the stick here :slight_smile:

I might be confused about what you’re confused with :stuck_out_tongue: but let me try to answer :slight_smile:

My suggestion is that the name of the token would be based on the subdomain and domain of the current page (e.g. if the current URL is “safe://blog.example/post.html” then the name of the token would be blog.example). To obtain this information, we can use

I changed the sentence to this:

maybe the name of the token could be generated by safe-js based on the value of

Is it clearer this way? The rest of the paragraph also makes it clearer:

so apps wouldn’t have the option to use another name, the token name would be generated by the browser based on the subdomain and the domain name of the current page (e.g. safe://blog.example/post.html would generate a token key called “blog.example”). and retrieving the token would also be based on (so you can’t retrieve a token from another site).

1 Like

Yes lol, :slight_smile: and that seems a good approach.

To avoid forcing this, but instead to just make it the easy, sensible, default, it might be worth providing a way for a developer to override this and pass the token between different subdomains where each subdomain corresponds to a related app (eg a multi-app office suite:,, etc).

Awesome, thanks.

Launcher checks and changing the default ‘new tab’ should come with the browser sync as we get around beaker’s default DB setup methods.

  1. API improvements: I’d started down this road when implementing tests, so I’ll be reworking these as safe-js goes forwards, as yeh returning the whole HTTP response is for sure overkill!

  2. Yup! I’ve begun this process and this’ll improve as I go though and get tests written. I’ll be reworking the resolve/reject functionalities then.

  3. tokenKey:

This is a bigger one it seems. Right now, the method in safe-js could be changed as @Krishna and @frabrunelle are suggested. For sure mandatory :thumbsup:, that makes sense.

But right now, as @Krishna notes, Beaker-safe-js cannot see the window itself, but it also does not have localStorage access at all. That’s why I shifted it and made it optional in the latest batch of changes, as the user will (currently) need to handle the response and save the token themselves anyway.

(Note: With localStorage there’s no real need for per domain tokens, as localStorage is stored on a per site basis anyway, so there’s no way a site could access another’s localStorage to gather any data. )

As the SAFEsync stretch comes this should enable us to have some methods for storing the key in the the browser’s data.

I think something like the suggestion makes a lot of sense though for beaker to user internally. I think the safe-js methods wont suffice here as they have no window method. But the beaker-plugin should be able to implement a helper function here to access the current window and get this information for key storage in beaker itself.

4: Makes sense.

5: I haven’t checked either, but good point and sometime I’ll add to the list to checkout :+1:

Thanks for the feedback, @krishna @frabrunelle !

If anyone else devving, has any suggestions for SBB/safe-js feel free to fire them in here also!


i installed and try to access websites using the browser, it keep showing this error:

"This site cant be reached


however using chrome i was able to access safe sites.

1 Like

yes I just came here to say the same thing, but I saw that someone already did. I get this quoted error frequently, and if it’s not that error then it’s:

Also, my APP ZERO only doesn’t work when I use it on SAFE Browser, and neither does SafeEditor. None of them are allowed to make auth requests, seems like. Nothing works to authenticate with the Alpha Launcher,

Works great on Firefox

What sites? The browser blocks http requests by default but this can be toggled in the File menu right now.

Is it built to use the safe browser APIs? What errors are you facing?

safe://safeeditor.davidmtl/ is throwing a ‘no such data’ error for me right now, so can’t test on the latest network.

1 Like

it was safe site which i created for test, however after configuring the proxy setting it works well on chrome however not on safe site.

You should not be using the proxy with the Safe Browser, it has safe-js methods built in (so you can use window.safeAuth.authorise() for example. Please check the readme: for more info.

1 Like

@whiteoutmashups @babilavena and anyone trying to use the SAFE Launcher API directly (IE not via safe-js)…

Here is my understanding after slack chat with Josh just now…

Direct HTTP access to SAFE Launcher API is not supported by SAFE Beaker. You must use safe-js only.

This is because the cross origin policy necessary for security (enforced within Beaker) means that access to SAFE Launcher via localhost:8100 will not work, because it breaks this policy and causes CORS errors.

The current SAFE API docs have not been updated to reflect this yet, so in the mean time refer to the SAFE API tutorials.