We have experimental code to support this, but it is not yet enabled by default. It can be enabled with:
sudo snap set system experimental.user-daemons=true
… and disabled with:
sudo snap unset system experimental.user-daemons
With the feature flag turned on, it is possible to install snaps that provide user services. On the snap side, this is achieved by adding daemon-scope: user to the app definition for the daemon. At present, Snapcraft does not understand this key (at least until PR #3129 is merged, which will probably happen after the feature is turned on by default), so it would need to be listed through a passthrough: section:
apps:
svc:
command: ...
daemon: simple
passthrough:
daemon-scope: user
In most respects, you can use the same types of configuration as you would for system daemons. If you want to use socket activation, the socket locations must start with one of $SNAP_USER_DATA/, $SNAP_USER_COMMON/, or $XDG_RUNTIME_DIR/ (the last of which will be in the snap’s private version of the directory).
If you try to publish a snap using this feature, it will currently fail automated review and require manual approval. As mentioned above, it will only be installable by users who turn on the feature flag. I can’t give you a timeline on when the feature will be turned on by default, but it is important to us as it is a prerequisite for enabling D-Bus service activation support for the session bus (something that is obviously interesting to the desktop team).