As I understand it SolveSpace assemblies rely on having one file reference another file by path. This assumes that the files have a fixed relationship to each other in the filesystem namespace.

But it looks like the sandboxing implemented by flatpaks means that each file ends up with its own (randomized?) path within a virtualized filesystem namespace. This means that even if the assembly file seems to work on one session (with awkward-looking relative paths), it doesn't work for other sessions or non-flatpak users.

If it can't find the files, solvespace will prompt for replacements, but this is both inconvenient and error-prone (as it looks like choosing the wrong file will result in a corrupted model).

I think this is a known issue https://github.com/flatpak/xdg-desktop-portal/issues/463. I wonder if its possible to do one or more of:
- use looser constraints on flatpak packages
- use some other distro-neutral packaging scheme
- package for Fedora (my preferred distro)
- use some other file structure which doesn't require encoding paths in files (which seems to be something @whitequark has suggested)

- and perhaps some additional way for solvespace to validate whether provided replacement files are the expected ones to prevent accidental corruption (eg uuid or file content hash?)

Perhaps related, its also not possible to open files on SMB shares, since it looks like the flatpak portal doesn't allow access to gvfs paths.