MaidSafe Dev Update - 6th September 2016

Last week, 3 new RFCs were submitted:

The focus of these RFCs is to expose new API features (Structured Data API, Immutable Data API and Appendable Data API) for app developers as well as to improve the efficiency between safe_core and safe_launcher.

Our main chunk of work this week is to implement RFC 38 – Appendable Data, RFC 41 – Low Level API and RFC 42 – Launcher API v0.6 so we can get going with the tutorial/example series.

Click here to see all the RFC discussion topics on the SAFE Dev Forum.

We welcome developers and community members to comment on the RFCs :slight_smile: We would especially like to hear feedback from app developers on RFC 42 – Launcher API v0.6.


The safe_core FFI changes are being integrated along with the React/Redux code refactor. This should get safe_launcher working with the latest master of safe_core. Testing the refactored code base and fixing the issues identified as an offshoot of the refactor will be addressed this week.

Low level API integration is also in the pipeline for this week, and will likely take until next week to complete.


Spandan and Adam are currently implementing RFC 41 – Low Level API.

Routing & Vaults

Andreas and Qi are working to implement RFC 38 – Appendable Data and Fraser is focussing on RFC 37 – Disjoint Groups.


We wanted to share some next steps for MaidSafe and the future of the SAFE Network. On September 12th we will be launching an equity fund-raising round with BnkToTheFuture, a leading global online investment platform for qualifying investors. MaidSafe is looking to raise between £1.75m and £2m during the 30 day campaign.

Read this blog post for more details

New Team Members

Nikita (@nbaksalyar) is starting from next Monday. He’ll be working with Spandan.

Ben (@lightyear) is starting from this upcoming Friday (one day per week for the first month and then full-time). He’ll be working with Krishna.

Dev Tutorials

The content of the first tutorial is being worked on and the code examples are about to be integrated. We agreed to use GitBook to generate and host the Dev Tutorials. It has a very good default theme and it’s super easy to learn and use.

SAFE Browser RFP

We’re looking to have a few discussions with @joshuef now that he is back :slight_smile:

We hope the next stage of development will expose SAFE API endpoints that would allow devs to build web apps that don’t require users to configure the proxy :grin:

Dev Forum

We added a Support category for developers who need help with the SAFE Launcher API. Thanks to @lightyear for his suggestion!

Also, there are now two new mods: Ben (@lightyear) and Rob (@neo).

And as we announced in the last Dev Update, we are planning to close the MaidSafe-Development Google Group (by making it read-only). All the content of the Google Group will still be easily accessible and searchable, but users won’t be able to create new topics. If there are no objections, we will do this tomorrow.

We encourage developers to sign up for the SAFE Dev Forum instead.


Is there any additional info on the current alpha/Test 8 release as far as how it is doing for performance/bugs/etc? Hopefully it is cruising along as expected! :slight_smile:


Keep doing what’s required :ant:


Yes alpha is coming along nicely, we will get some stats for it and post them. A few folk had issues (very few) with proxy setup so be great to see that gone. Testnet8 is as expected (hobbling along) until we get to the data republish & unbalanced nodes which will allow these to combine. Work there is progressing and we expect at least 1 more testnet but perhaps more depending on results. Should not be too many though as the unbalanced nodes issue is the showstopper for connecting the Alpha and vaults from home.

We will probably restart with testnet9 in the coming weeks though to confirm the current RFC work which has been rather intense in terms of refactor. Alpha releases will continue in parallel until we are satisfied the unbalanced nodes is solved effectively though.


Thanks for the update & your hard work Maidsafe team,

We’re getting there, exciting weeks ahead :stuck_out_tongue:


I read in the RFC 42 that there’s a versioning issue for appendable data? I’m not sure I fully understand the intricacies of NFC and what not but if there isn’t a hardcoded versioning system perhaps one could patch something together on the app or software level. Like if changesubmitted() then version++ or something. You know slap the version record into a json file and upload it to a github database or something along with the app. Also if you’re going to be using Gitbook (which I assume is dependent on Git) I’d recommend having a “Git for Dummies” tutorial handy. I for one have yet to figure out how to use git and yes I’ve tried, oh lord I’ve tried.

1 Like

Great to see things moving forward so well, and congrats to the new team members, @nbaksalyar and @lightyear!


Why is there so much work being done on secondary things? I would have thought at this point that most manpower would be focused on the core functionality to get an actual release out that runs on a public network.

Why API refactor when old one already works? This directly pulls resources to update launcher api implementation. Why introduce low level api when high level is there. Why add appendable data when there are several types already that have been verified to allow much functionality? Why write tutorials when there is yet no product to target?

Which of these are stuff that are intimately linked to the core routing/network/vault aspect and necessary to take it forward, and which are stuff that can be added once the basic functionality is ready? With no deeper knowledge it looks that from the rfc:s mentioned only disjoint groups is such necessary work and it was not even mentioned in the “our main chunk of work” part.

Is this a case of “too many cooks spoil the broth” and additional manpower simply won’t help? Is it because the other devs are not experienced to work in that area?

The hard fact is that not many outside people are going to start invest resources into researching and developing apps and sites for safe network or join in as a volunteer developer helping with the project before it is proven to actually work.


Not at all, there are two teams with differing skillsets here. The core functionality in routing and vaults has new members coming in to help. The other team works in getting the API’s available for application developers.

Our decision was to run these in parallel and provide the app devs the resources they require and at the same time allow the core vault code to get through the RFC’s and actually be able to test the client requirement as we go along. The current client API’s being introduced allow for instance messaging/chat/video conference etc. plus Wallets to be created as well as giving some great functionality to decentralised dynamic applications.

So there is cross over for certain, but all of this work really needs to happen to allow safecoin for 1 and a reason to use safecoin (beyond cash) secondly.

Hope that helps a bit. If something is not launch focussed then it’s just not done, but the client side should not stall for the vault side, they both must happen and developers need to get involved and build apps, even without vaults from home right now.

[Edit I should add disjoint groups is a huge part of work with three folk on it as will data chains be. After disjoint groups we have a smaller rfc (secure name/join) then data chains and in parallel probably vault start/reward]


Does this mean that the existing functionality did not make it possible to implement wallets & safecoin? Or do you mean that this added functionality allows for a better design and more features in wallet and safecoin?

This sounds really nice, but the dev update seems to mention only one person working on it?


Yes that is right, messaging is in part required for safecoin (it’s how a client is told they have farmed for instance) . Also dynamic apps are really important.

Andreas, Fraser and Qi are all on it, Viv and myself are involved in a lot of the design discussions as well. Of course they are also working on AppendableData types In routing plus a load of RFC work which is vital. So everyone is really busy, when we have 5 folk on a hangout for design rfc work it’s bad enough (Viv then has the other teams design hangouts as well, lucky fella) , if all 10 were then it gets too wild and expensive in terms of wages and effort.


I mean that in general, was not the existing functionality, data types etc. enough to implement messaging, leading to wallets and safecoin?

I hope i am misunderstanding you (or you me) because the way i read it is that the old design was lacking, and now new features are being invented to expand the functionality.

1 Like

Thanks to the team for all the hard work! And welcome to the new members.:grinning:


Structured Data was enough for safecoin I believe but I think they just want the Eco system boosted along with the addition functionality that the low level api’s provide as well as appendable data so that with alpha 2 devs can be easily dive in and have easy to follow tutorials and once beta hits we have tangible things for people to play with. What good would an app-less and empty network be at beta? I think it’s a good decision


The new design is more generic and useful for all app devs. Previous messaging is not off the table but is more work.


These are really really good questions, and ones I’ve been wondering also. Should be launch launch launch right?

I think that maybe perhaps Mr. Irvine and MaidSafe want to see certain things before they are comfortable with releasing a launch / SafeCoin / live version perhaps, like a few running & successful apps being made & used with all the new APIs from the new RFCs, and other types of things like that.

Seems like a battle of philosophies. On one hand we have the old programming saying “done is better than perfect,” and on the other hand we have things like the DAO being hacked for lots of $$$$ so I think they are trying to find the balance, and perhaps not as “launch tomorrow” focused as you are asking for.

Just my thoughts, after mulling this thread over for a day or so.


Yeah just think about it without stuff to play with at launch the whole thing loses a bit of momentum. Say you launch with just a secure network which is still amazing it’s why we’re here. But we don’t need just developers at launch interested or say hobbiest farmers, we need users. What do users want? They want websites, services, social networks. If it’s not there they won’t come back right away, if there are no users then the developers have far less incentive to create apps. They both have to be there at the pinnacle! Public launch! If things look great at beta then public launch will be even better. Stay positive @whiteoutmashups


If you read my message i did not imply that launch should be a priority over all else, just a beta launch (or call it alpha n) just the key point was that a product is released that works in the wild and not on maidsafe’s servers. After that is out and is working correctly, then i think the current approach would be perfect.

But dirvine explained the reasons quite well IMO.