> On 21 Jul 2019, at 03:28, yak mandango <email address hidden> wrote:
> 
> @zyga: In your last comment in April, you mentioned a refactor would let
> $HOME/snap be moved to $HOME/.snap instead. You also mentioned creating
> "views" of the new .snap directory.
> 
> You didn't mention the possibility of using XDG paths, or making the
> path configurable per system or per user. Would either of those be
> possible after the refactor?

Using XDG paths is hard because they don’t map to the concept of the snap directory. Let me explain where I am going with the idea of the snap folder.

The folder itself will remain a special folder with a constant name. The name will just be prefixed with dot to hide it. The name must be constant for a large number of reasons: it is present in global (not per user) confinement profiles, it is accessed by snapd on behalf of a logged out user, it is persistently mapped into other mount namespaces. All of those make it infeasible to both have per-user variability and even changes while the user is logged in.

The contents of the future $HOME/.snap folder (note the leading dot) would largely remain as the public $HOME/snap folder today. It is a tree of per-revision mini-home filesystems. Those already include provisions for .cache .config and .local. Since snapd is not mandating a particular design on packaged applications we cannot constrain applications to just those locations. We cannot also shared them with typical XDG locations (that is real $HOME/.cache, for example) since that would introduce an attack vector on the host. For this reason is best if the per-snap mini-home filesystems retain their current form.

The view concept works as follows: the user can optionally mount a special file system, that is purely designed for interaction with classic side of the world (that is, it is not actively used by snap application processes but could be used by file managers and users themselves). The filesystem would expose a curated view of the per-snap data in a way which allows the snap package maintainer to design.

As a simple example: let’s say we have a photo management application called photo-manager. The application stores data in $HOME/.local/shared/photo-manager/data. When packaged as a snap that would be translated to $HOME/snap/photo-manager/common/.local/shared/photo-manager. That is already very obscure and non user friendly. The snap packager could use new syntax in the snap.yaml file, to describe how to map that path to user-friendly data. For example we could say that  the only folder visible should be “Photos” and it should correspond to the long path mentioned above. When using the file manager the user could navigate to, say, $HOME/Snaps/ (or whatever name that a particular user chose to use, including localised one). Inside that directory the user would see a special filesystem that interacts with snaps to expose only the view described by snap.yaml. In our case it would be $HOME/Snaps/photo-manager/Photos. This would allow to, over time, build nice experiences for user interaction, all while maintaining compatibility with snap applications available today.

To get there we need some more pieces of infrastructure:

- We need to finish the work on per-user mount namespaces and corresponding bugs in mount event propagation
- We need to allow snapd to migrate the snap directory to .snap (and perhaps back)
- We need to write the new filesystem that uses can mount anywhere that shows their view of snap data (initially just all the data)
- We need to design and implement the language that performs the mapping
- We need to implement user configuration that chooses if and how the new filesystem is mounted

We are currently on the first step. If anyone wants to help me out I can certainly use some extra pair of hands. I’m offering mentorship and patch review.

Best regards
ZK