SAFEr Browser(s) Proposal

Updated Update

This is an updated proposal to fund development of an initial SAFE Network browser.


Updates include:

  • Reimplementation of the original goal to produce a safe: protocol browser.
  • Addition of continuous integration and app packaging to basic development goals.
  • Removal of anonymous launcher integration stretch goal. The launcher will remain separate (for not, can be debated or added later if desired).
  • Addition of browser data stretch goal to integrate browser data sync to the network, instead of any data storage on a local device (ie: history/favourites/a ā€˜cookieā€™ system etc).

You can donate to the dev fund here:


Summary:

The browser will (initially) be a fork of Beaker, a simple browser that should allow for rapid prototyping and development.

Initial development will aim to get a usable, secure, safe-only browser in the communityā€™s hands, further goals will look to incorporate SAFE browser functionality for userā€™s data (eg. history/favourites).__

I have a Proof of Concept using Beaker working without the need for the proxy using a ā€˜safe://ā€™ protocol.

This build currently requires some build and technical know-how to run, which is described in the README.

The Beaker POC will be updated to use beakerā€™s plugin functionality for the safe: protocol and app builds, asap___

Description:

The browser will advance via a concept browser implementation in Beaker.( as itā€™s easier to work with a smaller codebase, iterations will be faster.)

The main aims of this development will be:

  1. Rapidly create a useable SAFE only browser. Utilising a safe: to denote access to the SAFE network.
  2. Create portable javascript code that should facilitate implementations in other browsers (via browser window js injection).

Should more features be required Iā€™d look at implementing them after all basic requirements of a SAFE browser have been met. (Two stretch goals are noted).

Known Limitations:

Beaker is a minimal browser, and so might not have all the functionality of larger browsers (itā€™s very minimal not as easily to ā€˜extendā€™ as Chrome, for example). But for an initial browser, it should be much faster to work with.

Initial Development goals.

  1. DONE: POC beaker browser, access the SAFE Network without needing the proxy.
  • Allow only SAFE network access in the browser.
  • Inject API endpoints into the browser window for webapps. This will allow launcher access as part of a standard SAFE Browser experience. (Likely via an updated version of safe-js).
  • Continuous integration setup to allow for testing and app packaging.

Budget:

Initial development goals can be achieved for 65,000 MaidSafeCoins. Progress will be reported at every goal (if not more frequently), ready for user testing and feedback.

I envisage a locked down SAFE-only beaker, sans proxy, ASAP (~ two weeks from start of development). Implementing APIs will require more testing to ensure itā€™s robust, and will follow thereafter (~ 2-4 weeks).

Stretch Goals:

  • 25,000 MaidSafeCoins: Implement clearnet ā€˜indicator / switchā€™. Enable clearnet access when desired via browser UI, to optionally re-enable clearnet browsing.
  • 35,000 MaidSafeCoins: SAFE browser sync Add history / favourites / cache / settings to the network and prevent local browser caching via saving browser data directly to the SAFE network, and preventing saving in the local browser.

Team:

@joshuef: Professional front-end web developer with 5+ years of experience. I work with a variety of web technologies, including nodejs and reactjs on a daily basis. Iā€™ve been working with SAFE more and more over the last months. safe-js being my first public project (that extracted launcher APIs into a javascript promise library for webapp development). And Iā€™m working on some simple distributed search implementations as well.

Iā€™ve been a forum member for a couple of years (or so) and Iā€™m pretty stoked to be able to finally use my skillset for something useful and SAFE!

Iā€™m planning to work on this 20 hours/week (1/2 time) time as needed to get through all funded development goals.

POC:

A Beaker POC, running without the need of the proxy is available here. Please note: this is not currently a fully secure experience. Normal HTTP requests are still enabled.

Complete app packages of the POC for windows/osx/ubuntu will follow asap once app purveying has been set up.

23 Likes

Hereā€™s a screen from beaker running with safe://

To translate your site to the new protocol is easy:

http://test.bluebird.safenet becomes safe://test.bluebird, or http://upsate.safenet becomes safe://upsate.

No proxy needed! (Just the launcher runningā€¦)

8 Likes

I think using different url formats could be a problem for different browser compatibility. Not everyone will be using the SAFE browser to surf SAFE.

In the end, both options would be available. (clearnet and SAFE), so normal links and safe links will work.

safe: would most definitely be on the SAFE network. Whereas xxx.safenet you never really knowā€¦

http://whatever.... would still work (when clearnet is enabled, is the end goal).

1 Like

Yes but this creates the problem of having to create two sites. One that is SAFE only and one that is clearnet compatible. What if I want to surf safe only sites but simply do not which to use the SAFE browser and stick with firefox or chrome or whatever browser I prefer?

Thatā€™s out of the remit of this SAFE browser proposal.

But any code created for this, should be easily portable to other browsers that utilize javascript.

The question of implementations there is trickier as certain browsers only allow certain things. (ie. not custom protocols like safe:).

So implementations there would be browser dependent. You can implement extensions for those browsers as you wish.

You can still use the proxy if you want .safenet. But this is a security risk (imagine your proxy is disabled for whatever reason, and you access a .safenet site. It still worksā€¦ but where is that code coming from?

Those can be used interchangeably with the beaker POC w/o proxy and firefox with proxy. No need to make two sites.

2 Likes

safe:// Looks really cool like a new brand and abandon the http:// !!!

6 Likes

safe: looks even cooler, by removing the baggage of //

15 Likes

Also props to @cretz for the protocol examples (SAFE Browser RFP - #23 by cretz) :thumbsup:

3 Likes

The world is used to this. they recognize the http:// so very small step to go to the safe:// even while it has no technical use.

4 Likes

I think, as @happybeing pointed out in the main RFP topic, safe: and safe:// should both be possible.

Iā€™m away from my computer just now so canā€™t check, but this might already work in beaker. If not, it shouldnā€™t be a lot of work to get this working.

4 Likes

Exactly, with safe: there can be no mistaking that Iā€™m on a different networkā€¦and that itā€™s built by cool guys who are dragging us into the future.

7 Likes

Yes and it bites deeper than that. Iā€™m sure youā€™ve heard people painfully enunciate their web address as: h t t p : / / w w w . m y s i t e . c o m

Pleeease maidsafe can we use this opportunity to disable the temptation to enunciate the ā€œforward space, forward spaceā€

So who really cares if itā€™s safe:// technically because we wont be typing it anyway, but keeping it clean for human communication purposesā€¦because less tech savvy folk tend to enunciate the whole address.

For me, to see safe: as default from a resolve, visually confirms Iā€™m on a totally different network and ensures the verbal communication of an address is short and concise.

I guess itā€™s gonna come down to another poll if there are no strong technical arguments for safe://

11 Likes

Iā€™m diggin this prop and I agree with safe:

4 Likes

Looks extremely promising @joshuef , great to see more ā€œsmartest guys in the roomā€ working this.

5 Likes

agree agree agree - // is not baggage, its familiarityā€¦ retain ā€œsafe://ā€ for comfort. Allow people time to adjust to familiarize with safenet, learn about it and adopt it. Then make the radical changes. Baby steps.

5 Likes

Yeh, if we can have both. Why the fudge not?

Iā€™ll be scoping this out when Iā€™m back at the casa this evening.

5 Likes

:ant: safe: :ant:

We should embrace every good opportunity to ease out of unnecessary clutter , http:// being one of them ,
even after years and decades , our elders and many ā€˜trogloditeā€™ users still struggle with these monsters ā€¦

4 Likes

Careful, brave may not be in a state worth forking, and since they roll their own electron (for now), you need to maintain a set of patches so you can constantly merge upstream changes when brave changes. If you want to go that far, you might just see if you can squeeze in an abstraction layer into brave.

Yes, custom protocols have many issues in Electron too. I can help you fight through some of the issues as I too have experienced them. But basically, you canā€™t use a separate webview partition if you donā€™t have the latest Electron. But even with a common partition, the custom protocol really just needs to be implemented as an HTTP handler which basically does a local loopback to an internal proxyā€¦because the HTTP handler does not give you enough freedom for things like setting headers or streaming responses well.

I say PLEASE PLEASE no! I may make a browser in the future, as might others. I do not believe we need a single blessed implementation. Rather we just need standards (e.g. safe://, a JS API, etc).

I do not suggest offering the launcher APIs as protocols. You need to stand in between the API anyways to allow users to approve the use of the API (of course, the user can permanently store permission allowances). I personally prefer a JS API exposed to webpages. Also, I strongly suggest being very granular in permission requests, e.g. ā€œWebpage at safe://whatever wants to do the following: * Read public files * Write app-specific filesā€, etc. Think of it as no different than the HTML5 location or microphone APIs in how they ask for permission (though the permissions may be more specific).

Edit: I should add that I do not believe individual webpages should register themselves as ā€œappsā€ (you can easily spoof an app by just knowing its id). Rather, everything is done by the browser as the browser app. To keep sites separate, you can offer site-specific sub folders, but I think thatā€™s overkill for now.

Canā€™t. Itā€™s a URL ā€œschemeā€ as strictly defined in the RFC. You donā€™t want to change that. In fact, in most cases you canā€™t and you donā€™t want to make everyoneā€™s URL parsers stop working. The original RFC that specified it may be older than some of the forum users here. In fact, for some fun reading that came out just the other day, see here which shows that the originator regrets the decision as can be seen here

My pleasure. I would be happy to code review as well (at least the functionality, not some strict standards like I subject my dayjob employees to :slight_smile: )

Overall, good proposal and POC IMO. I say both this one and the other one are right on with features. The devil, as always, is in the details.

9 Likes

Yeh, thatā€™s been my problem so far.

Yeh, Iā€™m with you here. Iā€™d rather produce a set of patterns that we can apply across the board in browsers or extensions.

My thinking here is that any protocol (or REST API) provided by the browser would simply forward responses to/from the launcher. So the browser would not be handling anything beyond that. The webapps can sort their own auth/permissions/storage out.

Rather, any protocol or API (which would need be accessible, so perhaps safe://nfs/<nfs-api-routes>) is made available in the browser to webapps. That just punts them to the launcher APIs, without exposing localhost/ports etc.

The question is more of how we best do that.

Awesome. Iā€™d quite excited to get in deeper and get some stuff done to review :smile:

1 Like