MaidSafe Dev Update - February 16, 2017


#1

Test 12b has been great and very useful! It helped us identify problems that didn’t come up in our internal tests. Without the community testnets, it would take us a lot longer to find these bugs. Thank you to everyone who participated in this testnet :slight_smile: Also, as discussed in this topic, we are looking for a way to make it easier for users to submit logs to us.

We are currently addressing the issues we saw with Test 12b. As you might have already guessed, we haven’t iterated to Test 12c today. One of the main issues (there were a few, most of which are already patched in routing master) we saw with Test 12b was a bug which caused a single node to accumulate as a group and which then rippled further through the network causing other issues. We are going to be patching that soon (like tomorrow) with a simple minimum threshold for accumulation, but it also – as highlighted in this post made by @dirvine – pointed to some current limitations which if addressed would have prevented it without even needing the minimum accumulation threshold. The Routing team are currently also working on the integration design for these parts and hopefully we can remove some of these temporary patches with it and address the limitations once the proposal there is complete. In the meantime, we’re hoping to be done with this patch and other general fixes we’ve seen with Test 12b this week, which should then give us some time to run the internal tests early next week and iterate onwards to Test 12c.

SAFE Authenticator & API

@bochaco and @lightyear have been knocking out bugs that were identified in the Node.js API last week. We have been expanding the test cases of the API to make sure that it’s getting more stable. We also added documentation of the complete API to the safe_app_nodejs repo.

At present, the beaker plugins for safe_browser and also safe_app_nodejs have to be built locally to get the library dependencies based on the platform. But in the future, when the module is installed via npm, the dependencies will be downloaded based on the platform. Electron takes a similar approach where the Electron executable is downloaded at the time of installing the dependency.

@Shankar has been working on an example application to allow website publishing. This is an example application to show the devs on how to use the Node.js APIs. It currently has minimal features. We will be adding more features like deleting services, remapping services, etc. in the weeks to follow.

The Electron example application is just out of the shelf. We know what needs to get done to get an Electron compatible version of safe_app_nodejs. In the meantime, building the example might need minor tweaks to get it building depending on the platform. This is explained in the README. Also, the application needs to be packaged to test the entire IPC process with safe_browser.

SAFE Client Libs & Crust

The Mio-bug seems to be finally resolved with this commit. With that merged into mio-master, we are now waiting for a Mio version to be published to crates.io. Our Crust PR to latest Mio is ready for merge, having passed all tests on all platforms. The existing version in master uses the previous Mio which had a bug that caused a panic on Windows. We had forked Mio-v5 to turn that into an error instead of a panic for avoiding a crash in an otherwise running system. That however meant that Crust on Windows could not be used as an echo/stun service, thus causing problems such as reported here. This has been resolved with Mio-v6 and the upcoming Crust. The test, which had been previously disabled for Windows, has been re-enabled and passing. Also, we did a quick build of safe_vault with the new Crust, which solved the issue raised in the forum. Unless we hit any major problems in testing against droplets, the Crust PR should be good for a merge and version publish.

On safe_client_libs side, we are working on exposing the bootstrap config of the Authenticator to the apps during the IPC handshake (see this PR). This will be useful as apps now run as individual processes connecting independently to the SAFE Network. Instead of expecting all of them to keep track of networking configurations with their own set of bootstrap nodes etc., the Authenticator will pass the configuration that its Crust uses on that user-machine to the apps so that the same config can be reused by them.

Routing & Vault

As mentioned above, we are working on the issues uncovered by Test 12b:

  • #1354 addresses several bugs related to merging sections.
  • The merge bugs wouldn’t have shown up in the first place if we already had full message signature validation in place, so we were looking into completing #1356. However, we decided against that for test 12c.
  • We are extending the churn test to simulate more churn, in particular more split and merge events, as well as nodes joining and leaving at the same time.

Developer outreach

We’ve also got a few of us travelling through Asia next week. David, Nick and Krishna are going to be attending and speaking at a Tech Conference in Jakarta this coming Monday about the SAFE Network.

Also, Ben (@lightyear) gave a talk titled “It’s time to SAFE the Internet” at FOSDEM 2017 :smiley: Click here to see the video and slides of his presentation.


MaidSafe's Asia Trip (February 2017)
#2

I hardly realized it was Thursday :smiley:


#3

how could you be faster?!?!?!?!


#4

One day I’ll be first :smiley:


#6

As I don’t see this in the update yet, here’s an unofficial copy of the:


#7

Coooooole.


Also:

The link here is missing maidsafe in the url and thus is broken, FYI @maidsafe


#8

Any hints at when mutable data type will be available?? Things are progressing at such a great speed. Great delivery @maidsafe


#9

oops, I just fixed the link. good catch!


#10

Great stuff. Hope you pull a good crowd there. Can’t wait to see the videos.

Enjoy the brief respite from winter. It’s not exactly a holiday, but a change of scenery is usually a good thing when you’ve been working really hard.


#11

Sweet! Been waiting for the new API. Now it’s here. Thanks for the hard work.

That’s painful to read. But better than nothing.


#12

Already done!

From that website:

Description
“Maidsafe Tech Conference”

Sold Out


#13

I’m personally very impressed of all the tests being performed by the community with the vaults and the user run network, a lot people effectively helping by providing logs, searching for bugs, etc., I’m really proud of belonging to this community and project.

Now, this should be probably posted in this other thread, but I would really love @fergish to have a podcast with a few of these folks who were running the user run network and participating in this community for a long time all together, to hear their experience, comments, thoughts, funny and sad stories in this SAFE journey, I think it will be so much fun and I think we can all learn a lot by listening to them.


#14

excellent! - glad to hear that things can go further now in that sector =)

oooh - that totally makes sense! - a common config file Oo will make the whole system more reliable :slight_smile:


#15

Could someone ELI5 what safe_app_nodejs means for application level interaction with the network?

I rather liked this post on node.js and npm from @happybeing on the dev forum back from December, as I’m fairly in the same place now

node.js/npm is just a lot to get your head around, so a barrier in other ways, and clearly I still haven’t got there yet.

REST is easy - anything can put out a call in a certain format that the API understands and receive back a response that’s readable … json or similar.

What are the limits on interacting with the node.js or is it for all purposes the same as a REST API?

My experience of npm is limited to wondering that it’s a very large tool for cracking a small nut and always struggling not to install it at every compile action. Nooblike but it’s another hurdle in the way of user that understands something is possible, trying to get it done.

So, how will an application make a call via or to the nodejs?.. is it similar to REST API??.. I can understand it’s trivial in browser as it looks like javascript but it’s one step away from my comfort zone.

Also… and I expect I’m being daft but where are the docs at:

Edit: I see now unofficial copy which looks useful


#16

@MaidSafe does the SAFE Browser work on Android / iPhone?

If not then what are the plans for porting it?

That’s the whole reason you’re making the Authenticator right?


#17

Beaker has not build for Android devices. But it can be done.

And as for the authenticator, you can still use Safe-JS, and build android applications.


#18

Thanks for that :slight_smile: safe-js FTW

But @MaidSafe are you planning to make android / iOS browsers for SAFE?

Maybe another CEP?


#20

To clarify, this is the official docs (not my work), but published unofficially.

I built them from the safe_app_nodejs repo (and even had to ask Ben how :blush:). I didn’t mean to give the impression I did significant work here!


#21

So, how will an application make a call via or to the nodejs?.. is it similar to REST API??.

I don’t get it very clearly either: is the rest API dropped ? How would a non js app talk to the network ? Say a c++ or a rust application.

I have been away from recent Safe development so it seems I missed a train :slight_smile:

EDIT reading about safe_client_libs right now…


#22

There’s already Rust API. But the problem is that Rust ecosystem is new. To build around that is not feasible right now. There is no “stable” GUI for rust. It’s bleeding edge so you gotta keep update with it.