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.
Publishing data
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
Unpublished data is only accessible to the owners of the data. It is not considered public.
Mutable Data
The 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.
AppendOnly Data
You can also create unpublished AppendOnly Data
, i.e. accessible only by the owner(s).
Sequencing
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 AppendOnlyData
and MutableData
data varieties.
Unsequenced data has no such requirement or check.
Immutable Data
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.
Use Cases
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 AppendOnlyData
)
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.
File Management
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.
APIs
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.
CLI
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
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.
Feedback
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.