MaidSafe Dev Update - June 1, 2017

Development Updates
1

Last week, we talked about potentially adding a temporary data persistence solution to client-only networks (testnets where MaidSafe manages all the Vaults). The advantage of implementing this feature is that the front-end team and app developers would be able to start gaining experience with versioned APIs, versioned data, backward compatibility and deprecating APIs before data republish gets implemented via data chains. But based on what we heard from the community, we’re going to drop any plans to support this immediately. We can revisit scoping options for this if we have too many short testnet iterations causing data wipes, since this probably wouldn’t be a great experience for app developers.

Developers who want to try out the new SAFE API can use the SAFE Browser binaries built with mock routing. See also the documentation for the Node.js API and the DOM API as well as the following example applications:

SAFE Authenticator & API

We updated the safe_app_nodejs API based on the recent changes in the dev branch of safe_client_libs. The changes in safe_client_libs address a few inconsistencies and include a couple of API changes as mentioned in this pull request. @bochaco also expanded the example snippets in the DOM API documentation. A few minor bugs were identified while creating simple code snippets and have been fixed. We’ll update the API docs at the same time we release new safe_browser binaries, but devs who want to see the latest DOM API documentation can build it locally via the beaker-plugin-safe-app repo.

@kumar has been away for this week and, as a result, the progress with the Java API has been slower. We had cross-platform issues while running the test cases. The issue was with the FFI callbacks being garbage collected. The issue is fixed now and the tests pass across several platforms. We will be wiring up the MutableData and NFS API next week.

Based on the community’s request, we will be releasing signed binaries from now on. We are planning to release these for the browser and also for the web hosting example application. We hope to provide signed binaries early next week which would include all the latest changes.

SAFE Client Libs & Crust

We are close to done with updating the master branch of safe_vault to latest routing (in this pull request), including changes like Serde 1.0 and SHA-3. This is currently the single remaining library that needs these updates, good news and nice to see the end of that road.

With help from the front-end team, we continue to polish safe_client_libs and apply a few more fixes and tidy up some of the code. Lately we discovered some inconsistencies in NFS functions available to user apps: they don’t work as expected (e.g., not updating last modification time) and this behaviour is not documented properly. So currently we are in the process of reworking the set of NFS functions in safe_app to match the API available to Rust developers in safe_core::nfs.

@bochaco has discovered several bugs in the DOM API that are possibly rooted in safe_client_libs and we are looking through these cases, we’re also trying to find a more efficient way to debug such problems in the future.

Routing & Vault

The simulation for option B is making good progress with most of the routing team working on that this week. The initial results covering adding, removing, splitting and merging look promising. We are making a few small improvements to make the simulation more accurate, and also slightly extending the option B proposal itself, specifically:

  • We need to cope with the fact that we can have several “contradictory” valid, current blocks affects safe_vault, and how data can be handled given that kind of uncertainty.
  • The document assumes that we have a mechanism that guarantees that eventually, every node receives every vote that concerns it. That will also need to be designed in detail.

We also applied a few tweaks to the rules to make them less ambiguous and to address some scenarios we came up with independently of the simulation. The forum post has been updated.

In routing master, we fixed a potential problem where two parallel merges could cause nodes to go out of sync.

51 Likes
2

First! 20 characters

9 Likes
3

Woah caught us by surprise… first!

Edit : You cheat Tom! :slight_smile:

Have done it myself :blush:

3 Likes
5

#Ask questions here!

Community video discussion. We are here now to answer any questions anyone has

2 Likes
6

Both of these separate links point to the same page.

Just making sure this was intentional?

1 Like
7

So the signed binaries will be for external dev testing and not a maidsafe hosted testnet? Just curious. Also is the team leaning towards Data Chains Option B?

3 Likes
8

No testnet this week, working towards that though asap. Data chains option B is the focus right now in terms of the simulations and working out any remaining wrinkles in that proposal. Option A has a few lingering issues in terms of speed and potential attacks. We spent over 10 weeks in option A variants and option B is now getting a lot of focus to pull it apart if we can. Simulations so far looking good and I hope we can take a lot of that work to aid production code if possible.

24 Likes
9

I wasn’t expecting anything this week but I would like to voice my excitement for “asap” :wink: but it’ll be nice to finally reach the MD milestone everyone has been desperate to see. How much of what is coded for data chains is usable? Basically a skeleton?

16 Likes
10

There are a few codebases around data chains now with all the POC work. I am sure we can use quite a lot of that code moving forward. The simulations and testing are critical though, especially with option B as it’s much more natural (i.e. complex to reason about) and likely very powerful, but we will see soon :wink:

15 Likes
11

oops, I just fixed the link for the DOM API :slight_smile:

6 Likes
12

It’s very exciting to see work on data chains progressing. However on a personal note, I would really appreciate a MD testnet soon. Just from following github and the pending “monster” PRs I get the feeling it’s a little bit stagnating (but hard to tell from this perspective). Could you maybe elaborate what the main blockers are for merging MD code?

8 Likes
13

It’s all already being merged :thumbsup: , if you see the SAFE client libs section of the update then you will see the team are very close, just a library remaining to merge, then of course we go soak test crazy for a while then testnet. Soak tests can sometimes take a while, especially if we uncover a bug (we would be scared if there were none :wink: )

22 Likes
14

Have you given up option A altogether ? or does it just mean there are big problems with options A that would take another 20 weeks to solve ?

If you started with option A, it likely means it was the option which you initially thought could have the biggest potential and B was a back up plan. Maybe you thought A could be a simpler solution whereas B was more powerful but also more difficult to implement ( which means it could take more than 10 weeks).

care to let us know about that ?

4 Likes
15

Team split in two with one focused on the upcoming testnet/Alpha 2 and the others technically designing/testing datachains going for Alpha 3. Nice work folks, as always. But don’t forget there’s a third group everybody, they are building apps using local mock routing with MD included. Big applause for all of you :clap:

13 Likes
16

No not at all, but right now the focus is on B to fully test it. Looks good so far, but we do need to finish looking into it.

Not really, option A was considered as it was more well known technically, however it has limitations and assumptions that do not quite match our network. It was considered “easier” to reason about and the team went down that path to consider those ideas in our network. Option B is more like the original ethos of the initial data chains POC, but much harder to reason, so A was tried first. That’s all really. HTH

14 Likes
17

Thanks Maidsafe devs for another week of hard work, it works energetic to read these ninja scrolls :stuck_out_tongue: your extreme testing before you deliver something is also inspiring.

Shout out to all the super ants who are always here to leave a comment, you know who you are. :kissing_heart:

11 Likes
18

I’m happy to see that the team tend to Option B in Datachain.

As a simple follower I do not dare to comment on a topic so complex but the last few days cannot stop thinking about both options and, the more I think about it, the more convinced I am that option B is the right one.

4 Likes
19

I rarely comment but always read, and I’m sure there are many like me :slight_smile: Always appreciate the comments though, so +1 for the regular commenters.

25 Likes
20

So, on a very quick pass at catching up… and not time atm to read the manual… my experience on Linux Mint 18.1

SAFE Browser - setting up an account with a fake invite code works.

safe_hosting_manager - gets stuck not seeing a reply from authorisation, though the app is noted as authorised.
+bug from clicking [clear access data] out of curiousity:

799×682 88.4 KB

email_app - which is within the clone of ./safe_examples/ sees the npm install works but then npm start gives an error:

> Error launching app
> Unable to find Electron app at /home/davidpbrown/x/SAFE/SAFE-June/safe_examples/email_app

Markdown Editor - the abc is less obvious at first pass but following the form of the others, does appear to work with npm install and npm start but then seems not to prompt for authorisation for that to be acknowledged in the Browser.

2 Likes
21

I have a question about the evolving work on the Java API (and possible Swift API) for mobile. Is there any plan once that API is done to produce a SAFE browser for mobile or a plugin for Apache Cordova, or are mobile devs expected to use those APIs directly?

3 Likes