SAFE Browser RFP

Nice, I look forward to it. IMO, one of the things I think the proposal should address is some abstractions which will make your browser app not the only one out there. Specifically, explain how you parse/use safe:// links, how you handle links to other protocols (e.g. HTTP) and that you’ll attempt some form of standardization around the exposed API to a JS-exposed safe API (wrt to permissions). Multi-browser interoperability is import here and I think very easy to do. Otherwise, devs will suffer lock-in if they build their “sites” around specific things in just your browser.


I totally agree and very possible since this application will be paid for by the community. One of many reasons developing applications by the community for the community will quickly become the standard. @cretz and the community as a whole…is there any other must have features you see?

1 Like

Concerning the proxy thing, please don’t use an external proxy. I keep pushing for the launcher to stop including a proxy or at the very least turn it off by default. I think the best way to do this is via an electron custom HTTP protocol (ref: You can see here how I did this and you can see here where I disable HTTP links (note, the app will no longer work due to API changes…it was just a POC).

Note, although we got this to put the protocol/webview in a different partition, until things like this and others are implemented, you cannot do a pure HTTP custom protocol. Instead, you just need to proxy to an HTTP server you have running to handle it. Although I never got far with it, my concept of this was a local HTTP server embedded in the browser that I proxied the requests to. To prevent being accessed by other things, I used a signature approach to ensure the request was from me, see here.


I’d put in a proposal myself, but I cannot be beholden to get the work done due to several other obligations. But happy to provide any opinions or answer any questions. Good luck!


Here is what we have (@PureF has the tech description) so far


Looks excellent Travis, and I like the “stretches”.

Another to consider maybe (and rather tempting since you are using electron): merging SAFEbeaker with SAFE Launcher so for most activity the user has just one desktop application with websites and Web Apps apps on the browser tabs.


I don’t know the details of that idea, but SAFE uses a relay_node for the client side already. So no need to use any more proxies IMO. What I got from the proxy thing we have right now, it that it’s a workaround because we mix SAFE with the main internet at the moment. If we have a browser to just surf SAFE no need for any proxy.

Another thing that comes in my mind is avoiding to much functionality. People might like a bridge and whatever with Firefox but do we really need it? People can run Firefox if the want to surf the normal internet and the SAFE browser for SAFE. Building bridges between the 2 might add safety risk.

Great to see you are working on this project btw, much appreciated.


End user retains total control, no stake holder model please. End user is the only stakeholder that matters here.


[quote="MrAnderson, post:22, topic:10141]…is there any other must have features

If I may suggest, I don’t know how hard it would be but an extension system like the one in chrome and firefox would be terrific.


I hear you loud and clear. Avoiding stake holder control is my primary goal for building this public utility; which will ultimately be purchased by the community. The professional developer at this stage (Only learned of SAFE after bidding on the work proposal) is only interested in being paid via at the time of completion; I have paid them a small amount for their time in developing this SAFE browser RFP. They have no interest in ownership of the application and has already agreed happily to the arrangement.

I have calculated current/past/future MAID value and factored in my personal financial risk, as well as for my time to lead this project and recruit talented programmers like @PureF to join the SAFEnetwork build out. I do not hold any ideas of ownership of the application and all licensing will be either GPL/MIT or whatever the dev’s have for the application we fork. All development will be done on Github. One main goal is to make this as open, adaptable and easy for future projects to build on.

So @Warren I please ask that as a possible “end user” of this project you consider supporting us with MAID so we can show the world there is value in recruiting talented developers and provide them with the resources they need. Then all of us can enjoy the return of a better, stronger network and community[quote=“polpolrene, post:26, topic:10141”]
Another thing that comes in my mind is avoiding to much functionality. People might like a bridge and whatever with Firefox but do we really need it? People can run Firefox if the want to surf the normal internet and the SAFE browser for SAFE. Building bridges between the 2 might add safety risk.

I couldn’t agree more; sometimes less is more. As you see in the proposal the main focus and basic program will be a SAFEnetwork browser that will be as tech agnostic and easy-to-use as possible so then later either us, or if we are lucky, many others will build out the added features like firefox sync, magic worm hole, file-system, Interledger (for blockchains, traditional payment assets, and SafeCoin).

I don’t anticipate a huge sudden burst of financial support on this first RFP, but I think it is good to state what is on the list of feature desires. If there was enough support from the start, then we would keep building and I would hire my second and third very capable pick of candidates I found while interviewing a couple dozen groups.

I’m picking up what you are putting down and I love it. One click on one install application…the holy grail “one grandma button.” I will get back to you on this one.


I have posted the proposal here:



One question from the RFP:

and also enable web applications to invoke the APIs exposed by the Launcher

This is, that sites should themselves be able to PUT/GET dynamically, correct? Ie, proxy all requests to the launcher. (safe://nfs to enable access to those apis…)


This is that the browser should itself expose the APIs, so the launcher is no longer needed here?

1 Like

Okay, after a weekend of research, I decided I should offer one up also!: SAFEr Browser(s) Proposal

1 Like

I see both proposals so far are suggesting an address scheme starting with safe://, mimicking the traditional http://

But as Sir Tim Berners Lee himslef admitted that the 2 slashes were a mistake, we do now have a unique opportunity to right him by using a simple and clearer safe: instead.

Would Maidsafe agree to specify this as a requirement to the RFP submitters ?


Interesting. For me the // is second nature now, and I’d wonder if removing it would be confusing.

I’m not against this per se. But any browser implementation should be consistent across the board. So if http:// is to be enabled, then to me safe:// should follow suit.

1 Like

Personally I’d have liked a browser based on firefox but I suppose that can come with time, that or a plugin of somekind. Also with the safe:// change would that not cause issues with compatibility between browsers? Not everyone will want to jump ship between browsers in order to use SAFE. Therefore sites should not be coded to be browser specific.

There’s no reason a browser could not support safe:// but also allow safe:

Problems arise when different browser implement different standards, so it would be important for everyone to adopt the same implementation whatever it is.


It would seem a good time to bed it down.

Maybe @cretz could comment on any purely technical aspects that may favor safe:// instead of safe:

I did this at SAFEr Browser(s) Proposal