The only powerful difference here is, that as soon as a user clicks on the “new tab” they could get the appstore, instead of having to type in a url. At first sight it would be the perfect play ground for @whiteoutmashups appstore, I could be wrong, but I’m just thinking out loud here (actually started thinking about it, just now).
Thanks for taking this task and you can absolutely count on me with financial support.
I think the line between “APPS” and “website” will further blur with SAFEnetwork. I like the starter block style page most browsers are doing now and what @whiteoutmashups is doing with the app store is a prime option to be the default starter page. When we move forward with the stretch goal of combining the browser with the launcher, this line of thinking should organically happen.
I initially had several other stretch goals, but after reading @frabrunelle 's well placed advice. We are going to focus on the stuff we can build today. We will be utilizing the KISS protocol, or for those that are sensitive: “less is more.”
Since you brought it up though , this is what I envisioned for a galaxy far far away Interledger with Blockchain, legacy and the “mother of all coins” SAFEcoin integration - All electronic transfers have to be recorded in stateful systems. Otherwise the same instance of an asset could be sent to two different destinations, essentially duplicating the asset. This is also known as a double-spend. We call these stateful systems ledgers.
Ledgers consist of accounts. Accounts are individual buckets containing a decimal amount of one type of asset, usually (but not always) associated with an owner. This amount is also called the account’s balance. Balances can be positive or negative, representing assets or liabilities.Assets can be transferred between accounts on the same ledger. We call these events book transfers or just transfers.
A transfer of assets across ledgers requires two or more local book transfers. Some system must know the relationship between the two transfers. We call this system a connector. The same system may act as both a ledger and a connector.
The Interledger is a network of independent and diverse ledgers. Each account is part of a particular ledger; the Interledger itself is only conceptual.
I want the equivalent of a Swiss Army knife, and one with pluggable options at that, rather than a scalpel:
A browser in which you can have each tab on a different network, especially including networks currently not even imagined: Clearnet, Tor, SAFEnet…
My current browser provides for a (add-to-able) choice of search engines, one of which it defaults to if I type some random thing. It also has plug-ins that put convenient buttons on the toolbar.
I want a browser that opens by default on some user-selectable network, with addable-by-plugin radio buttons on the toolbar that allow the user to open a tab and select a network.
A one-network browser will lose out to the sort of browser I describe above. Making it a framework for other developers to add to, as described, will make it much more future proof.
EDIT: I’m not saying they need to build it out and include Tor, for example. I’m just saying, start with creating an API for a generic network to use the browser, then add the options for cleanet and SAFE, and leave it to future devs to add plugins for other networks. And after all, we can expect SAFEnet itself to be fluid in its structure and interface during alpha and into beta, so adding it as a plugin rather than hard-wiring it into the browser will make such upgrades much easier to handle.
The central goal here is to a simply build a browser for users that has privacy, security, freedom set as the default. Non tech users will not have to make any adjustments to the settings to view the SAFEnetwork.
Additionally, this gets the ball rolling for future devs to more easily (Other browsers are massively complex) build onto this core browser with the features they want.
I will follow up with more details to how this API for a generic network could possibly work. I think we would fail with this build if it didn’t make it easier for others to integrate SAFEnetwork into all of the more complex browsers in the future.
Having endless options and customization is amazing and something I seek out, but my target end-user is my 87 year old grandparent who still calls the Internet Explorer Icon her email and writes down every step she has to do to buy something from Amazon; but still calls me to order something. When her home page of yahoo email (set by me) some how changed she called me immediately and said her email was broken. Last but not least she manages to click on every spamware, virus, scam you could imagine and has had her credit card information stolen multiple times.
Finally, MaidSafe felt this community driven build was important enough to be the first project for the Community Engagement Program so I will do everything in my power to make sure this is completed. It seems logical starting with something simple and achievable now so we all can learn and build from this initial project.
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.