FR-PLAT-LIN-3 — Flatpak. Packaged, not satisfied — and it cannot be satisfied by packaging.
What exists
A Flatpak manifest granting no filesystem permission of any kind, AppStream metainfo, and docs/distribution.md.
Why that does not meet the requirement
Inside the sandbox:
A folder library is chosen by typing an absolute path, and nothing in the tree calls the FileChooser portal.
$HOME holds only .var/app/....
dr_plat::volumes() reads /proc/self/mountinfo, so a card mounted on the host is invisible to a sandboxed process.
So a Flatpak build of DarkRoom today can reach a Nextcloud account and essentially nothing else on disk.
The fix
An ashpd directory picker beside LocalStorage::grant — not a change to the manifest. The portal returns a handle the sandbox honours, which is the Linux analogue of the SAF work in #25 and worth designing alongside it.
Also
No Flatpak has been built here — flatpak-builder is not installed — so the permission set is reasoned, not observed.
Portal directory picker wired into the launch flow.
volumes() reports what the sandbox can actually reach.
Build the Flatpak and confirm the permission set empirically.
See docs/outstanding.md §5.
**FR-PLAT-LIN-3 — Flatpak.** Packaged, not satisfied — and **it cannot be satisfied by packaging**.
## What exists
A Flatpak manifest granting no filesystem permission of any kind, AppStream metainfo, and `docs/distribution.md`.
## Why that does not meet the requirement
Inside the sandbox:
- A folder library is chosen by **typing an absolute path**, and nothing in the tree calls the FileChooser portal.
- `$HOME` holds only `.var/app/...`.
- `dr_plat::volumes()` reads `/proc/self/mountinfo`, so a card mounted on the host is invisible to a sandboxed process.
So a Flatpak build of DarkRoom today can reach a Nextcloud account and essentially nothing else on disk.
## The fix
An **`ashpd` directory picker beside `LocalStorage::grant`** — not a change to the manifest. The portal returns a handle the sandbox honours, which is the Linux analogue of the SAF work in #25 and worth designing alongside it.
## Also
**No Flatpak has been built here** — `flatpak-builder` is not installed — so the permission set is reasoned, not observed.
- [ ] Portal directory picker wired into the launch flow.
- [ ] `volumes()` reports what the sandbox can actually reach.
- [ ] Build the Flatpak and confirm the permission set empirically.
See `docs/outstanding.md` §5.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
FR-PLAT-LIN-3 — Flatpak. Packaged, not satisfied — and it cannot be satisfied by packaging.
What exists
A Flatpak manifest granting no filesystem permission of any kind, AppStream metainfo, and
docs/distribution.md.Why that does not meet the requirement
Inside the sandbox:
$HOMEholds only.var/app/....dr_plat::volumes()reads/proc/self/mountinfo, so a card mounted on the host is invisible to a sandboxed process.So a Flatpak build of DarkRoom today can reach a Nextcloud account and essentially nothing else on disk.
The fix
An
ashpddirectory picker besideLocalStorage::grant— not a change to the manifest. The portal returns a handle the sandbox honours, which is the Linux analogue of the SAF work in #25 and worth designing alongside it.Also
No Flatpak has been built here —
flatpak-builderis not installed — so the permission set is reasoned, not observed.volumes()reports what the sandbox can actually reach.See
docs/outstanding.md§5.Design alongside #25 — SAF and the XDG portal are the same shape of grant, and both land beside
LocalStorage::grant.