MaidSafe Dev Update - April 27, 2017

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?


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

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


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 !!!


Do we use node to use this MD?

safe_app is node I think. I’ll DL

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.


Womp womp. We just deflated :expressionless:

1 Like

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


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


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


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.


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!


Amazing update. Waiting for next one!:slight_smile:


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.


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.


Why can’t we have SD, and MD?


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

I respect what @tfa is trying to say and think we need to listen to it


i dont know enough about it but it seems that losing ownership transfer and multiple owners would hurt the ability to have a team working on website development.


This is still being worked on and will be (re)-enabled with data chains more efficiently.

This is only temporary while some parts in routing ensure double votes/conflicts cannot happen. It was for now only having a vec of size 1 and not handling more than 1 sig in the vaults that meant it was misleading. 100% multiple owners will be the case though.

I think this part is possibly still up for debate, depending on size of dir object verses speed of recovery of the objext etc. It’s worth a debate for sure, even better and RFC, but I know we have been poor recently with community RFC’s (which is wrong to even say community RFC’s as they should all be equal), it’s pure resource at the moment. There is a huge hill we are climbing (hopefully near the top) with the internals of routing and vault interaction that will allow all of this and much more.

If we fix the shared ownership part properly then shared private data etc. will all be solid, but all at once. It’s small steps right now and ensuring the foundation is solid and mathematically proven where possible that will enable many more eyes on the API and how to make sure it’s the most powerful it can be, including pay for Post etc.

I hope that helps, not a defence or criticism, just a view from the other side of this hopefully short lived fence right now.