Please get in touch when you are ready to work on integration / fluidity across projects.
Our tests have primarily been around Firefox, Chrome, Safari and Opera (with the Droplet Test Network), but if your project succeeds (will support with part of my personal savings) then we will be very excited to begin developing around your Beaker browser as well.
Let us all push for a very out-of-the-box experience at SAFE Network launch, with access to files, an App Store, a browser, basic Decorum, early crypto trading platforms, and all the basics that a SAFE user would require.
A united SAFE community of developers will produce amazing things. All the flashy proprietary chrome/firefox plugins will come later as the value of the network/SafeCoin grows…we know they will build them and that will be fine for a specific end user. The thing that will make a huge difference to how things are done in SAFE is the user friendly ecosystem will already be built and be the core reason why the network and SafeCoin are growing in value.
Below is a set of notes and questions, numbered for easy response. Please don’t take them personally, they are all just my opinion. I have a million more items worth discussing, but I’ll try to keep the list short for now.
Please do not try to abstract SAFE into some common FS API. It has many more features that an abstraction can’t address. Also, it is highly unlikely that you will get benefit from this abstraction because it’s not like people are switching from IPFS to SAFE and vice versa frequently. Please just support all SAFE API features as minimally as possible. If an abstraction over different APIs is required, it can be done in a library. Also, as part of this project, please document the API in exact detail, because some of us may make our own browsers and we want interoperability
Please discuss how you plan to handle HTTP links/requests. Outright block them all and allow the user to open HTTP requests (that happen on the main frame only) in their browser (my preference)?
Please provide all of the features/permissions you plan to enable on the Electron web view.
Please discuss how the webpage will use the API and how you will ask the user for permission. Specifically looking for how granularly you store this information
Please provide information on how you are going to handle user login w/ the launcher. Is it going to be on first FS mutation request? On startup (my preference)?
Please provide information on how you are going to store state including user permission items and user auth success info. This is especially important in multi-user scenarios.
Please provide information on how you plan to handle web caching and state management (i.e. cookies, local storage, session storage, etc). I suggest no caching whatsoever and cookie and local storage management just like normal browsers do.
Please discuss the URL format. I strongly suggest safe://.
Please please please do not merge this application with the launcher. There is no real benefit (we can make installation easy by having your install fetch the launcher install if not already present on the system). It is a huge issue if this browser is embedded into maidsafe software for many reasons, the least of which is the folly of having a single, “blessed” implementation.
Thank you for the very thorough review. We will get started in addressing each excellent point.
@cretz you mentioned on the other thread about being open to consulting with the build. Is there a specific component or part of this you are most passionate about? You obviously have the right motivation and skill. If there is anyway I can make it easier for you to work on any part, let me know.
I am not interested in participating in the code (though I might make an alternate implementation if I get the time). However, I am happy to code review, give advice, test, etc as an outsider. The things I am most passionate about are basically what’s there in the notes. Mainly I just want extreme security, simplicity, and very few features If the entire (granularly opt-in) API is exposed to site devs, they can do wonders. I look forward to seeing the updates, thanks!
Lets start with the simple scalpel first and then build the complicated Swiss-army knife.
I think it would help with adoption if the Launcher had a built in browser that just worked right out of the box. The browser and launcher should be one in the same. This will let the user know that the Safe Network works just like their old internet and that SAFE is not HTTP and that it is a new protocol.
Making it usable by your grandmother is a matter of the user interface, (in particular, its default configuration) and does not conflict with making it extensible to an arbitrary number of and types of networks.
You have me getting stomach cramps from laughing, I totally get it and feel that way sometimes. My grandmother is a great use-case for me though, because she is a brilliantly smart person (how many 80 year olds do you know that email) who taught school for thirty years. She apologizes all the time and says she’s an idiot, but my response is often “grandma I was the idiot who assumed you would be able to use lastpass with yubikey 2FA and also their password generator (So when her “grandmapassword” gets hacked she doesn’t lose access to everything).” I come across tech all the time that I think would make her life easier, but I have to remember why she uses the computer. She wants to communicate with family and friends and work on her genealogy tree and she doesn’t want to keep getting pop up screens that tell her the computer is infected with viruses (click here for example)…that is it. Even at this most rudimentary use I think there is great promise for SAFE.
Totally agree and hopefully we build something that can have extensibility for an infinite amount of networks. If we finish this initial implementation and the community speaks by financially supporting further features then I will hire whoever needs to be hired to keep doing this same approach; over and over. Sooner or later talented developers will realize they can work directly for the community and don’t need people like me…and that is great too.
Wow, already close to half of what would be required from the community to move forward. 45k MAID from MaidSafe and 45k MAID from community and just between the two of you (assuming max stated amount) 20k is almost half way. This is exciting stuff!
This, to my eyes, is key in order to stay within the safety features that the Safe network provides. One should be able to copy external links to the clipboard and do whatever they like with it outside of the safe browser, or the safe browser could provide a way to call an external browser using context menu. ( like, right mouse button or hovering pops a dialog saying "open this link with (xyz) browser ? , xyz being defined in preferences. ).
Other than these features, http requests to the legacy internet should be ignored by the code.
Very pleased to see that someone takes the plunge !
Creating a full-fledged module other than copies of the FS, will require a deep immersion into the BEAKER code, as well as support from the author that is currently not possible, therefore, within the given timeframe and budget that seems unlikely. This will also require a code processing, as well as his careful study, which is quite difficult to do, given the reluctance to help by the author.
We are all for @PaulFrazee being rewarded for your efforts on this portion; if you have the time and the community thinks it is worth it at this stage to fund. If you are interested, please include what would be required to complete this portion with regard to time and cost.
I do not know yet how it is implemented in BEAKER. We will follow up on this at a later time. Any suggestions on this section that will stream line our work would be greatly appreciated.
This is implemented in Launcher API on TOKENS and AUTH level tokens are stored in encrypted form in a cookie.
They will be stored in encrypted form in the cookies, if BEAKER allows you to work with cookies.
Yes, they will be stored in cookies.
9.I agree. But I do not know yet how it is implemented in the Beaker.
The browser will communicate with LAUNCHER through the API as a standalone application.
The implementation of all the above will require dense exploring Beaker code and dense work with the author of the Beaker Browser, so with designated budget and time this is not possible (Deep study of Beaker code alone may require a month and attempts to make modifications that will not result in the failure of his work as documentation sparse - it will be a re-engineering project. Therefore, the implementation of which is more complex than the FS module fork with the ability to work with the API instead of the file system in the budget and deadlines would be impossible.
Based on @PureF assessment the community can decide on how deep to go down this rabbit hole. It seems there is monetary support, but maybe we should put these extensive work items as additional stretch goals (First up) and let the crowd decide. I will do my best to connect with @PaulFrazee to get him on board with this build and make sure he is fully compensated for his time and efforts. @frabrunelle do you have any connection with the developer?
I suggest if an HTTP request happens in the main frame (i.e. top level as though you clicked a link), you ask the user whether he wants to open it in his primary browser with an option to never ask again for this site or to never ask again ever (of course, settings can be changed in a settings area).
Cookie makes little sense for a desktop app. Local storage is probably decent. Local sqlite would probably be fine too. Granted since you do login handshake on startup, in memory is probably fine for the auth info, just may not be reasonable for cross-process persistence such as permissions/settings.
Again, cookies make little sense as a storage mechanism for a desktop app.
I think it’s probably not fair for me to ask these things ahead of time. I will just take a peek at the code when implemented.
I want to update the community on where I am at with this project. I did this proposal because we were less than a week out from a vote and nothing was posted.
Even though I’m out some cash and time spent hiring different devs to research the project and provide the technical components of the proposal(s) and commit to developing it–I have also been working on a bigger total Brave Browser customization with larger firm (Did not work out)— I am considering closing this proposal and putting my full support behind @joshuef and his impressive proposal.
I am very encouraged by his commitment to the community and level of technical understanding of what needs to be built now…and he can do it cheaper; I think his stretch goals and cost are also amazing. I wanted to put my thoughts out there, since this will leave us with one really strong SAFE browser proposal.