MaidSafe Dev Update - April 27, 2017

Development Updates
1

As mentioned in previous weeks, our work on the Mutable Data integration with a view to releasing the next testnet continues. About 50% of resource is focussed client-side, while the rest of the team work on supporting Alpha 3 (node ageing, data chains and increasing the scope for running Vaults from home).

SAFE Authenticator & API

Through the course of this week, we have been updating the APIs and testing them. Although the majority of the APIs are stable and tested, we did spot a couple of issues and inconsistencies in terms of API usage with Mutable Data. There is an issue with deleting keys from Mutable Data. Other than that, the private Mutable Data API expects the keys to be encrypted before fetching the data, but it is not the case while saving the key and value. We are discussing a better approach to maintain consistency in terms of the API usage. @nbaksalyar is helping out with these fixes from the Rust side and we will be updating the APIs to reflect the fixes. Basic crypto helper functions are now exposed from safe_app and the same must be exposed from safe_app_nodejs.

We have also been testing the applications using the mock network and it does seem to be far more stable than previous iterations, which is very reassuring. While some known issues are addressed, we will be carrying out some regression testing with the apps and we’ll update the API documentation once these issues are resolved.

@Kumar has been a lone warrior battling with JNI and JNR. JNI samples seem to work on desktop and also on Android. He is trying to troubleshoot the JNR issue with Android. If he finds some positive results with JNR in the upcoming week, it would be really helpful in terms of maintenance and integration.

SAFE Client Libs & Crust

The Mutable Data PR is undergoing more review. The dev branch of safe_client_libs has already implemented and tested Mutable Data against the mock routing and mock vaults. We decided to run the tests with actual routing and vault’s Mutable Data branch, and the extensive test cases in safe_client_libs helped us find a few inconsistencies and bugs in both vaults and safe_client_libs. Some bugs in safe_vault were caught by safe_client_libs tests and a few in safe_client_libs were caught by the corresponding correct code in vaults.

safe_client_libs and frontend integration continues smoothly. We have added a crypto module to help the frontend not have to go to sodium package integration as that could be less secure but more importantly was conflicting with the versions of libraries used. Tapping straight into libsodium via safe_app dynamic library is also not very friendly so we just added FFI interface and helpers to the Rust code itself.

Routing & Vault

The first part of simplifying the node names has been merged.

The missing checks to avoid adding unauthorised nodes to the routing table have been added.

Thanks to the fake clock, we are now able to do some cleanups in our test code and make it more realistic. No explicit “now assume everything timed out” anymore!

The next step of the data chains proposal is currently being internally discussed and it will be published when it’s ready, while the routing design team is also looking into the details of node ageing.

58 Likes
3

First reply two weeks on the run, is that a double first?! :slight_smile:

13 Likes
4

Second… Was really looking forward to the new auth browser

4 Likes
5

I can actually test apps with mutable data now?! Even though it is unstable? What type of errors that I and other safe devs should be aware of?

5 Likes
6

Oh what, that’s what it meant?? :smiley: :smiley:

7

#Live call! Ask ?'s here / get support on new MD etc!

4 Likes
8

Awesomeness :smiley: if we can work with MDs on mock, then I’ll start learning the API again :sunny:
Could someone @maidsafe give a hint on how much we can expect it to move from its current state ? Deep fondamental changes ? Or more smallish fine tuning ?
Thanks for the hard work again !!!

6 Likes
9

Do we use node to use this MD?

safe_app is node I think. I’ll DL

10

For most apps, you would need the layer above safe_client_libs (SAFE Browser with authenticator + a language binding such as safe_app_nodejs). Some issues still need to be addressed as mentioned in the “SAFE Authenticator & API” section.

5 Likes
11

Womp womp. We just deflated :expressionless:

1 Like
12

Thanks Maidsafe devs for your hard work.

It’s really incredible the amount of tests you guys do to get this thing right. Good code takes time, bad security code is our current internet :stuck_out_tongue:

Keep up the good work, because this is far from easy

11 Likes
13

“Be the change that you want to see”. This is what Maidsafe does. Heads down to the keyboards. Code on. Slow and steady.

2 Likes
14

Sorry for the delay. We are trying to wire up the loose ends and missing pieces, should be good to try out sooner.

You can try the APIs and the authenticator by building it on you own following the instructions. We do have few inconsistencies in the usage of the API ATM and we are trying to address the same in the next few days. One known issue is with deleting a key from the mutable data,. Deleting a key does not remove the key from the entries, instead it clears only the value associated to the key. Even the examples in the documentation might have to be updated in certain places.

Trying the APIs this week can be a bit of a hassle as it stands, however we hope it should be good for devs to try and test from next week. We will have to get the docs and examples updated for the same too

14 Likes
15

Clearing the value is the right thing to do, and was what was originally done with SDs. See following topics (they are very long but first post of first topic summarizes my points very well):

Later, this post was a confirmation that this principle would also be kept with MDs.

So, they have changed their mind again, but I won’t debate a third time because this is too exhausting and I have said everything I could on the subject in these 2 topics.

6 Likes
16

I might be wrong here too. From an app devs perspective if the key is still existing as an entry, then there must be a means to identify it as deleted. I still feel, it is a limitation where the clarity to differentiate between deleted entries and non-deleted entries could be better. If it is going to be the same way as it is, then from the API side we should not allow empty values to be inserted. Thus, mentioned it as a limitation in case some one tries to delete and still finds the key in the mutable data.

We have limitations to the number of entries in a mutable data and if we don’t clear the keys then it might be a difficult task for a app dev to design and work with. I hope there will be a better solution in the near future which can be debated.

I will read through the posts linked anyways, thanks!

13 Likes
17

Amazing update. Waiting for next one!:slight_smile:

4 Likes
18

Keep up the hard work @maidsafe I’ve been invested for many years now and I continue eagerly keeping up to date with the project.

4 Likes
19

Never mind. Do what was planned for you.

There are so much things that were lost in the transition from SD to MD, soft delete is only one element among others:

  • removal of signatures (for proof of ownership transfer and optionally proof of acceptance)

  • owner key having a coarser granularity than unit of modification

  • multiple owners not possible anymore

  • file datamap not stored directly in the directory object (its name is stored instead)

IMO SDs were better than MDs, but this is a lost cause for me and changing only one element is of no use.

8 Likes
20

Why can’t we have SD, and MD?

8 Likes
21

One way would be to increase the allowable entries by one and that entry is a list of deleted keys (in order). So a delete key would remove the key entry and update that list at the same time.

That way anyone can ask for the deleted keys and know if a key has been deleted then recreated.

1 Like