Hello world!
I did manage to get Joplin going in Snap, and like everyone else, I struggled to get it going with the Electron-Builder tools and whatever else Snapcraft has actually dedicated to the problem. Fortunately I’ve done a few other Snaps so understand the rough outline of the Snap system, which makes the problem a lot easier by avoiding the Electron specific tools and just treating it as a native-like install, and piggyback on the existing NPM build system.
If upstream is happy to adopt Snap, I’m happy to remove the Snap currently versioned to my username. I think Snap makes a lot of sense for Joplin, and although it might receive less attention from the developer orientated community than Flatpak, I wouldn’t say this implies it has less support from “normal users” at all, as you can see from this graph from my builds current metrics page. https://i.imgur.com/vqo5Tbi.png That’s a nice amount of users in 10 days from an unotherwise unadvertised build.
Important considerations for Snap therefore include:
To actually claim the “joplin” package name, you’ll have to go through an authentication process on the Snapcraft forums, as Joplin is considered a reserved package that only the official developers should be able to register. Unfortunately, it’s not possible to automatically make joplin-james-carroll users joplin users.
The WebClipper extension probably won’t work, I’m not sure how trivial the fix is for this, but the KeePassXC browser extension does have a workaround that might work for Joplin (with modifications) in a Snap build too, though I haven’t looked into it. https://raw.githubusercontent.com/keepassxreboot/keepassxc/master/utils/keepassxc-snap-helper.sh
The Chrome sandbox is disabled in my build. This is expected for Electron apps on Snap because use of the Chrome sandbox is considered privileged. It could be possible to reenable it in an official build via asking for permission on the Snapcraft forum, given the Joplin is a well known entity unlike myself and considered trustable. (The Snap sandboxing still runs as is mandatory!), this would be at the discretion of the Snapcraft admins.
The automatic update (and manual update checking) functionally is intentionally broken with a simple sed script in the build process. This is because there’s no way to update a Snap without pushing a new Snap revision, so it’s useless functionality in the Snap environment. Preferably, the UI would be updated better to reflect this.
If upstream decides this is worthy of adoption, it can make use of the Snapcraft build service hosted by Canonical to integrate with a GitHub webhook that would build and publish a Snap for every single commit, released to the Edge channel that can be pushed to the stable channel at will.
Finally, Electron hasn’t yet integrated patches that enable XDG-Desktop-Portal functionality available, as used in Flatpak, to enable arbitrary access of the computers filesystems in a secure manner. Effectively this means that by default, the snap is confined to $HOME, and cannot access USB sticks (without enabling the removable-media sandbox interface), and potentially arbitrary FUSE filesystems. When Electron integrates the patches upstream, this limitation should disappear on supporting systems.
Otherwise, I’ll keep on pushing updates myself to my unofficial build for the foreseeable future, although I’ll look into automating it at some point.