We should develop an ALL-in-one browser (like Brave) and focus on mobile interfaces

Development
1

This is both for development and marketing, but i seriously think we should

  1. Concentrate on MOBILE apps instead of desktop clients where you can EASILY in one click, send and receive Safecoins from other users by scanning a simple QR code, all on a mobile device, and upload files from your mobile to the Safenetwork and then being able to access it on any other devices. A mobile farmer would be the perfect farmer, too, considering almost all our mobile devices are on 24/7 these days, as we usually get to recharge it before the battery dies. The Graphic User Interface is going to be the most important. It needs to be smooth and not feel buggy or clumsy.

  2. We need a browser that is suitable for ANYONE to use and download, much like Brave browser, you don’t need Basic Attention Token or even be part of the ‘cryptocurrency society’ to download and use it, as it’s a privacy focused browser with ad-blocking benefits. Safe browser should be like this - with an addition - that you can also browser websites on the safenetwork and easily send and receive safecoins, create your own website on SAFE, as well as interface with the apps on the safenetwork, AS WELL AS farm for safecoins - all within one or two clicks in the browser. In other words, it should aim to be MUCH BETTER than the current browser that people are using(such as Google Chrome)!

With the second point said, i want to stress that we REALLY SHOULD make our browser able to interface with the current internet all without any problems! This is extremely important, as otherwise, let’s say a website also has a corresponding version on the safenet, but how will that website link people to the safenet? They can put a link on their site but people won’t be able to click it and end up on the site. They’ll have to copy the link, download another browser, and then paste that link… it’ll just be like Tor, which is a hassle to use, and doesn’t exactly foster mass adoption…

For the people who care about their privacy and arguing for safebrowser to only interface with safe sites, you should also realise 90%+ of the people in the world do not, and forcing what you want(your own personal desire to be private) onto what other people should also want isn’t going to help with mass adoption. We can have an option for it though, by default the browser can interface with all sites, however optionally, the people who really care about their privacy for any reason, can choose a ‘maximum privacy’ mode on the browser where that browser will not interface http traffic at all, and does other things to help them be more private. We can have a glider bar that slides between ‘maximum convenience’ and ‘maximum privacy’ that the users can easily choose from depending on their own desires and needs, instead of the more privacy focused people significantly inconveniencing the rest of the world who may just want to use safecoins as a store of value and a transaction medium, and to store data onto the network as well as farm for some safecoins, and do not care a huge amount about internet surfing privacy.

Anyway, all in all, those two points are just my two cents for the team to consider :slight_smile: But I seriously believe they are extremely important to foster adoption and usage of the safenetwork for the masses.

8 Likes
2

Have you read about the browser Maidsafe is developing

Search on “Persue”

2 Likes
3

Anything can be done with the right incentive mechanisms yes. Just a matter of knowledge and being gung-ho.
As much as SAFE is trying to be the ultimate incentive on its own, perhaps there are those who need something else, for whatever reason, be it egocentric or anything really.

4

This is only a interim measure and will not be used once the security is incorporated in SAFE code.

So this requirement is already fulfilled.

That is what “Persue” will be. So already being worked on.

Mobile devices can if they are on charging. If on battery then battery life will kill this idea. Not a fault of SAFE but of battery technology. Also as we’ve told you mobile data at this time will not support farming because of the exorbitant outrageous prices charged for mobile data.

So farming on mobile devices will be possible when they are on charging and WiFi

Well then you should detail how we can do it without the problems.

Instead of saying something should be so, when the problems have been detailed, you should detail how to SOLVE the problems.

The issue is security and the idea is contentious. I am sitting back waiting for the contentions to work themselves out. But as soon as you allow traditional internet access then you introduce all the problems with traditional web sites and the security problems. Also then it allows total leakage of private information thus removing anonymity and allow tracking

2 Likes
5

Yes I’ve had a look, THAT’S WHY i posted this article, because it’s, frankly speaking, shit, the GUI especially. But of course, its understandable because it’s in the early stages. I still suggest we use a fork of Google Chrome/Brave though, the look and feel is just a million times better

There are mobile powerpacks which I and many other people nowadays i see carry. Battery life shouldn’t be a problem unless it uses an absurd amount of power, plus, as well as foreseeing bandwidth cost decreasing, you should foresee that batteries are going to have more and more capacity and take less and less space, no?

First, i’m not a technical expert, so don’t expect me to solve the problems even if they exist, i bring it up so that the community can work together to solve them. Secondly, I don’t really see a problem besides people arguing for privacy issues.

Exactly what i mean, first of all, 90% of the people don’t give a shit about privacy and leakage and remaining private etc etc. And for those that do, i already proposed a maximum privacy mode which they can optionally choose to turn on, in which then the browser will be the exact same as a full safe browser and won’t access the clear-net at all. Solution is already there if you read.

6

As things progress so will the possibilities. Obviously if you are using powerbanks then that is “on charging” isn’t it? Well that is how the mobile device sees it.

7

Sure, minor point though. I mean if you get all technical people obviously won’t have their phones plugged to the powerbank all the time as it may be inconvenient when they pick up calls, so again app should have an option to only farm when plugged in or user can set to farm anytime. Anyway lets use our time to discuss the browser more, as that’ll be the upmost important thing that’ll revolutionise everything IMHO.

8

That is the stated plan.

I’ll leave that to others who have more experience considering the issues.

9

Here’s the discussion for browser development, weighing various options: Future of a SAFE Browser and node/webAPIs - General - Safe Dev Forum

We will need a separate mobile client code base from our desktop client, for which a foundation is being laid to develop with Xamarin: https://github.com/maidsafe/safe_app_csharp.

Peruse browser depends on electron, which is built with Chromium, which is the open-source version of Google Chrome. For the time being, electron is in line with the structure of our lower-level client library which is centered on foreign function interfaces.

If we moved over to using a fork of Brave, we’d no longer be able to utilise foreign function interfaces; we’d need create library that is compatible with web assembly or native node modules, which is fine but we first need to test those options to be sure that they can serve our needs completely.

All that I’m saying is the points you bring up are being worked on, they just require a lot of initial testing to be sure that they are viable and that the time that will be required for implementation is worth the opportunity costs, also including identifying those opportunity costs.

20 Likes
10

I suggest a port of Peruse to Android nicely interlocked with power management and some rules/options the user can click on to control SAFE Network behaviour.

I have been down this path several times before, so its IMHO best to contract out the power management portion to those that have done itseveral times before and are absolute experts in the space. check out ex-Montavista developer Kevin Hilman, he lives in Seattle but is linked to South of France via https://www.linkedin.com/in/kevinhilman/

I have worked with Kevin when he was working on Mobilinux at Montavista, the pre cursor to Android before Rubin walked with the code (He was at MV for six months after his Danger company failed trying to push Palm OS add ons) and set up Android (based on the MV Mobilinux OS unofficially ) that was then sold to Google, in Kevin there is no better for hire contractor in the mobile power management space, he could definitely make sure Peruse is awesome on Android.

2 Likes
11

Thank you for bringing up the subject of power management.

It got me skimming this, https://www.dre.vanderbilt.edu/~schmidt/PDF/spot.pdf:

Each application and network communication protocol
has a specific overhead associated with it and can
result in significant power consumption (Heinzelman
et al., 2000). Certain protocols require more development
overhead to implement, but have low runtime
overhead (e.g. bandwidth consumption, message processing
time, etc.). It is hard to determine early (e.g.,
at design time) in an applications lifecycle, however,
how this overhead will affect power consumption and
whether the number of messages transmitted will be
substantial enough to impact power consumption significantly.

Also this: https://www.dre.vanderbilt.edu/~schmidt/PDF/spot-chapter.pdf

For certain our mobile applications will be performing encryption and decryption operations.
Then at some point Crust will be using various protocols to establish peer-to-peer connections and initially it appears that process is different on mobile networks.
Anyway, I’m curious to know about how exactly these operations are pinpointed in order to measure their power consumption.

1 Like
12

One of the items aside from WIFI connectivity which uses alot of mobile or offgrid laptop/desktop power is the write to local file structure operation on mobile devices which is a real power pig, the root cause being the OS file system vanilla write driver using NAND without disciplined queued/ordered/match to app use write control, as a result the apps are queued up in mobile by the connection manager randomly and you end up getting get random interleaved spray of writes from different concurrently running apps on the Mobile SSD, while not quite as bad as HDD setups found in towers, desktops and older laptops/notebooks, this write action is still power intensive and a big battery drain. The better approach is to in memory, contiguously order the write and then to in one cycle (a few chained ops) save in a Giant block size locally belonging to just one app (pattern matching @ L5/4) and then match up in a similar fashion your P2P WAN network writes to the block size which routers like best which is 4096 the typical “4k” packet size to avoid router resends sometimes caused by Van Jacobsen’s scale up/down throttling of TCP ( A cisco feature) , UDP uTP or course can be engineered appropriately (lots of automation work required here), however opening up new ports through a router network need often to also be mapped into shared TUN or STUN (and soon VXLANS over TUN TCP now a big thing in local DCs) over the WAN to get speed and efficiency also making sure the packet size for the L5/4 port pair write is also mapped properly through the firewalls and load balancers.

With reads, these are energy efficient on SSD so I wont go there, they can be a power pig on fragmented HDDs.

fyi- I know of some big league mux/queuing L5/4 tech based in California (south NOT the valley) which does the contiguous write efficiently to NAND with incredible throughput via rules and app write behaviour pattern matching and prediction, the code was ported to earlier Android in 2011-2012 in Toronto by a colleague of mine , however it’s currently not open source but on the drawing board now to be open sourced soon in 2018.

The code heritage, lets call it TurboX, now sees it as currently a 3rd generation mature development of the old 2009-2012 Whiptail Code for SSD Storage which saw that company lead the market in IOP speed from 256 to 4096 DTU size by about 4X on average over the competition. SANDisk (now Western Digital) replaced it after loaning 10M US to Whiptail to facilitate the sale of Whiptail to Cisco, with the SANDisk code which worked but was way slow, so the V2 code on Whiptail Thanks to Sandisk killed the SSD Invicta product line offered by Whiptail and Cisco was forced to write off what was a $600M + US purchase as no one would repeat buy the Whiptail V2 shite. The TurboX code as it is offered today commercially to OEMs easily leads the performance curve for RAID 5/6/10 writes by 20X for large 4k block size writes and 4X for 256byte DTU with very good CPU and RAM efficiency in terms of power and cycle count. Let’s say they use Pure as the benchmark to prove their numbers.

I will keep you posted when TurboX gets closer to Open source this year, it will still have a commercial license attached when that happens.

nb- I am working with the closed commercial version of TurboX now @ Cloudprox which is a small outfit based in Toronto (and have been for over the last year mainly in a Solutions Architecture role for DCs and uDCs), Clouprox’s David Bruce has done a brilliant job there and has adapted it to work with CEPH (which has always been slow) for really cheap RAID 5/6, but more importantly Cloudprox together with the TurboX developer and some local DC Colo help in Toronto have benchmarked the TurboX code to prove it to some big OEMs looking to add it to their 2U DC boxes of SSD Arrays, so Cloudprox will have a real distributed storage killer bolt on TurboSAN storage app coming very shortly in Q1 2018 which is initially targeted for Ubuntu and can be easily ported to MS, Apple and Android.

My thinking is the Opensource variant of TurboX would be an excellent fit for the Peruse browser on any mobile of desktop OS platform as a write speed up option which costs a few more SafeCoin.

Thoughts?

I would be willing to org a chat with David, if there is some interest.

br

R2

8 Likes
13

@dirvine? This sounds interesting!

14

A post was merged into an existing topic: MaidSafe Dev Update - January 11, 2018