SAFE Browser Update (0.2.8)


@frabrunelle has caught a couple of errors after updating function nomenclature to better match the API docs. I’ll sort these and push a new release this evening, so perhaps better to hold off on moving to 0.2.8 for now.

This weekend back from my tip I’ve been firing into safe-js with documentation and tests. So we’ve now got a fledgling test suit that should provide some stability for the js lib that’ll be powering app interactions in the browser.

safe-js documentation has been added for all 0.5 level APIs, and you can read it over at the repo there. Safe-js has also been updated with the foundations for some 0.6 API with some PRs from @Krishna, and the 0.2.8 version includes these, too.

Please feel free to PR with any improvements to safe-js, code, tests or documentation. Any changes to tested code should be passing those tests now.

App Packages

mac/linux -
windows -

Next up

Now that there’s a test suite for safe-js implemented, I can refocus on the browser implementations itself. I’ll be looking to:

  • Sort appveyor deployments to the same github release as travis (so we only have one link!)
  • Update beaker to beaker core latest version (0.3.5 as I write).
  • Add toggle for ‘safe’ mode and http request blocking.
  • Start browser data storage/sync to the SAFE network.
  • Improve safe-js tests and coverage.

Finally getting to look at this @joshuef and I’ve been wondering about applications supporting both legacy and Beaker browsers. As an app developer I just want to write one app, deploy it (locally for testing, or on SAFE network for users), and for it to work in both SAFE Beaker and legacy browsers.

I’m not sure, but thinking the way to do this will be to for the application to wrap the SAFE API using an object that supplies the same interface as safe-js, but which internally detects whether it is:

a) in SAFE Beaker, in which case it uses the ffi route to SAFE Launcher via window.safeAuth, or
b) in a legacy browser, in which case it uses the REST API and local proxy route to SAFE Launcher.

If this makes sense, is it something that you can help with?

It would need to be coordinated to stay up to date with both Beaker’s safe-js / ffi, and with the equivalent REST API. On the other hand, you/MaidSafe may have a policy of only supporting Beaker, and leaving it to app developers to provide legacy browser support (I am not clear on this issue: everything seems to suggest legacy browsers are being dropped by MaidSafe/Beaker, but AFAIK nobody has actually said this. Let me know if I’m wrong!) If legacy browsers are to be “unnoficial” only, obviously someone else would need to provide a separate JS library to provides this dual support.

Or, maybe there’s another solution!? :slight_smile:

EDIT: There also needs to be a sensible way for local development to be handled (e.g. using localhost as per this SB issue), before it makes sense for me to begin migrating to beaker’s safe-js API.

[@moderators I wanted to reply on new topic but that wasn’t available here]

1 Like

@happybeing what you propose here makes sense. You could build the app to use the same interfaces, and optionally include safe-js if you don’t detect window.safeAuth for example. Such a shim might well end up being useful for app developers.

Safe-js in a legacy browser would indeed use localhost, and for that to work we’ll need to modified CSP which I think is coming soon, as the proxy is removed from the launcher. Though I’m not sure exactly when. That change should make it a lot simpler to develop apps though using legacy browsers (via safe-js, so you have one clean interface), or SBB.

Does that make sense?

An aside: If legacy browsers are to work once the proxy is disabled, then there will be plugins needed, which I’d hope would include safe-js or some similar API for accessing the network, so ideally down the line, this wont be too complex a procedure for devs.

Thanks @joshuef, it makes sense but I think we need more clarity about what is coming and in what order, from MaidSafe, and what is being left outstanding. At the moment I’m stuck again, not sure whether safe-js is sensible for me at this point or not.

I’ll wait for the developer update and then see where we are with this - the proxy appears to have been removed so things may become clearer with that.

The latest version of the launcher already dropped local proxy support. And won’t be re-introduced because of discussed security problems. IF normal browser will be supported again (at some point), it will be through an addon which allows to put similarly strong security constrains on the tab as beaker does it right now (like blocking of clearnet, preventing cross-leaking). For the time being, beaker is the only supported platform.


Thanks @ben it’s very helpful to have this clarity. I’m not sure it will go down well with the community, but let’s see :wink:

Well, I personally also prefer my firefox over a chromium inside an electron app :wink: . So I doubt it will be long until there will be an addon…

1 Like

Oooooooookaayy :wink:

I did wonder about this, and nearly referenced you in my post for that reason.

What is CSP? :smile_cat:

1 Like