Comment 95 for bug 1575053

$HOME/snap is for user content. User content should be user-accessible. However, it looks like the feature is not very user-friendly. Should users need to change how they organize their files, to gain access to the features of snap?

For example, today the firefox snap created $HOME/snap/firefox, along with three files in there: two empty directories (118, common) and a symlink (current -> 118). My initial impressions are below.

First, the name of the top-level directory is named after an application, rather than being called something meaningful to a user. What has been snapped? Are we talking *oh, snap*? Fingers snapping? Twigs? Camera shutters? I don't mean to criticize the name of the project, but by putting that name as a directory in $HOME, these are the questions a user might have. Particularly if the user doesn't know what the snap application is or does.

Second, two extra hierarchical levels adds complexity that seems
unnecessary. Why do I need to navigate through this? What organizational purpose does it serve, to offset the time it takes to use?

Third, the files created under $HOME/snap/firefox are named nothing that makes sense to a user. What is 118 anyway?

Fourth, the organization behind the files under $HOME/snap/firefox doesn't make any initial sense. Why is current a symlink? Are these files versioned somehow? Is that specific to firefox, or generic to snap?

Finally, taken together these first points make the content of $HOME/snap seem quite opaque. That conflicts with their stated purpose of being for user content.

After reading [most of] the comments on this bug, I decided to test it out. I downloaded a file, and found it in $HOME/snap/firefox/common/Downloads. This is deep enough in the hierarchy as to be effectively hidden from both shell and GUI users. How would I have known it'd be there? Why not just use $XDG_DOWNLOAD_DIR?

A symlink could be a workaround, to get rid of the 4+ levels of folders that effectively hide these files from view. If a workaround is necessary, then there is a problem. If there is a problem, then it would be inappropriate to consider the issue as a feature request.

XDG lets users have a clean $HOME, and to define what "clean" means. Standards like XDG have community/industry support. They should be respected, either by following, or by stating a clear reason to not follow. How should this be done in XGD? Or what shortcoming of XDG is being addressed?

Implementing snap as a feature of ubuntu is a rather aggressive way to change the standard. It seems to lack clear direction, in breaking XDG. It therefore appears to disrespect the community, for whom the standard works. The feeling of disrespect can be seen motivating the various tones of people posting to this bug report.

XDG effectively combines the data for all applications into one structure. Does this make sense for something compartmentalized like snap? At my distance (new snap user, linux user since kernel 1.x), the new file structure doesn't seem inherently necessary, to have compartmentalization. It seems that each compartmentalized app should be able to use the XDG directories. Why not?

Is part of the compartmentalization approach to keep user data separate? If so, how will the eventual need for users to break that separation be handled securely? How do the $HOME/snap/<appname> directories fit into this?

Also, since epochs are mentioned in the rationale above, are they conceptually-relevant to $HOME/snap? Or is that just a technical dependency that we don't really need to understand, to know about $HOME/snap?