Sandboxed nextcloud desktop client for Linux and system integration

Since I had trouble with the natively packaged nextcloud client, I tried the three available sandboxed cross-distro packages, the AppImage, the snap and flatpak. With all of them, system integration (with Nautilus, Caja, Nemo or Dolphin) also does not work, you do not get the overlay icons or the nextcloud functions in the context menu.

I wonder whether this is just an inherent limitation of those sandbox formats which cannot be overcome. snap and flatpak both use separate file system hierarchies, so that e.g. /usr/share/caja-python/extensions/syncstate-Nextcloud.py which provides the integration with the MATE file manager Caja does not get installed to its proper location where caja looks for it. One could place a symlink manually, but such kludges should not be required. I haven’t checked where the sandboxed client places its socket to communicate with the file manager extensions.
It seems worst with the AppImage format, because there, everything is packed within one file, that gets unpacked and mounted at runtime, so that choosing autostart in the nextcloud client settings has no effect, because the file which is to be autostarted this way is not the AppImage, but the nextcloud binary within the AppImage, which gets unpacked only when the AppImage is launched.

I am sure that the developers of these distribution systems have also noticed these issues, I just wonder what the conclusion is. If it is that we are just going to have to live with it, then it is not an option for nextcloud, because without system integration, it is not really fun. Does anyone know what the situation and what the plans are in this regard?

See this issue - in short, this isn’t really possible:

Snaps and Appimages can’t add extensions for file managers.