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.
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.
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’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
Versioned
Optionally versioned,
Where OV replaces unsequenced, and takes the version parameter like you and I suggest, and versioned is the same as Sequenced.
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.
Great news on the marking front with all those meetups. That can only bring new investors so keep having these events!
I think that’s a great idea to really decide on brand identity you want to stick with til the end. Especially in this field where newbs are like so um WHICH bitcoin should I buy? Make it very clear this is the real SAFE network and not several different animals for new people doing research.
Published cannot be deleted, unpublished is more like private data, so you can delete/amend it. Only owners can Get unpublished datra. Vaults can see it. but not publish it, if that makes sense. So a bad vault could return it, but generally, it won’t work. That data is not able to be used as publishable or Gettable by users. So a browser, for instance, won’t try and get that data as the type is wrong unless you are the owner.
Haha, yes of course What I meant was that the mock vault now used by the CLI is the same file that all applications will use when the use the latest SCL API
With regard to this, it’s the API that is designed this way. If you pass GET_NEXT_VERSION or 0 as the version then Client Libs will fetch the latest version from the network, increment it and then apply the mutation. For the unsequenced data types newly introduced, the network itself will not expect valid versions and updates / appends can be constantly performed without any versioning check. This would prove to be useful in cases like IoT devices that constantly stream data. If multiple devices append entries to the same AppendOnly Data then it not be feasible with versioning.
Many thanks for answering my questions to Maidsafe and community members.
It helps me a lot and hopefully others too. I make notes from these things which i can then refer to while I’m building stuff if I can’t recall how things work.
I’m continuing to make progress with Solid apps atm, and very much looking forward to getting to grips with the new APIs. First task will be to look at SafenetworkJS to see if it is worth keeping that, or moving directly to the new higher level stuff. My guess is to start with migrating it, but maybe deprecate it later, but it depends how quickly the higher level API becomes available, and whether or not I maintain SAFE Drive which I suspect will require the lower level APIs (in order to work with FUSE). I’m sure some parts of SafenetworkJS will remain useful, but expect/hope much of it will be redundant. If any of you are building with it, let me know because maintaining support for others will also be a factor to consider.
I’m also interested to learn if Deno will be a better way to offer stand alone packaged node style apps (like SAFE Drive) as well as the basis for a SAFE package manager. Again lots of scope for others to get involved in this, feel free to jump in, the water is lovely.
Also Mark, this is a great post (and library) for using CRDT type (actually it goes a bit beyond/different) data. Looks great https://www.inkandswitch.com/local-first/ I can see us doing similar things in the future, possibly in the network, but in any case it is a great read.
Indeed! Super important not to build a decentralised network and then have all development centralised through one company, even if that entity is the MaidSafe Foundation.
Looking around, the only project i can see that has some degree of success with decentralised decision making is Tezos. It would be sensible to take a peek over there and see why they have had such success, and if that could be used on the Safe Network to incentivise developer contributions and to automate network upgrades.
It would seem to me that the reason they have such a high voter turnout is the baker/delegation model. People can delegate their tezzies to a baker to gain a % of the proof of stake rewards, but this also gives the baker the network governance voting rights of the delegated coins. If there was a way to implement something similar on Safe (ie delegating your spare storage to a farmer for lower % of rewards but with no configuration hassle) it could be a way to decentralise important governance decisions on the network.
Whatever delivers Fleming fastest gets my vote.
