Safe Browser Dev Updates (@v0.4.2)

Yeh, good ideas. I’ll get this worked in :thumbsup:

Hi is this version just a test version perhaps?

I’m having lots of trouble working on my SAFE web apps with it. SafeEditor doesn’t work, many of my bigbang sites don’t, and the only page I can really get working is my APP ZERO (all on alpha).

Really wanted to give a shot at working on a web-app version of the email software, but the firefox proxy was taken down and I can’t get anything to work right in the SAFE Browser so I’m feeling kind of stuck? (win/lin)

@WhiteOutMashups have you converted to using the version of safe-js bundled into the window object in the safe browser? or are you still trying to get calls to localhost to work?

The latter will not work on live safe: sites. You should be moving towards accessing the safe-js methods such as window.safeAuth.authorise().

You can test these against a localhost test site in the current 0.3.3 version of beaker (as noted here)

1 Like

Ok fine, but just so I understand, everyone’s moving in that direction for web apps since the proxy was removed? It’s the main option now, moving forward? That’s fine, but it means all web app devs will be pretty dependent on safe-js to stay current right? Lots of added pressure on you, sounds like, and I’m just remembering making SAFE-FS versions and we were waiting on safe-js updates each time we wanted to move forward

not saying anything bad against you, it’s totally human and totally understandable to not be 100% updated always, but it just seems to be moving back in that direction, yes?

side question, this means like in the JS DOM? That’s how it gets around the need for a proxy?

Thanks @joshuef , tried more just now, got a little farther, left you some questions in the other forum here.

I have a local version of APP ZERO I’m making with safe-js, so I have a folder on my desktop with all the safe-js files, and my index.html and this javascript file, all in my desktop folder.

All the files are together, so the safe-js parts should be working right? I just can’t seem to get the auth part working (which is what APP ZERO is all about :slight_smile: for anyone not following it)

Any and all help from anyone is very very much appreciated! Looking to get started with safe-js :smiley:

Sorry if that’s too many questions…

Just want to understand auth in safe-js :1234:

Maybe the tutorials will help here Will. I’m busy for now, but if you post your code I’m sure someone will jump in and help.

I’ve responded over there.

RE: window, yeh, as in the window object available to any running js on a page. You can access it via the console in the browser to test things out.

To get safe-js in beaker, via window, the site HAS to be uploaded (for security), but you can shim the window functionality so you can test locally, and just remove the polyfill for going live.

Heh, yeh, a lot more safe-js pressure :slight_smile: im working on improving its error flow and promisey-ness right now. So it should be smaller/smoother.

If anything is unclear in the docs, PRs are super welcome.

And I think more things like what you’re doing, more tutorial projects and examples will also help, * a lot*. So thanks for going through the pain :stuck_out_tongue:



Pre release of 0.3.6 can be found here:

This features the updated safe-js with better promise rejection and error parsing to give an informative error instead of the uninformative 400 Bad request.

This has only been updated for the ‘classic’ APIs so far.


Dev Update

It’s been a wee bit quiet on the Safe Browser updates as I’ve been knee deep in making some fundamental changes to enable the last stretch goal to be met. So I’m happy to say that I’ve got a working prototype hooking up beaker’s data storage APIs to the network :smiley:

The OverrideStorage Branch is still in heavy development (aka: pretty rough around the edges), but it enables SAFE storage of sitedata and settings APIs to the network. As well as retrieval of the same settings from the network on launch.

This has been a complicated process, working around some specifics of beaker, but I’ve got something going that doesn’t interfere too much with the core beaker code. And now that the patterns of internal data storage and retrieval are set, it’ll be a cleaner process getting the remaining APIs hooked up. (Which I’d hope to do this week).

There’s also a few extra things that are coming as part of this next batch of changes ( I won’t offer any built packages as yet, as everything needs to be solidified, tested and tweaked):

:white_check_mark: Add launcher detection (helper in safe-js), and appropriate notification.: There is now a SAFE Status page giving an overview of launcher status (Currently hacked together, but working as a POC).
:white_check_mark: Safe network sync for browser data. as noted above

  • Setup some helpful default ‘favourites’ for safe This will be bundled with an updated Bookmarks API using the safe network… all we need here is a list of default sites
  • ensure production environment used for builds & remove BeakerDev menu: This will need to be implemented as part of this update to ensure things are clean and clear for production users (removing some ‘dev’ portions of the interfaces.

And once that’s all in, I’ll be free to scope out the usability issues and other bugs currently up there (feel free to add more, or PR with changes :smiley: !)


I’ve also squashed a couple of safejs issues, which will be coming to the browser with the next big release. Highlights include:

I’ll continue working on safe-js as we go to improve it, so thanks for those catching bugs and pushing the repo forwards! (@happybeing, @ben)


For those interested in such things, I’ve worked around beakers’s sqlite dependency by implementing a redux store in the app for each beaker API. This makes things (for me at least… someone who does not like sql :stuck_out_tongue: ) cleaner and clearer and it also gives us a really simple object to be saving to the network (via using store.getState() whenever we update a change.

It also provides a simple and clean event listener to check for changes on pages. Although getting this to work in beaker which isn’t built in a fluxxy manner, has been a bit of a pain, it is all doable, which is good.


Some things I’ve come up against but don’t have an answer to, yet:

  • browser authToken… this can be used to auth as the browser on the network. Currently it’s saved nowhere for obvious reasons. This means a lot of re-auth with the network (at least when you’re testing :stuck_out_tongue: ). This isn’t necessarily a bad thing… It does make me wonder if any authenticator could have an ‘approve automagically’ option for trusted apps…?

  • saving data to the network: Currently I’m writing/fetching a whole file. I can see this being a costly exercise in terms of PUTs (especially as an update currently needs to remove/put a file on every update. I’m wondering if this should simply be done on an interval, instead on every update of state (as happens right now). I’m also wondering if, via new data structures on the network, there might be a better way… @Krishna @ben any thoughts there? (I haven’t had a chance to scope out the latest examples of data storage yet, so I’m pretty clueless. But I’m hoping to dive in once base Sync is done. )

  • default safe sites - As noted above, I’ll be implementing new base ‘favourites’… what should they be?


Josh this is superb, thanks.

Working with beaker and safe-js I’m aware of some of what you are up to (and very much appreciate your help and responsiveness), but expect most people aren’t aware of how busy you have been on beaker and how much impact all your work is going to have.

Beaker itself is shaping up really well, but it is also going to be a powerful enabling platform that lots of developers will enjoy using to build websites that are easily turned into apps, with just a bit of JavaScript and it’s built in safe-js.

Even at this very early stage, beaker plus safe-js is ready for business, and worth getting to grips with.

default safe sites - As noted above, I’ll be implementing new base ‘favourites’… what should they be?

I guess there are a few obvious ones like safe://diy.yvette and safe://dirvine (@dirvine?) we just need to ask if people are able to keep them working as the test networks proceed.

I will commit to maintaining safe://rsports, which will be an index to ports of remotestorage.js apps, so this could be listed in beaker or in an yvette index.

(safe://myfd.rsports is nearly working, but I’ll add more so if you list safe://rsports I can just add them to that).


Just saw the latest version of this and it looks great! Great job keeping that up for all these tests.

A few learning questions: what does “Out of 52 PublicIDs guessed, fell 15 websites” mean? Someone’s guessing PublicIDs?

And also, why doesn’t the “Enable Comments” button work for me? I’ve allowed the auth in my launcher, but this blue button below doesn’t do anything for me when I click it. I’d like to add my new link to the directory:

EDIT: this is for @davidpbrown if I remember correctly

Also, small suggestion on SAFE Browser, but whenever I have lots of tabs I sometimes do Ctrl+W to close my current tab, but instead the whole browser shuts down and quits.

Could this be fixed?

1 Like

Certainly could. There’s a few issues around shortcuts I’ll be looking into just after safesyc is all setup. So I’ll add this onto the pile there :thumbsup:


@joshuef, is there any live example on how to use the safe API? If not, how do you access the auth token to give to the createFile function?

1 Like

Yes… it’s guessed so an indication that it’s not some known detail from the network. It’s easier to guess those than you might expect… any truely obscure bitcoin-private-address-like PublicID would remain hidden through that obscurity. Most people use their forum username as publicid or otherwise some simple to guess instance. Service names are harder to guess and the more obscure ones are simply known from having been declared here on the forum… at one time or other. I retain memory of ones that existed in the past to try again on the next round.

If you look at the same site on Alpha, you’ll get a clearer sense of the route to them… most services are guessed as blog. home. or some such.

:bug: I don’t know what’s causing that but I had the same a couple of days into the test and I expect the devs must be aware, as the same appeared to happen in the previous test. I expect that its network related rather than browser. So, I can’t see what posts had been made to that now. (not a caching issue either it seems)

Edit: updated with rough scan => Out of 65 PublicIDs guessed, fell 19 websites

@joshuef To keep on topic, what I’d like from the browser is an option to refresh a page without needing to delete the cache… or that there is no cache for .html, to ensure that the content displayed is current.

1 Like

@DavidMtl I have a live example, complete with bugs :wink:

If you read the following github issue it includes a link to the code repo for my port of an example called myfavoritedrinks.

The issue describes how to run the code locally so you can either just read the code, or use the beaker debugger to see in detail what it does.

Unfortunately, for me, the beaker debugger has stopped working with the live version, so if you want to break/step/inspect you’ll have to clone and run locally.

Or you can just look at the code: search for safeNFS to find where it called the API.

Hope it helps.

1 Like

Thanks @happybeing.

I don’t understand why the response you get from the function window.safeAuth.authorise is the parsed response while the response I get is an object that contains a lot of stuff including the parsed response but under the child-object named _ parsedResponseBody_. In other words, the same function return two different things.

This is the content of what window.safeAuth.authorise returns for me, you can put it inside a json viewer to see it more clearly:

{"__parsedResponseBody__":{"permissions":[],"token":"eyJhbGciOiJIUzI1NiJ9.eyJpZCI6IkFkVll0MEppR3VXN0ZGS1Y1R1Fvc2srZE5VRFcwOC95WGtaRnZKYkduTVU9In0.J7n6V1sdP9cObe7EK-mfwXMtBE3vxfh0Z8RweRPtMqU"},"_abort":false,"_bytes":165,"_raw":[{"type":"Buffer","data":[123,34,116,111,107,101,110,34,58,34,101,121,74,104,98,71,99,105,79,105,74,73,85,122,73,49,78,105,74,57,46,101,121,74,112,90,67,73,54,73,107,70,107,86,108,108,48,77,69,112,112,82,51,86,88,78,48,90,71,83,49,89,49,82,49,70,118,99,50,115,114,90,69,53,86,82,70,99,119,79,67,57,53,87,71,116,97,82,110,90,75,89,107,100,117,84,86,85,57,73,110,48,46,74,55,110,54,86,49,115,100,80,57,99,79,98,101,55,69,75,45,109,102,119,88,77,116,66,69,51,118,120,102,104,48,90,56,82,119,101,82,80,116,77,113,85,34,44,34,112,101,114,109,105,115,115,105,111,110,115,34,58,91,93,125]}],"body":{"_events":{"end":[null]},"_eventsCount":3,"_readableState":{"awaitDrain":0,"buffer":{"head":null,"length":0,"tail":null},"decoder":null,"defaultEncoding":"utf8","emittedReadable":false,"encoding":null,"endEmitted":true,"ended":true,"flowing":true,"highWaterMark":16384,"length":0,"needReadable":false,"objectMode":false,"pipes":null,"pipesCount":0,"ranOut":false,"readableListening":false,"reading":false,"readingMore":false,"resumeScheduled":false,"sync":false},"_transformState":{"needTransform":false,"transforming":false,"writecb":null,"writechunk":null,"writeencoding":"buffer"},"_writableState":{"bufferProcessing":false,"bufferedRequest":null,"bufferedRequestCount":0,"corked":0,"corkedRequestsFree":{"entry":null,"next":null},"decodeStrings":true,"defaultEncoding":"utf8","ended":true,"ending":true,"errorEmitted":false,"finished":true,"highWaterMark":16384,"lastBufferedRequest":null,"length":0,"needDrain":false,"objectMode":false,"pendingcb":0,"prefinished":true,"sync":false,"writecb":null,"writelen":0,"writing":false},"allowHalfOpen":true,"domain":null,"readable":false,"writable":false},"bodyUsed":true,"headers":{"_headers":{"connection":["close"],"content-length":["165"],"content-type":["application/json; charset=utf-8"],"date":["Sun, 06 Nov 2016 18:08:50 GMT"],"etag":["W/\"a5-CRWmf6/5CtRdLV4/vZXv3g\""],"x-powered-by":["Express"]}},"ok":true,"size":0,"status":200,"statusText":"OK","timeout":0,"url":"http://localhost:8100/0.5/auth"}

My authorise code looks like this:

let app = {
       name: 'SimpleSafe2',
       id: 'davidmtl.simplesafe2',
       version: '0.0.1',
       vendor: 'davidmtl',
       permissions: [],

    window.safeAuth.authorise(app).then(function(res) {
      	console.log("Authorize response");
    }).catch(function(error_text) {
        console.log("ERROR:" + error_text);

Any idea @joshuef?

Probably a version issue, I know this kind of thing was modified in recent updates. I didn’t think Auth was one of the functions that changed, but I might just have forgotten. :slight_smile:

Ah, so Safe browser isn’t compatible with the alpha network anymore, correct?

EDIT: It works now. Had to update to the version 3.6 of the browser and launcher 9.3. Thanks!