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.
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
So what’s new is,
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.
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.
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.
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 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.
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.
Users should be able to store private UnpublishedData on the network which is not accessible by anyone else.
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.
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.
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 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
Where OV replaces unsequenced, and takes the version parameter like you and I suggest, and versioned is the same as Sequenced.