MaidSafe Dev Update - November 15, 2016

Today we are releasing the SAFE Markdown Editor along with a dev tutorial that shows how to build a text editor that stores its data on the SAFE Network :tada:

The SAFE Markdown Editor lets you create and edit Markdown files. The files are encrypted using a symmetric key, which means that only you can read them. Each time you save a file, a new version is stored on the SAFE Network. You can browse through previous versions of your files and compare the difference across versions. This example demonstrates the usage of versioned structured data.

We are also officially releasing SAFE API v0.6. We updated the SAFE API Docs website. It now contains documentation about the Low-Level API:

SAFE Launcher v0.10.0

This new version of SAFE Launcher is compatible with TEST 11. The previous versions of SAFE Launcher (v0.9.2 and v0.9.3) should continue to work fine, but we recommend using the new version (v0.10.0) instead.




  • API version updated to 0.6
  • Fixed issues #285, #289, #292, #293
  • Minor nitpicks
  • Tests cases expanded

SAFE Browser v0.4.2

We recommend using the latest stable version of SAFE Browser (v0.4.2) in order to use the SAFE Markdown Editor.



See this Dev Forum topic for the latest news on SAFE Browser.

SAFE Markdown Editor v0.1

Live version

You can access the SAFE Markdown Editor at safe://editor.safedev using SAFE Browser v0.4.2.


SAFE Comment Tutorial samples

We had to update the comments plugins to make them compatible with the latest versions of SAFE Browser (there were some changes to the authorization code).




  • Compatibility with SAFE Browser v0.4.0-5 and above

SAFE Demo App v0.6.2

The previous version of SAFE Demo App (v0.6.1) should continue to work fine, but we recommend using the new version (v0.6.2) instead.

When uploading files using SAFE Demo App, the maximum file size is 25 MB per file.




  • Fixed displaying service list if service home directory is not found

Other apps and tutorials

You can access the SAFE Signaling Demo at safe://mediawebrtc.ben using SAFE Browser v0.4.2.

To download SAFE Mail Tutorial, see this topic:


If you need help with anything related to SAFE Launcher or SAFE Demo App, please use the #support category on the forum.

If you need help with anything related to the Dev Tutorials, please use the #support category of the SAFE Dev Forum.

Where should I report issues?

If you know which component a bug is associated with, feel free to report it on GitHub in the corresponding repo.

If you’re not sure where to open an issue, you can simply create a new topic on this forum and add the #bug tag. @lightyear and I are subscribed to the #bug tag, so we will automatically receive a notification whenever someone adds the #bug tag to any topic. We’ll take care of opening an issue on GitHub if necessary.

If an issue is specifically related to the SAFE API, then it makes sense to use the SAFE Dev Forum. But for issues related to end-user applications (e.g. SAFE Launcher, SAFE Demo App, SAFE Browser, etc.), it’s fine to use this forum ( Most users already have an account here :smiley:

SAFE Launcher

As mentioned above, today we officially released SAFE API v0.6 and we updated the SAFE API Docs website.

We also released a new example app (SAFE Markdown Editor) along with a tutorial that demonstrates the usage of versioned structured data. The tutorial series now exposes a few use cases for appendable data and structured data. The existing tutorials are still going to be supported, but there will be a period of no specific activity in terms of new tutorials.

For the next few weeks, we will be focussing on getting the required changes for SAFE Authenticator in place.

Earlier today, we published an RFC related to the new authentication flow that was first explained in the topic about the future of SAFE Launcher. See this dev forum topic for more details.

New authentication flow

The current authentication and permissions handling flow relies on SAFE Launcher, a stateful intermediate between any particular app and the network. While this allows for fine-grained control over the access flow and user setup, it has the drawback of requiring the process to always run, keep a local state and proxy all network requests. This is particularly cumbersome on embedded devices and mobile, where we cannot provide this pattern reliably.

RFC 46 – New Auth Flow proposes to replace SAFE Launcher with SAFE Authenticator (a stateless alternative). The RFC outlines a new process to give applications authorised access to act on the SAFE Network with the user’s credentials. In particular, it is designed for the mobile and embedded use case in mind.


Over the next few weeks, we are going to be implementing the changes necessary to support a SAFE Authenticator based paradigm. In addition to working in safe_core, we will also be making the necessary changes in routing and safe_vault. That way, the Routing team can continue focussing on implementing Disjoint Groups and Node Ageing.

Earlier today, we published two RFCs related to app permissions and app management. See this dev forum topic for more details.

Granular permission control

Existing data types don’t support granular access control which is required for mobile platforms where access to the network through an intermediary like SAFE Launcher is complicated: each app would have to receive full permissions to modify and fetch data on a user’s behalf and private keys to sign it. This compromises security and allows malicious apps to get full access to the user’s data.

To mitigate that, MutableData provides fine-grained access control and more narrow-scoped data operations. This data type is an evolved version of AppendableData. It combines StructuredData and AppendableData features and improves the network efficiency, saves bandwidth, and provides a standardised approach for apps to fetch and mutate data in the network.

RFC 47 – MutableData proposes to combine StructuredData and AppendableData into a new single data type, MutableData, similar to HashMap.

Authorize apps on behalf of the owner to mutate data

If the requests made by the permitted apps need to be charged these must all go through the Maid-Managers and they should know about the owner that an app is associated with so that they can charge the correct account.

RFC 48 – Authorise apps on behalf of the owner to mutate data details how apps route their mutation requests to Data-Managers and how revocation works.

Routing & Vault

We implemented the new way of collecting signatures for group messages, but there are still cases (messages from a group to itself, messages to clients) where some more work is needed. We are considering doing the accumulation in the group itself instead of in the first hop (a neighbouring group) to simplify the message flow.

Debugging and re-enabling the mock Crust tests is still ongoing (it’s a lot of tests!), but we’re making steady progress.


Thanks for everything you all have done and are doing!


Does this include any changes that @Seneca requires as mentioned here


Excited for mobile!!! I know that’s a ways off but the groundwork is important now for it to be ready when everything comes together soon enough. All of the example apps are very very cool, I hope they stay up to date so they can stay a valuable resource to developers. Can’t wait for routing to be sorted out but it is one heck of an overhaul and there is obviously some optimizing going on there. Good luck team, the world is watching and we’re ever so anxiously but realistically waiting for release.



My humble congratulations to the whole MaidSafe team for all the achievements as well as these dev tutorials which really showed more clearly the huge potential of this project and technology! Thanks a lot!


Is this markdown editor the baby of @lightyear ?
I think I remember seeing ghost in a safe or something like that, so this uses or is similar to the ghost markdown editor? I never use markdown but it’s cool for all the future safe bloggers :slight_smile: cool stuff


It’s Krishna’s team with input from them all, including Ben :slight_smile: He has been a great addition there and outreach. Much more to come though.

The next/current sprint is still vaults from home, but the core and client guys will get the authenticator in place plus settle the immutable and mutable types, so a ton for them to.

This shows markup as an example, but we hope devs can take this and have any type editors (should be easy) with syntax helpers etc. then perhaps even github like shared development / editors. Basically though it’s a skeleton for apps using the network for direct user facing content. So CMS systems and much more should be simpler now and help those devs that have already strayed into that area.

The examples have been great for us in house and they have caused a huge amount of meetings and the teams have trimmed the background types and capabilities as you will see with the slew of RFC’s. All in all this means the network should have much more capable fundamental types allowing a much better developer experience, well we hope so anyway :slight_smile:

I think this also see’s the RFC’s bringing in a lot of stability into the API with the next few weeks changes happening. I really hope we can have a fantastic end of year here, but it is a deluge of work in many areas, so we will see. I feel confident that we have reached a real milestone here though in terms of capabilities where folks always had questions about using the network for various static and dynamic “stuff”. A pre-rfc over in the dev forums looks also very interesting with chat about semantic search and deep learning capabilities. Now that woudl certainly put SAFE in a new light. We will see where that goes, but it will be after launch I think.

Still need to get some CEP stuff going as well, we have all been too busy to help out there. Lets see if we can change that in the new year.


I’m trying to republish my web page, incorporating the new editable comments. I deleted the old files and uploaded the entire directory. It seemed to work, but not all the files were showing up.

I then tried to see if I needed to republish it. When I go to “Manage Websites”, I get this…

So I then say, OK, I’ll create the service again. But that fails also.


Unless I misunderstand, you deleted the entire directory, and then uploaded the new directory.
My guess of what’s happening here is that the new directory is internally not the same directory (different address) as the one your deleted which was linked to the service, even that it has the same name.
I’m assuming the services are mapped to directories using their addresses and not their names.
So if you deleted only the files within the directory but not the directory itself that could have worked just fine.
I’ll leave it to the dev guys to confirm my guess is accurate though.

Did you remove the service before tying to create it and map it to the new directory again?

Thanks Maidsafe Team for another great update,

This is more aimed at the SAFE Browser (not really an issue), but we have an app that’ll be SAFE Network and clearnet (clearnet because the website we’ll link to will still be on clearnet for a while). Would anybody mind if the SAFE browser just worked like Tor, meaning that you no longer have to toggle between SAFE Network and Clearnet? It’s already asking a lot to let people change a browser to access your site, but also having them toggle from one net to another might be asking to much. It would also be fun (easier said than done) to see the browser have a integrated vault + a wallet like brave browser.

Thanks again for your hard work :stuck_out_tongue:


No, I did not.

It would be nice to have the ability to blow away the detritus so that we could recover from errors like this, even if it meant needing to re-upload all the data.

I think it is actually possible to recover, just delete the service and try again.
In any case remember this is just a demo app.

I can’t. It gives the error message I showed, and when you clear the error message, you see that you have “No services registered”. But when you try to add the service back, it says, “DnsError::ServiceAlreadyExists”

Agreed it’s just a demo app. Not complaining, just highlighting, in case this is a bug that was just introduced, so it can be looked at.


I assume you deleted the directory www and uploaded the contents again. If the directory mapped to the service is deleted, then the new directory created must be remapped. But right now the demo app wont allow because it is not able to read the deleted directory.

Created an issue in JIRA for this one, will get this fixed.

Thanks @Tom_Carlson!


@Seneca had asked for transferring ownership of data. This is being made available as mentioned here in the RFC.


This is awesome and eventually could lead to a text editor or word processor that saves files to the save network. However with that thought in mind documents, even text documents, can get rather large and doesn’t structured data have a size limit on it? What happens when the document size exceeds the structured data limit?

1 Like

App can create the DataMap using the immutable-data API and save the DataMap in the StructuredData. The email app tutorial demonstrates the usage of immutable-data API.

Should be fixed in the patch release v0.6.2 of Demo App. Please do let me know if the problem still persists. Should be able to upload a new directory and remap to the existing service


Thanks for the shout out @Nigel, but if you look closely at the commit history, you’ll notice that while I started that example, most work was actually done by @Shankar. He did a great job and deserves the praise for this one!

I was busy taking all that experience we gathered building the previous examples into the new data type and authentication flow RFCs we’ve published. To make developing for SAFE much easier and more comfortable. The examples where a great way to gain more experience with the API and we know a lot of things we will improve now :slight_smile: .