How to develop for the SAFE Network (draft)

Aha, this sounds like the webview has crashed in the browser.

What are you loading? And is it a server that might be doing websocket requests? I’ve had a bad time with some versions of webpack with hot reloading. But there are workarounds if that’s the case. (I still haven’t been able to pin down exactly what is crashing the electron process)

1 Like

Hmmm, on a second reading that might not be it, @happybeing.

Something to try is, instead of using localhost, if you turn off SAFE Browsing in the file menu, can you access the site using the normal http://localhost:<port> url?

If you have a link to the code in question (feel free to pm me), I can give it a run and see if I can see what’s up.

1 Like

That made no difference, but the code I’m running is here, in ./deploy I’m running ws . -p 8000 and then visiting the URL localhost://p:8000

Thanks! :slight_smile:

Okay, it is indeed the webview crash :frowning:

I’ve filed an issue with electron for this a couple of weeks ago:

I thought it was related to requests and access-control headers, but it doesn’t look like you’re doing any. It’s for sure related to remoteStorage.js (taking it off the page and it loads). So that’s helpful.

And to be clear, this is related to the localhost protocol. So if it’s live it’ll probably work. Just super not helpful for local development. :frowning:

But this at least gives me something more to debug against to see if I can find more of the why as to this happening.


Hey @bochaco, when you have a moment can you look at the problem I had with the web hosting manager above. I updated the browser to 0.5.1 and the manager to 0.2.1 but still have the same problem.

EDIT: No rush, I’m running a web server to serve my files instead of uploading them with the manager so it’s not blocking.


Hi @DavidMtl, so my understanding is that you are building both applications yourself, can you please confirm you have this issue only when you build the applications yourself but they work fine if you use the packages we released?

Also, can you confirm that when you build them you set the NODE_ENV globally in your shell session rather than passing it to the command?
Just trying to make sure any of the commands in the build scripts are not missing the env var. E.g. I usually build the browser in Linux with NODE_ENV=dev yarn run burnthemall and it works fine like this, but I think you could have issues if you split the script steps like NODE_ENV=dev yarn install && yarn run rebuild && ...

1 Like

Is there a recommended way to write tests for SAFE browser applications (using Mocha or the like)?

Hey @bochaco, I just did a fresh clone on all projects. I build them all using NODE_ENV=dev to use the mock network. The browser works fine, I can load the safe_api_playground and it works. So this part is now working correctly. I can’t say what I did wrong before that made the safe_api stop working. I have a feeling it was just that I wasn’t “logged in” with the browser anymore… Anyway that works now.

The problem with the web_hosting_manager is still happening. As I said before, when I run the app, the safe_browser gets called into focus but doesn’t pop the authorization side window. The console shows the error I mentioned before.

I haven’t tried with the binaries as I’m trying to work with the mock network. I’ll dive a bit more into the code of the web_hosting manager and the browser to see if I can find the reason why the URL used by the browser doesn’t include the “safe://” protocol. Or maybe I’ll just try to hack my way past the problem…

Anyway, if anyone has any idea on how to fix this or if anyone can run the web hosting manager with a mock network let me know.



I was running into the same issue with Chrome repeatedly downloading safe_proxy.pac while browsing sites on Beaker. Apparently I had set up a proxy under my Ubuntu settings (it was needed before, but I don’t think it’s used anymore); removing the proxy setting fixed it instantly.


baby steps :slight_smile: !



@bochaco I get the following error message on a freshly cloned ‘safe-browser’ repository with command
NODE_ENV=dev yarn run burnthemall

error Fetch succeeded for undefined. However, extracting “” resulted in hash “496a9b46ffc32e050a5a636629dc4bd23d656de5”, which did not match the requested hash “93ff8377180dc84c046b8598a15b9cd61190437a”.

Do I something wrong, or is that something yet to be fixed in the repository?
I could replace them app/yarn.lock (also for safe-app, beaker-plugin-safe-authenticator,…) but maybe better to wait feedback before continuing.

EDIT: nevermind, solved after checkout of commit of yesterday.

Yeah, that’s because we are in the middle of the process of upgrading dependencies in all repositories with the new artifacts. You need to just upgrade the lock files by running yarn upgrade.


I’m getting the hash mismatch error for the browser now, too. I’m running off the alpha-2 tag. Paste below.

I suspect the code base frozen with the tag should be in lock step with the static file, but that isn’t happening for whatever reason. Perhaps it would be useful to establish a static file methodology used by CDNs where the file has its hash sum appended to the file name. e.g. beaker-plugin-safe-app-496a…de5.tgz and beaker-plugin-safe-app-93ff…37a.tgz. Never delete or override an old file name, just keep uploading versions with their hash appended. That way old versions of repo code still fetch the correct static hosted AWS file.

For reference:

mint@mint ~/Documents/project/repos/safe_browser $ yarn upgrade
yarn upgrade v1.0.2
success All of your dependencies are up to date.
Done in 6.10s.
mint@mint ~/Documents/project/repos/safe_browser $ yarn burnthemall
yarn burnthemall v1.0.2
error Fetch 
succeeded for undefined. However, extracting "
plugin-safe-app-0.3.0.tgz" resulted in hash "93ff8377180dc84c046b8598a15b9cd61190437a", which did not match the 
requested hash "496a9b46ffc32e050a5a636629dc4bd23d656de5".
mint@mint ~/Documents/project/repos/safe_browser $ git branch
* (HEAD detached at alpha-6)

I got the web_hosting_manager ready to go in the alpha-2 tag, but not the SAFE Browser.

1 Like

CC: @bochaco (20 char)

@BryanB, @Nigel, It seems that the tag was created just before the yarn files were updated on master, if you pull master now you should build it with no issues. We’ll need to fix the alpha-2 tag. Thanks!

1 Like

Thanks Gabriel appreciate the quick response

1 Like

Thanks @bochaco. Current master worked for getting the SAFE Browser up on mocknet.

1 Like

I have the master branch of SAFE Browser running on the mocknet. I was able to create a login and authenticate itself using a nonsense invite key. When I open the playground from the SAFE Browser, I get asked for auth and everything works as expected. So that’s good!

The above documentation suggests that the Web Hosting Manager can also run on mocknet. I downloaded the alpha-2 tag version of the examples repo. I set AUTH_ENV=dev and ran through the README. The app loads without error, GUI appears, the GUI says it needs auth, and then the SAFE Browser is brought to front. Nothing happens in the SAFE Browser: I see no request for authorisation as I did for the playground. I see no errors in the console for either the Browser or the Web Hosting Manager. I’m not sure how to troubleshoot this.

You need to set NODE_ENV=dev as oppossed to AUTH_ENV=dev

Sorry, I did not type that in my actual work; just a typo here in this forum. For the SAFE Browser, I used NODE_ENV=dev and was able to create a user using a fake invite token, which means mocknet was working. I used the same NODE_ENV=dev for Web Hosting Manager in my working environment, but encountered the problem described above. I don’t know how to confirm the Web Hosting Manager is using the mocknet though.