MaidSafe Dev Update - 2nd August 2016

Development Updates
1

As explained by @dirvine here, there were some issues during TEST 7 and therefore we decided to start a new test network (TEST 7b) that depends on the latest stable version of Routing, prior to the recent refactor.

We will now have two test networks: one for testing Client applications (Network A) and one for testing Vault functionality (Network B).

Having two parallel networks lets us provide a stable test network for end users and app developers (Network A) while also testing Vaults as more updates are made (Network B). That way, all the refactors and RFCs (e.g. Disjoint Groups, Data Chains, etc.) happening in Routing and Vaults wonā€™t affect developers and users who want to use SAFE Launcher and other SAFE apps.

For Network A, we have decided to use the latest stable version of Routing and to only release Client applications (no Vault binaries) in order to provide a good end-user experience as well as a stable network for app developers.

For Network B, we will release both Vault binaries and Client binaries (Network B will have its own Client binaries). The performance will likely not be as good as Network A, but the goal is just to minimally test the network until all the refactors and RFCs are implemented and tested. At this point we will revert back to having one network.

Dev Forum

We would like to announce our intention to launch a developer forum. This new forum would also use the Discourse forum software, but would be hosted on a different domain (e.g. dev.safenetwork.org). This forum will be a place where core contributors can discuss with the MaidSafe core team and where app developers can get help and give feedback on the Launcher API.

SAFE Browser RFP

Thereā€™s one week left to make final comments/requests into the SAFEr Browser(s) Proposal topic. At the end of the discussion period, we will publish a MaidSafeCoin address that can be used by anyone who wants to contribute to the development of this new browser.

Crust, Core: Spandan (tl) & Vinicius

The work in safe_core is focussed on general code improvements and bug fixing. Internally the deletion of directories have changed a little so that the metadata is returned for each delete. This will help locate the structured data that is now orphan, and in future we will use this information to delete the structured data. We are also discussing the idea of deletable immutable data. It is very much in its infancy right now and needs proper RFC to fully assess its viability. The very nature of immutable data makes it hard to delete, but if we can come up with ways to do it properly it will reduce data in churn. Also, currently safe_core creates immutable data to deal with versioned directories, so every change in version results in a new immutable data and the previous one continues to exist without ever being used. These are non-trivial issues to solve and this is what we will be going over in the next few days.

To ensure requests donā€™t hang without response, the request timeout has been increased to 2 minutes, so Routing will be given 120 seconds by safe_core to perform a request and if within that time we do not get a response, the front end will be notified of a permanent failure of that particular request.

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

We have branched routing 0.23 which is going to be used in the next few versions of the binaries we release, while a lot of changes are going on in the master branch:

  • Adam is putting the finishing touches on a huge reorganisation of routing core code to better separate the bootstrapping, client and node logic.

  • Fraser has started with the implementation of RFC 37 that redefines the concept of a ā€˜close groupā€™ of nodes, and will make several features we plan to add later a lot simpler or even feasible in the first place.

  • Qi is implementing RFC 30, which will tie the node name to the nodeā€™s public signing key.

  • (Andreas is typing this dev update section and leaving nit-picky comments in code reviews.)

Once these changes are complete, we will continue to break the Data Chain integration into small RFCs, work out all the details and implement them. This will take some time, but it should enable us to make Routing a lot more secure and at the same time increase its performance and improve utilisation of nodes with different bandwidths and storage space.

Once all the aforementioned RFCs are implemented, we will again release Vaults with new functionalities. This is along with community parallel networks testing Vaults as we move along and makes sense as users will really want safecoin farming to run Vaults. We realise that many people will want to run Vaults prior to safecoin farming to help and get ready for farming. These people will be a great help as we move through the Alpha releases (more on that later).

Client: Krishna (tl), Scott & Shankar

Last week after the v0.7.1 release of Launcher, we started working on fixing the limitations and also few minor nitpicks.

We have fixed the issue where the user had to manually kill the hanging process from the system process list on OS X and Linux when the Launcher crashed. Along with this fix, this GitHub issue is also being addressed.

With continued testing, we have also identified a few minor issues with Launcher and these are expected to be fixed in the next couple of days.

A few additional tasks that we plan on addressing over the next couple of days:

  1. Updating the applications to use latest dependencies.
  2. Gray screen is visible until the application is loaded.
  3. Fix warning messages from React components.
  4. In relation to this issue, we are planning to provide an option for starting the launcher in dev mode where the proxy will not inject the CSP headers. We are planning to support this by passing a command line argument while starting the launcher.
  5. Integrate version update checking mechanism for the launcher and demo apps.
  6. API bug fixes.

The API documentation is also being updated to reflect the changes in Launcher API version 0.5.

@scott and @shankar are also working on changes to the maidsafe.net website.

We are also looking forward to start the discussion on the SAFEr Browser(s) Proposal (at the earliest later this week).

40 Likes
2

First reply! Took your reply cherry!

7 Likes
3

2nd , equally happy :wink:

5 Likes
4

Iā€™m not sure why it makes sense to split information up. Will that forum be closed to certain people I assume not? But searching for information will become more complicated.

5 Likes
5

I think the idea of two separate testnets is great, I am so anxious to see the implementation of these new routing features and data chains. That will be huge!

6 Likes
6

I wholeheartedly support it. The signal-to-noise ratio is way off on this forum for those wanting to do actual work instead of just talk. It may seem like categories are the right answer, but even the ā€œdevelopmentā€ category (where this is posted) suffers from this. Searching two places instead of one is not really more complicated. But I can tell you that searching for a dev question here is complicated.

15 Likes
8

Thanks for the update :+1: lot of stuff happening.

2 Likes
9

This would be really good if possible.

3 Likes
10

I really love this project. I wish I was able to work on something so cutting edge as this.

9 Likes
11

The forum will be open to anyone who wants to join. The intention in splitting is to facilitate app and core devs to quickly access the specific information they require amongst topics tailored to them without needing to navigate through the vast array of categories that exist within this forum.

11 Likes
12

Itā€™s just easier and a bit more inviting for developers to sift through the more
streamlined and specific requests and answers . A dedicated forum covering the
depths hard to understand for non-devs offers them the focus and time savings
needed to feel more productive and chisel the rock into the monuments we want .

I assume weā€™ll be able to follow the bulk of threads there as well , itā€™s professional
to keep a more general forum while having a specifically curated one able to push
the workloads through the hoops ā€¦ without some of the noise and frictions we
produce without understanding technical aspects down to the level required .

Weā€™ll benefit all from getting better organised already , having two discussion sandboxes tailored to the different levels of knowledge required will help our common progress and render things more interesting and stimulating , too .

6 Likes
13

I understand and probably agree with you and @cretz that the idea behind it is good but I am not convinced that it will cancel the noise if anybody can access or migrate. Or it may be more strictly moderated to prevent noise. But then the development category here may just as easily be more strictly moderated without splitting sources of information and the community to a degree.

4 Likes
14

I think we will need to see how it progresses and if it doesnā€™t work for any reason then we change it. The idea is not to cancel noise, rather provide information that is specifically catered for an audience that has a different set of requirements.

10 Likes
15

Am I dreaming? *pinch *bleed Ok guess not :slight_smile:

4 Likes
16

Just to be sure Iā€™m getting this :slight_smile: Routing wonā€™t be updated until Data Chains + RFCs are implemented but the other libraries will have releases? If so, is the initial Alpha network still planned to be released before the first version of a network with Data Chains?

8 Likes
17

meaning AlphĪ±?

Ī†Ī»Ļ†Ī± Ī†Ī»Ļ†Ī± Ī†Ī»Ļ†Ī±

18

You will be glad to learn that there is literally nothing stopping you :slight_smile:

7 Likes
19

Sounds very good. Looking forward!

3 Likes
20

Maybe only speaking for myself, I would love a launcher with CSP headers off by default and with the proxy off by default (or flat out not included). I may put in a bit of effort once the launcher settles to distribute launcher builds without either of these. Granted that would be well into the future.

2 Likes
21

another long answer warning - sorry :smiley:

Yes we will push through Alpha regardless of data chains. It may mean restricted access to vaults, but the main push we will make here is clients and APIā€™s to enrich the application developers experience. We will need data chains or possibly a simpler process to ensure we can handle the low power / resource vaults. We (this community in test7) proved that very low power vaults (or so many per LAN they become low power). So we will run networks with droplet nodes for all the client apps and APIā€™s initially.

We will run the parallel data destroying tests in a separate network (that people can join) as we move along. I expect the parallel network to be very much Wild West as the RFCā€™s get implemented. The end game though will be we get to full feature much faster. At the moment we are fighting a battle we cannot win and also tests that must annoy people. I personally do not want to lean too heavily on the communities good spirits to keep killing their networks and data. So we will stabilise releases and keep the more gritty stuff in parallel until the network can handle the smaller nodes.

23 Likes