MaidSafe Dev Update - February 15, 2018

Development Updates
1

Here are some of the main things to highlight this week:

  • The Marketing team published a new blog post to highlight the upcoming SAFE DevCon in April.
  • The front-end team continued discussions regarding UX enhancements for Peruse and the Authenticator.
  • The Routing team started the implementation work of JIRA tasks for Milestone 1.

Marketing

Videos

This week, we’ve been working with @joeri and Hypercube on the scripts for both the Safecoin and the Consensus videos. We’re pretty much at the final versions now and we look forward to moving onto receiving the storyboards for both during the next week.

Update on SAFE DevCon 2018

We also put out a blog post today (Medium link, claps gratefully received…) to highlight the upcoming SAFE DevCon in April. We’re still receiving applications from developers looking to attend and we’re hoping to be in a position to directly respond to each to confirm places around this time next week.

Website wireframes

We’ve also been working on the wireframes for the new MaidSafe website this week. The process is continuing according to the schedule laid out and we’re looking forward to having something to share with you all in a few weeks’ time.

SAFE Authenticator & API

We’ve continued discussions in the last week regarding UX enhancements for Peruse and the Authenticator, and how to streamline those, as well as considering how these changes might play out with the apps internal design. We’ve reached some conclusions and have started tasks to set up application flows for the various network connections inside the browser (for notifications, app state changes, and also for the data that goes back and forth from the renderer and main processes when interacting with the SAFE Network), which are prerequisites for some of the coming UX enhancements.

Work on the safe_app_csharp bindings is progressing. We had issues while executing the test suite on Android. We have fixed it now and all the tests from the work in progress code are passing on desktop, iOS and Android. The apps are being updated to adapt to the new URL encoding schemes for data exchange between the authenticator and the apps. After testing end-to-end on mobile, we will be able to get the upstream master branch updated with these changes.

On the safe_app_nodejs front, we are putting some effort to have some additional validations for input parameters to be able to return more specific and explanatory errors. In most of the cases we just rely on the validations made by the underlying safe_app lib, this is why we are also trying to spot cases where we think the safe_app lib should make additional validations to the input params.

We’ve been also reviewing some edge cases for the authentication flow, to make sure we are covering some error scenarios, as well as to understand how we could support some additional features for the Authenticator in the future, e.g. being able to not only list and revoke applications, but block them and possibly revoke specific permissions rather than the whole application, similar to the way this is already possible with mobile operating systems. This is just an early stage analysis with a view to working toward an implemtation plan.

SAFE Client Libs

This week we noticed that a PR we once merged to update our API, namely to refactor and rename several *_for_each functions, missed one such function: mdata_entries_for_each. We have raised a JIRA task and will be getting this function updated and in line with the rest of the API.

Routing & Crust

We started the implementation work of JIRA tasks for Milestone 1. The tasks completed so far are mainly refactoring certain parts of Routing to create the required foundation for the upcoming new data chain features. For example, the PublicId used by nodes and clients to identify themselves on the network has been changed to PublicInfo to allow the inclusion of node ages within their identifiers.

Thanks to @tfa’s work of improving the simulator, a network with much larger size (over 580,000 sections with on average 25 nodes per section) can now be simulated. And the result shows a nice growing curve.

Number%20of%20nodes%20in%20a%20section
Number%20of%20nodes%20in%20a%20section1035×483 26.8 KB

We’re making efforts to get caught up with a slight backlog of tasks relating to rust_sodium, our crate which provides bindings to the excellent cryptographic library libsodium. As well as our own project, there are a few other crates which depend on rust_sodium, and it crops up in the odd article, so there’s an even greater responsibility to get through these tasks. The most recent work other than a couple of trivial bugfixes has been to improve the build process. The ongoing effort is in updating the crate to use the latest version of libsodium. This is a fork of the excellent work by dnaq on GitHub who still supports and updates the original crate. We do hope dnaq merges our changes upstream at some time in the future and allow us to deprecate this crate whilst maintaining the Rust Sodium community from both crates. Open source is great for this and forks are fine but also merges back are really nice when a fork proves an approach is acceptable and useful. In the meantime, we are happy to support the wider community with this fork.

In Crust, we aim for fully encrypted communication between two peers: everything starting from the very first connection messages, even echo address request/responses will be encrypted. That requires some structural changes in both the p2p and Crust crates and we’re working through those at the moment. Last week we hit some regression - hole punched connections were broken. That was spotted and fixed quickly and covered by tests to avoid any future regression. Luckily Andrew has progressed network simulator to a usable state and we should have more integration style tests by the next week - yay! We also made hole punched connections more reliable: now the window in which two peers must contact each other is 2 minutes. So the upper layers, like Routing, have more time to instruct nodes to connect to each other.

84 Likes
3

first!!! has been a while since this happened :smiley:

nice one! :slight_smile:

hehe - we’ll be prepared to grow and scale :sunglasses:

15 Likes
5

This is really awesome to hear! I love the granularity and it makes so much sense to have this at the network level. Great work @maidsafe
And a big round of applause for @tfa’s persistence in optimizing the simulations, it’s been enjoyable seeing the progress you’ve made in the dev forum threads. Huge props.

I was thinking about the upcoming videos earlier today, needless to say I’m itching to see them and share it in every crevice of the Internet I can find!

26 Likes
6

:exploding_head:

Love it how you guys keep optimizing everything. :vulcan_salute:

Thanks Maidsafe devs for a pretty neat update :stuck_out_tongue: Can’t wait for the SAFEcoin vid and Devcon

10 Likes
7

Ways to do granular authentication, maximum user control with minimal user burden is a tricky and fascinating problem, so I look forward to learning more about this.

Do you plan some discussion of ideas here?

Currently I think the situation I experience with Android apps is very poor. Apps get you hooked and gradually increase their permissions update after update.

I would like us to shift to a model where apps offer different features based on the permissions you have granted, so I can still use parts of an app without giving it access to everything it requests. And easy ways to handle cases where I might want to use a feature occasionally, and so only grant permissions for certain things in each use. Like the “Allow once / always” feature when Android asks me which app I want to open a particular file, for example.

25 Likes
8

Looking forward to those videos!

8 Likes
9

I fully agree with this, that’s how I also see it and wish to have. I remember stop using at least one app because it was requesting all permissions…or nothing, as soon as I disabled/revoked one of the permissions the app would just not launch claiming that it needed them all.

At the moment apps can actually already do that (I think I covered how the app can do it here).
The challenge now I think is more from the UX perspective in the Authenticator, and that’s what we are trying to figure out now, as you said higher granularity should be much better but we should also make sure that is still simple enough for all users to understand, otherwise I imagine many users simply giving up and allowing all permissions to all apps indiscriminately. I know…we cannot make sure users take the time to understand the risks, but making it as easy as possible is what we should definitely aim at.

25 Likes
10

Dear Maidsafe team -

I think developing the entire ecosystem is great but I think for the investors in Maidsafe, the best approach would be to split the project into 2 components -

  1. Decentralized Storage - This could be leveraged by companies that have current applications and would utilize only the storage layer of maidsafe. This will give an opportunity for companies to explore the decentralized storage part of maidsafe and build apps on it using their existing technologies, web sites accessed by current web browsers etc. This would be huge from business standpoint and could lead to interesting partnerships for decentralized, secure storage.

  2. The second part of this project should include developing SAFE web sites, accessed by SAFE browser etc etc. The second component is essentially developing the entire ecosystem (for anyone interested).

I think the stand alone decentralized storage component of this project has huge potential on its own and should be marketed/pitched separately. It should not be clubbed with the entire ecosystem development as it may turn back a huge market.

Thoughts??

Again, I am non-technical so if I am not making sense, please ignore. I just think that the decentralized storage part of this project is a multi-trillion dollar opportunity in itself.

Lastly, when safecoin is launched, please make it divisible. That will give more flexibility for people to use it and will help the price.

11

Excellent update. Thursday’s would not be Thursday’s without it. :slight_smile:

6 Likes
12

@bochaco:
At the moment apps can actually already do that (I think I covered how the app can do it here).

I think there are two barriers here which will be difficult to overcome.

  • Developers don’t realise this is possible, and those which do will not know how to design for this approach, and even those who do will probably not do so unless there is pressure from users for this functionality, which brings in the second barrier…
  • Users won’t expect this or demand it, and it will be hard to ‘sell’ it as a benefit if it asks more of them than the current model, especially as that is what they will expect and understand.

Tough challenges!

Well worth trying though. I wonder if there are any precedents for this kind of change we could learn from (not in terms of auth, but in moving developer and user from one approach to another). I well remember Microsoft introducing the “this requires administrator privileges” message box and doing it quite badly. On the other hand, I also remember a similar “ask when needed” UI for a third party Widows firewall (can’t recall the name now) which turned firewall configuration from a PhD level task to something most users could do.

4 Likes
13

Great update, as always!! Can’t wait to see the vids & the new website.

Hey @Anonymous2020, looks like you’re new here. Welcome! A couple of things…

I may be misinterpreting your point, but building the dapps/websites that will run on the SAFEnetwork is something that third party developers are and will work on. One great example of such is JAMS.

Safecoin will be divisibe. There are several topics on this. If you search for “divisible”, you can read up on all the relevant topics. :slight_smile:

10 Likes
14

Thank-you Sotros25. My main point was that the team should market the fact that if someone is not interested in using the safe browser or if someone has no intention to build a SAFE website/app and would like to instead only use existing web technologies as they do today BUT JUST USE the decentralized secure SAFE data storage layer, they could do that. Say Microsoft wants to build a new website accessible via IE 10 or Chrome - but only wants to use the SAFE decentralized Data storage layer, an example of such an application would be great. It will bring great attention to the project.

15

I’m following the Marketing section of the updates with keen interest. Whilst I am probably wrong about expecting Alpha 3 by the end of April, it looks like Maidsafe is putting down strong foundations for the future. Thumbs up guys and gals

4 Likes
16

Great progress happening! Thanks to the team and community for their passion, patience and persistence!

Like has been pointed out the permissions in Authenticator will definitely present UX challenges with convenience vs control (course grained vs granular). I’d be happy to help out with some thinking and collaborative wire-framing sessions. One approach that I’ve used is having course grained levels that have default bundles of permissions with more granular advanced permissions for those that want it, which is a common design pattern.

Onwards and upwards team!

11 Likes
17

These are in fact almost the same thing. Storage is storage, granted, but storage is addressable and due to that it can be anything, a video, program, OS, web page, binary file, library etc.

We do try and find parts to launch first, but beyond libraries it is very difficult really. The basic system that is being built right now for instance has no compute, no real smart contracts (no DSL yet), no mesh, no os boot, no archive nodes, no safecoin divisibility etc. So it really is basic in terms of what will be possible, but complex in itself as it is the foundation of a much larger system and one that I hope many more than maidsafe are involved in building all the parts for.

Then there are apps, like autonomous vehicle data sharing, medical research, medical record systems, voting systems, aggregated news and many more. Even now though with the current API’s people are building you tube type things, spotify competitors, virtual file systems, decentralised forums and many more, too many for me to mention form my deep and dirty day job in the guts of the consensus stuff.

In short we do keep looking and encourage everyone to do likewise, but I feel what we are trying to launch is the very beginning and I am not sure we can sub divide it any more. If we could we would though.

37 Likes
18

Good to see all these pieces coming forward!!

I really appreciate all MaidSafe and the whole community do to move this forward in a stable, rational way. It’s such a huge task that is starting to feel more “there” all the time.

12 Likes
19

Awesome progress. Better yet the summary in this post is actually understandable to the layperson and techie alike. :slight_smile: keep up the great work.

2 Likes
20

I totally concur with your thoughts on how Apps should be handled on the SAFE Network, and further some of the permissions should relate to resources such as use of memory, cpu %, network bandwidth (how much and even when. , time of day/week stuff…). just my 2 cents… :slight_smile: R2

21

for those wondering about the milestones:

Data chains being implemented. Yeah.

20 Likes
22

Sorry but this makes no sense. Web hosting is essentially just a file hosted on your own or another computer that you can view using your browser. If we have remote file storage then naturally we have web hosting. The only reason google drive or dropbox can’t act as web hosting is they use restrictive web apps but if you used a regular server you could. If you set up a laptop or a computer up as a server it would work just as well to run as a server at google to host a website. Maidsafe is attempting to decentralize the internet. That means allowing computers to connect directly to one another and share information directly with one another. It has already proven that self authentication works and that one can actually host simple websites using their proof of concept app. if one COULDN’T host sites then i’d assume that whatever they came out with next had failed so your proposal to market storage and web hosting seperately makes no sense since they are one in the same.

3 Likes