The following is a complete copy of the above issue, to facilitate discussion outside github. Significant points should be made there, but I’m posting here to highlight the issue and to make it easy to answer simple questions about it.
User testing of SAFE Drive is highlighting areas of difficulty with the UX for SAFE containers. These are particularly hard to solve within SAFE Drive because of the limited feedback possible when the user tries something that is not supported, but I think improving the experience for SAFE Drive will also make it easier, and a better UX in other apps. For example, all apps that show the user a file save dialog will face these issues.
I realise some of this might change if the underlying implementation changes, due to adoption of RDF for example, but considering these issues will help us avoid similar problems in any successor implementation of SAFE containers
Issue 1) I have been simulating creation of directories as temporary structures which become permanent when the user saves the first file to them (because once a file is saved, the directories exist in the key of the entry recording the existance of the file). This works fine until the user tries to create a directory in one of the default containers (eg in _public) rather than within an NFS container under _public (ie under _public/myname/www-root).
So a user cannot save a file in _public, or in a directory they have created in _public until an NFS container exists there, even though it is natural to expect that this is OK. In SAFE Drive, I can only reject this with ‘Operation not supported’ because only a fixed set of FUSE / POSIX error messages are available. This will likely be problematic UX for any SAFE file browser app, or any app with a file save dialog etc, even if it is able to provide a more helpful error message.
Proposal 1): The first issue could be much alleviated by making every subdirectory of _public map to an NFS container. I like this, even though it means they can’t be grouped by public name as now. So that’s one change to consider.
The above change also solves a second issue, which is another reason I like it!
Issue 2) is that a user expects to be able to create directories in a default container, and directories within directories etc. But in order to save files in those directories, at some point we need to create an NFS container and this isn’t something the user expects to need to do explicitly, and it isn’t obvious where in the path this should be, and if not done sensibly,y it could cause problems later.
For example, within SAFE Drive you can:
$ cd ~/SAFE/_public ~/SAFE/_public$ mkdir dir1 ~/SAFE/_public$ mkdir dir1/dir2 ~/SAFE/_public$ mkdir dir1/dir2/dir3
Nothing exists there on SAFE Network yet, but the user sees a directory has been created and the file system behaves as expected, so they can now:
~/SAFE/_public$ cd dir1 ~/SAFE/_public/dir1$ cd dir2/dir3 ~/SAFE/_public/dir1/dir2/dir3$
We can create an NFS container at any point, but if so where? Do we follow the convention of the first level not being able to hold files (as currently)? Do we allow further subdirectories that can’t hold files?
Any application that provides a UI to the SAFE file system will need to solve this, in a file save dialogue for example.
Proposal 1 (requiring every subdirectory of _public and the other default file containers, to map directly onto an NFS container) greatly simplifies this, and makes the results predictable.
Issue 3) Not being able to save files in the root of a default container is problematic for UX, because users will expect this to work, and rejecting this will be poor UX. Particularly for SAFE Drive which can’t explain why it failed, and where a file system really just needs to work or users will easily get into difficulties. For example, losing files they thought had been copied to SAFE storage, but failed with an error they didn’t notice or didn’t understand.
Proposal 2) I suggest we support saving files in the root of a default container, perhaps with a hidden NFS container, just for that purpose. I think proposal 1) and 2) could work well together.
Combining proposals 1) and 2) means that:
- every default container will have a hidden NFS container that holds any files that appear in the root of the default container (eg. in _public)
- every directory within the root of a default container will map to an NFS container
This doesn’t mean you can’t group files within _public by public name, but if you did, it would mean changing the way that web services map to containers, and would put all files for all services within a single NFS container which I don’t think is practical with the current 1000 file/entry limit.