SAFE Network Dev Update - July 18, 2019

This is the plan.

The guys are working hard to allow old and new, I am much more in favour of migration to new only though. I will let them answer, but I hope not to scrap and start again but adapt to new API where the calls will be slightly different (there is safecoin). I will let the guys chime in here, but I would like to get everyone to the new API as soon as we can, although we are also looking (you will see in the CLI) at having a high level API that is even easier to use. In whatever case though we will make migrations as easy as possible as we don’t want to lose apps.


I’m not too affected either way, and all my code is built on SafenetworkJS, so in theory I’ll only have to migrate that.

I think there’s a benefit in taking old apps across to Fleming as is, but if that isn’t supported I’m OK with that.


It is a goal for sure. Even if it may mean we help migrate on some occasions. We will try to make it painless though. I am excited to see what folk (hint hint) do with RDF now :slight_smile:


In Client Libs the new API is very similar to the older API. Even though the older API will be fully deprecated, migrating to the new API will be very straight forward.

The MutableData type still remains as unpublished sequenced MutableData and ImmutableData is now Published ImmutableData.

I see the new data types as additions rather than replacements :slight_smile:
So what’s new is,

  • Unpublished ImmutableData
  • Unsequenced unpublished Mutable Data
  • (Published / Unpublished) (Sequenced / Unsequenced) AppendOnly Data

@happybeing I believe that your code will be using the safe_app_nodejs package. Right now, I’m not sure what the plan with those API, but, as David mentioned we are planning a uniform high-level API in Rust so all languages can have similar public API.


Thanks again Lionel. What is sequenced and unsequenced?

I made a table which I hope summarises the above:



Had to look it up …


Thanks @lionel.faber very helpful

Sequenced means updates are indexed (sequenced).


And is published == public, or is it more subtle than that?

Can you define what unpublished/published means?

I can try to look it up, but i think it’s worth bringing into this thread for completeness.


I absolutely hope that you focus 100% on the new and don’t waste time on keeping it compatible for anyone having worked with old API. How many are there? Me, Nigel and Mark? The rest are dormant. It’s not worth it. Just make your life’s easy and do what works best for you to get the new stuff as good as it can be. We will adapt. And we are just a few, there are thousands of people, who don’t yet know it, who waits to start using the new stuff.

The update:

So much is happening that my head is spinning. I want to take part of it all, but I can’t! We are getting to MVP, beta and release with big steps though. :heart_eyes:


I’m happy you are voicing this out loudly @oetyng, I fully agree with that, we need to move forward and push hard, we are trying to have this high level API in a way that adapting to it would mean replacing N lines of current code with one single call.

Apart from that, I believe we shouldn’t be afraid of such adaptation and we should remember what we are: early adopters? no, we are the devs who are leading the way for thousands of people and devs, we are the devs to find the path so they have a simple and nice dev-UX when they arrive, as we know they will arrive, and we will be the ones welcoming them with our nice early developed apps to show the magic


Published Data

Published data refers to the content that is published (made available) for everyone. For example: websites, blogs, or research papers which anyone can fetch from the network and read without requiring any permission. For such public content, it becomes important to retain a history of changes. History MUST not be allowed to be tampered with and the published data MUST remain forever.

The AppendOnly data type is pivotal for data perpetuity, because it ensures the published versions are always available unlike the default behaviour of MutableData where the value can be overwritten. This is central to prevent censorship of information.

Data perpetuity is one of the fundamentals of the SAFE Network, which ensures the users of the network SHALL be able to store published data in perpetuity.

However, only the owner(s) SHALL be able to append the changes based on the permission.

Unpublished data

Not all the data is desired to be made public. Personal data or organisations’ data stored on the network is not supposed to be accessed by everyone. Since the data is not published for everyone, this is called UnpublishedData. Only the owner(s) SHALL be able to access and manage the data based on the permission.

The network should also be able to provide the flexibility for the users/developers to create private data which can be versioned or mutable based on their needs.

Private Data

Users should be able to store private UnpublishedData on the network which is not accessible by anyone else.

Shared Data

Users should be able to store UnpublishedData on the network and share it with a closed group. The user should be able to give permissions like read, write, append based on the use case. For example, a collaborative document which is meant to be worked on within a closed group.


:+1: Whatever delivers Fleming fastest gets my vote.


Hey @oetyng! I’m working away quietly! Very simple stuff though, so should be easy to move across to any new API.

This was something I was asking about at the meet-up. Fully appreciate all the recent roadmap stuff, but it did leave me a bit lost in relation to old milestones. Maybe a super high level explanation of this sort would be useful somewhere in the literature.


What’s the reason for having sequenced and unsequenced rather than just allowing ‘version == any’ and just having sequenced?

Currently NFS emulation is sequenced, but you can just pass version 0, to update regardless of the current version.


In some scenarios you want to make sure you are updating/appending on top of specific version/data, and you may need to know if that’s not the case and get an error. If this is the case you are dealing with then you need sequenced, if not, if you don’t care which data was there before you send your update/append request, then you can use unsequenced which potentially can also simplify your code.


I’m wondering why have sequenced and unsequenced rather than sequenced, but with the option to ignore the version when updating. That seems a simpler API.

I’m not clear from your explanation if there’s any difference in the capability between the above and sequenced/unsequenced.


I have been thinking this as well, and asked in the RFC topic.
I came up with one reason, was about to write it there. In a decentralised setting, it makes more sense than when accessed only by me / my organisation / my app. Because there might be constraints that are essential for the logic, but that simply won’t be upheld in a decentralised setting. (Not sure if that thought holds to scrutiny though.)

A compromise I guess would be to make it

Optionally versioned,

Where OV replaces unsequenced, and takes the version parameter like you and I suggest, and versioned is the same as Sequenced.


This is great.

This is great as well.

Great update, as always.

This makes a lot of sense, as far as I understand. Thanks for sharing David :+1:.


We are making great progress, and the progress is accelerating.

Thanks so much to the team for all of their hard work!


That’s not strictly true yet. It_could be_ the same mock vault as the browser. And hopefully will be soon enough, but as yet uploading things via CLI will not affect anything in browserland.

The browser needs to be updated with the new APIs once we’ve finalized NRS fetch.