There’s good support for moving this directory elsewhere, but moving it into the hidden location as proposed here still sounds like a suboptimal idea because that encourages software that otherwise would be entirely confined to be using interfaces like home just so they can put their data into a less awkward place.
We have some plans to support general access control for legacy software, which will solve that, and after that moving it would be fine.
That said, we can do something before that which would likely make people happy meanwhile: allowing users to configure their own ~/snap location wherever they want, as long as it is inside their $HOME, and probably some other minor constraints to ensure the place is basically sane. For example, we don’t want ~/.snap to be used because that’s already holding something else.
Here is a quick sketch of what we might do:
Add initial support for configuration schemas. We’ve had good conversations about that years ago, but we never got the time to get those in. We should probably do schemas before we do that, because we don’t non-root users being able to store arbitrary data into the snapd configuration database without some minimum validation.
Introduce per-user configuration. Today snapd forbids “snap set” as non-root. We’d allow that, and store the data on a user-specific namespace, which only the user itself and root can consult.
We add a setting that allow people to move their ~/snap location to a preferred spot.
It’s a bit of work, and the main blocker is probably the design of schemas, but we can probably do it in a cycle or two.