MaidSafe Dev Update - 27th September 2016

[frabrunelle]

Yesterday, we had to restart TEST 9 because of a bug in churn handling that ended up taking all the nodes offline.

@frabrunelle

For testing purposes, we make the nodes crash immediately for certain types of errors. We obviously wouldn’t do that in production code, instead we would simply make the nodes print error messages. But for testnets, making the nodes fail fast instead of printing error messages can help us catch bugs faster. In this case, it helped us catch a small bug in safe_vault. You can see the fix here.

All accounts and data have been reset, therefore you will need to create a new account with SAFE Launcher.

You can keep using the same version of SAFE Launcher (v0.9.0).

SAFE API Docs

Today we are releasing the new SAFE API Docs website We agreed to use GitBook to build and host the API Docs. The source code of the API Docs is hosted on GitHub. Anyone can easily submit a pull request by forking this GitHub repository.

The API Docs currently cover SAFE Launcher API v0.5. The new low-level APIs haven’t been added to the API Docs yet, since they are part of SAFE Launcher API v0.6, which is not ready yet. Krishna is working on a pull request to update RFC 42 – SAFE Launcher API v0.6. We will start working on the next version of the API Docs (v0.6) once that pull request has been merged.

Click here to access the new SAFE API Docs

SAFE Launcher

The implementation of the low-level APIs is being tested and will be followed up with bug fixes in the next couple of days. We also fixed a few UI bugs and improved the packaging process. CI suite has been integrated, we just need to test on Windows too. The unit tests are back and functioning (the Authorization, NFS and DNS APIs are covered by the tests).

We are currently working on integrating the SAFE Beaker Browser with the APIs required for the next example app. We are aiming to release the second Dev Tutorial next week

SAFE Core

We are currently involved in 3 active topics on the Dev Forum:

• Proposed changes in NFS
• Multisig Revamp for StructuredData/AppendableData
• Transparency or opacity of SD modifications

We welcome developers to voice their concerns and get involved in the discussions.

We have looked into the discussions so far and are now in the position to evaluate the merits of all the proposed approaches and community feedback put together. We will soon post a summary in each of the 3 topics. These discussions have had nice amount of details and involvement and have been helpful in allowing us to better understand the requirements.

Apart from the changes in directory structure and versioning and others as discussed in those topics, we are also looking into an async-refactor of safe_core and self_encryption crates.

A few newer APIs wanted by Launcher, like ownership assertion, version field exposure etc. have been added too.

Routing & Vault

We are currently discussing and writing several RFCs. Andreas is going on vacation for 2 weeks starting this Wednesday, so we are trying to make as many decisions as possible before he leaves. We also have two new team members joining soon, and are making plans for onboarding them. That is why the disjoint groups implementation has been paused in the past few days, and will continue later this week.

With the new RFCs we will try to answer in as much detail as possible the remaining big questions for routing and vault. Even if the implementation of some of them is still a long way away, we want to make sure that we are moving in the right direction and avoid writing code that is going to be rewritten later again. Some of the ideas are:

• Merkle tree of node keys: Periodically compute a hash of all nodes in the network which allows every node to prove its identity to any other node in the network and avoids the slowdown for group messages that comes with the original Disjoint Groups RFC.

• Node monitoring: Neighbouring groups evaluate the performance of nodes in terms of bandwidth and verify that the right messages were sent, so that we can detect and ban malfunctioning and slow nodes.

• Profiling joining nodes: Qi is working on measuring the bandwidth, CPU and storage of a new node before it joins the network. This is an alternative to RFC 44 – Relay Nodes and it’s probably simpler to implement.

• Data node names: Fraser is exploring ways to give two names to each node, one as a data holder and one as a group member that votes in consensus decisions. That is a prerequisite for relocating nodes periodically without causing all the data to be relocated, too – an approach that will likely be necessary to prevent a particular type of Sybil attack on the network.

• Recovery from broken groups: The network needs to be prepared for the extreme case of complete groups of nodes breaking (i.e. enough of them malfunction to prevent consensus). In such a case, the surrounding groups will recover the data – which should be possible even if only one functional node remains – and remove the broken group.

All these RFCs have required a lot of discussions in the last few days (several hangouts with up to 9 of us happening and several of these are lasting over 4-6 hours). We are doing a lot of upfront work (designing & reviewing RFCs) prior to working on the implementations (the easier part ).

[anon40790172]

first 20 characters. Will read now

EDIT:

@frabrunelle

SAFE API Docs

Today we are releasing the new SAFE API Docs website We agreed to use GitBook to build and host the API Docs. The source code of the API Docs is hosted on GitHub. Anyone can easily submit a pull request by forking this GitHub repository.

Nice update, thumbs up to the team!

[davidpbrown]

@anon40790172

Will read now

There should be a test before you’re allowed to reply…

[Krekc]

I agree, for example to correctly spell the word characters

On topic: good update, looking forward to the next tutorial next week!

Edit: @anon40790172 sneakily updated his misspelling of the word characters

[anon40790172]

@Krekc

On topic: good update, looking forward to the next tutorial next week!

And what about this one:

@frabrunelle

We are currently working on integrating the SAFE Beaker Browser with the APIs required for the next example app.

Messenger? Chatbox? Blog?

[Nigel]

@anon40790172 Let’s keep it a surprise!
Serious stuff happening in house, great update. @joshuef excited to hear that SAFEr Browser will be packaged with Launcher! Next week we get to play with toys (new example app)! I’m assuming that will be on Test 9? Or will the new launcher be out before then and be a whole other testnet?

[MrAnderson]

Yes I finally have a little time to test some more of this stuff out. Thank you all for your efforts!

[19eddyjohn75]

Thanks Maidsafe team for your continued hard work, if only an AI could code alone with you gals/guys and alleviate the hard work. this is what Ibm watson should be programmed for, to help out the Maidsafe team (but can your learn machine, to do what you highly skilled surgeons do)

It will be fun to see the next and web based design app

[Nigel]

Also, Its great to hear about team expansion! Can’t wait to hear names and their specialities. Im so gitty to see disjoint groups and data chains get implemented as well but these example apps and security improvements are definitely holding me over.

[Audity]

“Giddy” is the word you’re looking for. But Gittyhub has a good ring to it.

Ditto what everyone else is saying!!

[Nigel]

Thank you for the correction @Audity. Knew how I felt but not how to spell it, haha

[fergish]

Data node names! This is a very cool proposal. Makes everything SO much more agile.

[Secretariat415]

Thanks so much for all of your hard work! And welcome to the new team members!