While the new data types offer a wide variety of options for applications, they’re also not a world away from where we have been.
Changes to applications providing
published data should (ideally) not be too massive. Though there may be some learning curve, we’re hoping improving our APIs should make this more pleasant overall.
Any published data will end up being either
ImmutableData as it’s been so far, or
AppendOnlyData replacing what was up until now
MutableData, i.e. entries in a published
AppendOnlyData cannot be mutated or deleted, and only new entries can be added.
App developers shouldn’t have to worry too much about the nitty gritty here though, as we’re hoping to simplify the general APIs to make publishing, versioning, and handling data much simpler (while still leaving raw APIs available should anyone want to go deeper).
The general gist is that all data that you want to be public as things are now, will need to be
AppendOnly Data or
ImmutableData to remain public, and therefore perpetual!
Unpublished data is only accessible to the owners of the data. It is not considered public.
MutableData is the same data type we currently have with a few minor additions:
1) The ability to opt out of sequencing the data (see below). 2) It cannot be published, i.e. other users cannot access it. 3) Mutable Data can now be deleted.
MutableData, for example, might be data that you may want to change frequently. This could be a new use case (in terms of SAFE), and there are many applications that may want to take advantage of this.
You can also create unpublished
AppendOnly Data, i.e. accessible only by the owner(s).
The idea of ‘sequenced’ data is that order is important to you or the application. This is the same setup as we have now with
MutableData, where to update a key, a
version must be passed to ensure that you’re updating the correct data. This is only applicable to the
MutableData data varieties.
Unsequenced data has no such requirement or check.
Immutable Data can be both published and unpublished. There won’t be any great changes here beyond specifying the publish variety of ImmutableData you want when you PUT the data. When ImmutableData is unpublished it can also be deleted from the network analogous to the new (thus unpublished) MutableData.
App configuration (SAFE Browser)
Your browser settings for example (bookmarks/history, etc.), could take advantage of this. For example, we could opt to use
Mutable Data for the browser settings (as we don’t need a version history or it to be public, and this can also be deleted).
Perpetual Websites (“Internet Archive”)
The public name system, using published data, could now be versioned from day one. As will any data pointed to (via Immutable Data). This means we’ll be able to readily browse the history of applications/websites on any published URL and point to specific versions of that data. (With versioned-data being created atop
Our applications will need to be updated to reflect this. But in terms of API changes, the end use should be very similar. The greater scope of changes will be in terms of making this versioned site history data easily available.
The Web Hosting Manager will most likely create
published data by default. It may need to be expanded (or alternatives made) to more properly manage unpublished data too.
A CLI should provide a clean, simple and familiar way of publishing data from your terminal.
While there are many new data types, offering different feature sets, we’re aiming to build a public facing API that makes things clear and simple.
Our initial efforts in this regard have been focussed on thinking about CLI commands and what’s useful there. (We’ll be sharing a full RFC for this in due course.) It’s expected that these new APIs should (ideally) cover the vast majority of developer use cases. And so once we have this specced out, our applications will be migrated to use these new APIs. (Including yes, making those APIs available in the DOM of SAFE Browser).
Language bindings will need to be updated to reflect at least the developer ‘friendly’ version of the APIs we’re envisioning. And we should probably still make the raw versions of these APIs available (such as we have now).
Accounts + Authentication
As we get towards safecoin, some of the APIs will be expanded to provide for management of your coins. Choosing which wallet address to pay for various transactions will be possible for example. So applications will need to be updated to facilitate this.
This is an ongoing process, and a lot to think over. So feedback on any/all of the above is both welcome and vital to ensuring we get towards data and APIs folk will want to use.