MaidSafe Dev Update 19th July 2016

This week has seen us running TEST 6 with some increased limits on storage and also a reduced number of our own vaults. The test so far has proven to be again valuable, particularly in finding client bugs. These are being worked on now and updates should be coming along very soon to address most of them.

Currently the password input is being debated and again we will try another approach here, namely two passwords instead of one. We have investigated and debated BIP39 as well as many more options. The forum discussions are proving valuable here as well. This is what the community should do and we hope they do see that their comments are taken on board and worked on quickly.

So where are we now? Well as we said last week there are not many more tests before we move on through Alpha releases. We will absolutely still lose data until we finalise some designs we are debating right now. Again the community will be involved, but data persistence and security improvements will come after the first Alpha release.

What we are doing may seem slow to some, but it is working and working very well. With the SAFE Browser RFP then things are pulling together and we wish the current proposers the very best of luck.

Two proposals have been submitted so far and another proposal is about to be submitted. The application period was supposed to end today, but we are extending it until Thursday to give some additional time for last-minute proposals.

As a company we are very much behind these proposals, but will try and take a back seat and allow the community to get as involved as they can, it makes us all stronger. We will of course supply funding and resources to help where we can.

If this RFP works out well then we will quickly expand the process and grow the ecosystem of core applications and APIs for client devs.

Again thanks for the help and expect a quick client update very soon. We may need to supply new vaults, but the current opinion is not to, just update the apps. We hope this will be this week, but don’t be surprised if it runs over to early next week.

Crust, Core: Spandan (tl) & Vinicius

There is some discussion on number and complexity of user supplied passwords to make a balance between usability and security. Previously we had pin, keyword and password where pin and keyword were required for figuring out the location of the account packet and pin and password were required for decrypting the account packet. It seemed not so convenient for an average user to remember 3 credentials so we experimented with having only 1. However this one needed to be sufficiently long and complex for reasons of security as we would internally derive pin, keyword and password from it. This too turned out to be not so convenient as feedback was that it’s difficult to remember or come up with a complex password (e.g. random words with a few special characters here and there etc.). So now we are planning to have 2 fields and see how that flies. So one of them will be used to get the account location and the other to decrypt it. We should however make sure that none of this is a username. The more one treats all the fields as a secret/password, the more secure the account is.

Also we are working out on how to avoid the seemingly hung progress after 99% upload through the demo app. The progress for the actual Network upload happens in the last stage of self-encryption and that is difficult at the moment to communicate back to the Launcher. See this post by @Viv for more info. Hopefully with a few additions and modifications of features we should be able to achieve this.

Routing, Vaults: Adam, Andreas (tl), Fraser & Qi

A big code cleanup was merged this week, reorganising the routing code into a state machine pattern, more clearly separating the code related to bootstrapping (connecting to the network) from the client code, and from the routing node logic.

We also added some feedback in the case that a message remained unacknowledged by the receiver despite having been sent along eight different routes. This should help the Launcher to display more meaningful information e.g. in progress bars.

Client: Krishna (tl), Scott & Shankar

Following the release of our new Launcher UI last week, we’ve identified a number of areas to improve and work on:

  • To improve the onboarding process for users, we plan to incorporate further descriptions into the Create Account section, providing some useful information about the login process and what each credential is used for.

  • We also want to improve the handling of errors and initial “No data yet.” messages and more informative loading screens.

  • Another key feature we are adding is the option to logout without quitting, which should make using multiple accounts a little more seamless.

The Demo App is also getting some love this week and we’re improving the process of uploading and creating websites. We’ve decided to split up the management of data, and of websites and DNS. Our goal is to better reflect the underlying processes a little more accurately and this will also help us streamline and resolve some of the problems we see when uploading content.


P.S. We are planning to bring the client test network down on Thursday since it has become quite outdated (it doesn’t run Launcher API v0.5). When the Demo app and Launcher issues are at rest, we will be looking at getting another client test network up :slight_smile:

43 Likes

1st … :smiley:

EDIT/PS:

oh - excellent idea! i indeed missed that but forgot to mention it :-\ glad you recognized it yourself :smiley:

i’m looking forward to test that (the one long password really was kind of challenging) :slight_smile:

yeyey - with the browser coming + safe-fs 100% funded all of this is going on pretty well =) :heart_eyes:

11 Likes

You know, for what seems like radio silence in the actual forum discussions themselves, it seems like you guys are actually paying attention to them. That’s pretty cool.

Hell between you guys and the way the community is going, I get the feeling we’re going to have a network that will be basically good to go by Alpha. At the very least it’s gonna start off running.

So, ah, good shit, everyone.

14 Likes

I think right now progress is snowballing and soon we’ll be knee deep in alpha and we’ll barely realize what hit us. Couldn’t come soon enough it seems but the pieces are almost all ready to fall in place for all to see. MuahahahaHAHAHA!

15 Likes

Big thanks to the active folks coming up with proposals to build a SAFE browser. It’s much needed and will make SAFE safer again.

Thanks for the update as well. Devs doing a great job again.

13 Likes

You know maybe we should just rename the “demo app” to Client App as it seems to be evolving along with the launcher as a companion client. By the time Alpha and Beta hit it might be a stand alone decent app instead of just a demo. That seems to be the pattern of the network. Start with a seed and then let it grow and evolve into something bigger.

6 Likes

Alright hope I’m not being a bug but I gotsta know. My curious nature has got the best of me thanks to @polpolrene exposing it to the community but @dirvine will we see data chains on alpha 1 or soon thereafter??

but there will be many many client apps with different features … i don’t think “client app” could be an appropriate name … most of the client apps won’t be developed by maidsafe :open_mouth:

3 Likes

Fair enough. So call it “Super Maidsafe Client of Doom” or whatever else. My point is at some point it’ll evolve beyond being a demo.

1 Like

agreed - at some point it is more like safenet basics and no demo app anymore =)

4 Likes

cough DAO failure cough cough!

Well done guys, please keep it slow and steady so we won’t have big failures later. Thanks for the update! :slight_smile:

13 Likes

Are there any plans to tackle that issue where the network considers lost data as still existing and so refuses to let you reupload a file / recreate a domain, or is this unavoidable so long as the network can loose data?

Also, it’s great to hear the tests are proving useful, thanks for keeping us in the loop. :smile:

4 Likes

Yes, this is being addressed in the demo app itself. So there will be a slight change to user experience there, but it should resolve that issue of a single action doing everything at once.

12 Likes

Thanks Maidsafe devs for another cool update. It’s fun to keep testing the network like this…

Keep up the good work and that’s also for the hard working ants in this community :stuck_out_tongue:
We’re getting closer and closer, but patience is important and rewarding

4 Likes

BIP39 is cute (in a “let’s introduce more complexity, maybe it works better that way” kind of sense) but it’s simply not feasible to remember a long and meaningless string of random words, so I hope we’ll have a better solution, e.g. a simple password strength meter (may I suggest zxcvbn.) Also, I love my 17-word custom made passphreses :joy_cat:

3 Likes

The ability to manually delete multiple files is kinda important too :wink:

4 Likes

Your seeing issues with the current one?

BIP39 is good for secrets that need a known degree of security.

When you can easily change your password (eg most web services), this isn’t quite so important.

But with safe, it’s not easy to change. You set it once and that’s pretty-much the end of it.

So if you realize three years later that you picked a bit of a crappy credential, too bad!

This is the only reason I think bip39 is appropriate for credentials. In this case ‘your data in safe’ is essentially the same as ‘your money in bitcoin’ and safe credentials should be treated as such. Maybe I’m too extreme about the value of data?!

@mav

So if you realize three years later that you picked a bit of a crappy credential, too bad!

No, you will be able to change credentials. I don’t have a reference but am sure MaidSafe have said this will be possible.

5 Likes

Why should one not be able to change them if one
can provide the valid credentials to the mechanism ?

1 Like