Original source https://forum.safenetwork.io/t/maidsafe-dev-update-19th-july-2016/10345
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 BIP3918 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 proposals11 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.53). When the Demo app and Launcher issues are at rest, we will be looking at getting another client test network up
