I’m scratching my head about the different ways Apps can be implemented and used with SAFE Network. Here are some thoughts, and the questions arising for me…
Types Of SAFE App
unchanged App: an existing software that saves and loads data to a local drive, but where the user loads and saves directly from/to SAFE Network by choosing a Virtual SAFE Drive (VSD) virtual drive, using some MaidSafe software that presents SAFE network account and storage as a virtual drive on the local device/PC. This is not that secure because while the data you save is secured, the App itself is probably still writing bits and pieces to the local machine (configuration, temp files etc.).
portable App: apps modified to only use your VSD so nothing is left on the device/PC unless you explicitly request that, such as saving a file to the local drive. There are already many apps written to work like this from USB drives, so finding suitable apps will be pretty easy, and modifying many existing ones is not that hard either.
SAFE Apps: apps can be written from scratch (or modified) to assume a SAFE Network and do all their operations via the SAFE API. These will have been specially built using the SAFE libraries.
SAFE Dapps: distributed apps - hard-coded in the core and exposed as APIs: a) redundant private, public and shared data, b) Safecoin, for exchanging resources, c) messaging
SAFE Dcomp: distributed computation - NOT YET PLANNED - computation nodes can run (in sandboxed environments) fully decentralised, scalable autonomous applications
Here is my understanding of the plan at launch, this may be incorrect so I’m hoping for corrections from the team in that case:
Drive: The Virtual SAFE Drive (maidsafe-Drive) will be available at launch, so all of the above will be feasible (though not until the latter part of testnet3 or perhaps afterwards).
SAFE App Launcher: is I think currently only for SAFE Apps, though it would to me make sense if it could handle all of the above. The restriction is to keep user authentication within the launcher so that it doesn’t need to be handled by a SAFE App, but I think the Launcher could know which are SAFE Apps, and for those that are not do the authentication, ensure the VSD is mounted, and then start the App? There’s a trade-off here between keeping the Launcher to just secure SAFE Apps, but I think also a case for including portable Apps that are loaded from SAFE storage.
Apps Stored On Network: the current SAFE App Launcher assumes all the above kinds of App are installed locally, whereas it would be better, particularly for security, if the user could install Apps to their SAFE Drive, and also to use pre-published “ready to run” portable Apps and SAFE Apps, from public shares to ensure the same version of the App runs each time, free from corruption or infection by malware.
This last point would mean that if you trusted someone to publish a portable App or a SAFE App, you could use it as is directly from their share. No install needed, and no need to store locally or pay to PUT on SAFE. If the Launcher could support this it would be very useful.
One caveat is that it would be important to know that Apps from storage provided by trusted third parties (e.g. MaidSafe) were immutable, otherwise they would pose a massive centralisation risk because lots of users would be using the same copy of each publicly shared App. If someone obtained access and the App wasn’t immutable, all users of the App could be compromised.
Couldn’t this be solved by the SAFE system assigning a local storage key* so that any local disk storage (designated to be secured - temp files etc) is encrypted before storing on the local disk. Since the key is stored with your other keys then no need for the user to be entering credentials for each app and each time they run the apps.
EDIT: - NOTE: by local storage key I mean a key for local storage, not that the key is stored on local storage.
Thanks @BenMS I will update the OP with this later
SAFE apps, run on your local machine, hosted on a public (immutable) versioned share
This can apply to what I’ve called “portable Apps” as well as “SAFE Apps” and is something I’m very pleased to see is on the cards! Is there an easy way to tell that data (or the share) is immutable?
the data chunks themselves are always stored as immutable data, but these chunks will in most cases be gotten from a version-object (structured data), so any mutations will be reversible.
The reason for my question is that as a client/user, I want to know that a given “file” (or share) is immutable, so that I can just load it every day and know it has not been changed, and if it is changed, for me to know that and choose whether or not to use the new version.
I would think it ought to be possible to retrieve a “version” of a share, and to only update that choice to a new version (e.g. the current “head” version) explicitly. Is that the case?
You saying “mutations will be reversible” is not the behaviour I’m describing I think - it implies I have to revert to an earlier version after a change, whereas I want to ensure I stay at the current version even if the share is updated.
Yes, the NFS API allows you to get the latest version or query what versions there are and retrieve the specific versions desired. So for example from a code use-case you could lock the version of a code project you want to retrieve from the network. That is what I meant with ‘reversible’, i.e. you can go back to a previous versions; my bad for the wrong use of words.
And to answer your question then: every file is always and only stored in an immutable form. The directory structure it is saved in is versioned and will point to a all versions of the file.
Is there an easy way to tell that data (or the share) is immutable?