Classic confinement request for docksky

store-requests classic-confinement
1

  • name: docksky

  • description: DockSky is a Linux desktop app for persistent project memory and AI collaboration via MCP (Cursor, Claude, etc.). It helps solo workers keep context across sessions: projects, facets, journal, always-on-top banner, file activity tracking, and a local MCP server.

  • snapcraft: DockSky-release/snap/snapcraft.yaml at main · DockSky/DockSky-release · GitHub

  • upstream: PRIVATE

  • upstream-relation: I am the publisher and upstream maintainer. Application source is proprietary; snapcraft.yaml is published in the public DockSky-release repo for store review.

  • supported-category: tools for local, non-root user driven configuration of/switching to development workspaces/environments

  • reasoning: | DockSky needs classic confinement for v1 because strict confinement and existing interfaces are not sufficient for core features:

    1. Always-on-top banner — system-level window placement that must stay visible across workspaces and other applications.

    2. Global keyboard shortcuts — capture shortcuts while other apps have focus (productivity workflow).

    3. File activity tracking — FileSystemWatcher on user-configured project folders (e.g. ~/projets, ~/Projects), not limited to $SNAP_USER_DATA. Users point DockSky at arbitrary dev directories.

    4. Local MCP server — AI clients (Cursor, Claude Desktop, etc.) connect to localhost. The app reads/writes standard user paths outside the snap mount namespace (~/.config/DockSky, ~/.local/share/DockSky).

    5. Desktop integration — .NET/Avalonia desktop app expecting normal filesystem and window manager behaviour.

    I understand that strict confinement is generally preferred over classic.

    I have evaluated strict confinement and the available interfaces (home, personal-files, removable-media, network-bind, etc.). They do not cover arbitrary multi-directory file watching plus system-level overlay window behaviour plus local MCP integration without breaking the product. I plan to tighten to strict + explicit plugs once store behaviour is validated.

    Website: https://docksky.fr Contact: contact@docksky.fr Snap already uploaded for review: docksky 0.9.367 (amd64, core22)

Note that snappy-debug can be used to identify possible required interfaces. See snapcraft.io/docs/debug-snaps for more information.

2

This request has been added to the queue for review by the @reviewers team.

3

Hey @docksky

Looking at `docksky` webpage, I don’t think it clearly fit any of the supported categories for classic confinement. This is a hard requirement for a classic-confinement request to be considered.

I would appreciate other reviewers opinion

1 Like
4

Thanks @jslarraz for the review.

I agree the homepage alone reads broader than the snap’s target. DockSky is aimed at solo developers using AI-assisted coding (Cursor, VS Code, Claude Desktop) with an integrated MCP server: project memory, facets, journal, file activity on user-configured dev directories.

Supported category (my reading): tools for local, non-root user driven configuration of/switching to development workspaces/environments. DockSky switches and reloads per-project dev context for the AI client instead of re-explaining stack and architecture each session.

Clearer positioning: https://docksky.fr/pour-devs (MCP details see mcp page).

Technical classic rationale is unchanged: always-on-top banner, global shortcuts, FileSystemWatcher on arbitrary project paths, local MCP and config outside $SNAP_USER_DATA.

Happy to tighten the snap store listing and homepage copy so the dev-workspace category is obvious. Open to guidance if another supported category fits better from your side.

snapcraft.yaml: https://github.com/DockSky/DockSky-release/blob/main/snap/snapcraft.yaml

5

Hi @docksky,

I agree with @jslarraz’s verdict that the application does not fit any of the supported categories. The requested functionality can likely be achieved with strict confinement interfaces:

  • FileSystemWatcher on arbitrary project paths: As per Process for reviewing classic confinement snaps , access to arbitrary files on the system is on unsupported category for classic. Instead, you should use home interface to be able to access to directories like ~/Projects

  • local MCP and config outside $SNAP_USER_DATA: Since the file paths(~/.config/DockSky, ~/.local/share/DockSky) are owned by the snap, these can be auto-connected using personal-files interface after publisher vetting.

  • always-on-top banner: Have you tried using the x11 or wayland interfaces to see if they support this behavior?

6

Hi @shishirsub10, @jslarraz - Thank you for the detailed feedback.

We will switch DockSky to strict confinement and use the appropriate interfaces (home, personal-files, network / network-bind, x11, wayland, etc.) instead of requesting classic.

We are updating snapcraft.yaml accordingly and will test locally with snappy-debug before the next store upload. We will report back here if any core feature still cannot work under strict after those plugs are in place.

Thanks again for the guidance.

2 Likes
8

Hi @shishirsub10, @jslarraz,

I need your help to unblock the DockSky snap review.

Following your July feedback, we abandoned classic confinement and switched to strict with standard plugs. Thank you again for the clear guidance.

Current situation (revision history)

Rev Version Status
#1 0.9.367 Failed — original classic upload (June 26)
#2 0.9.380 Failed / manually rejected
#3 0.9.382 Rejected — “Automated review found 2 errors — rejected automatically after manual rejection from revision 2”
#4 0.9.383 Failed
#5 0.9.382 Pending (clock icon on dashboard) — this is the one to review

Revisions 1–4 can be ignored. They reflect our migration path (classic → failed strict attempts while the queue was blocked).

What changed in rev #5 (strict)

  • confinement: strict — classic removed entirely
  • No personal-files plug — config/data via $SNAP_USER_COMMON (XDG_CONFIG_HOME / XDG_DATA_HOME)
  • Plugs: home, network, network-bind, x11, wayland, desktop, opengl, desktop, desktop-legacy
  • Runtime libs bundled for core22 (.NET / Avalonia / SkiaSharp / ICU)
  • Tested locally with sudo snap install --dangerous before upload

snapcraft.yaml (for review) available on my git account, i cannot post the link here

Why I’m writing

On the dashboard I cannot unblock this myself:

  • Rev #1 only offers “Request manual review” — we do not want rev 1 (classic) reviewed
  • Rev #5 shows as pending but I don’t see “Reject and remove from review queue” or a working “Request manual review” action
  • New uploads were blocked with “Waiting for previous upload(s) to complete their review process”

Could you please:

  1. Review revision #5 (0.9.382, strict), or
  2. Clear/reject revisions 1–4 from the queue if they still block processing, then confirm rev #5 can proceed

Happy to run snappy-debug, provide logs, or adjust plugs if anything still fails automated review.

Thanks, Robert — DockSky

9

Hey!

@store this seems to be blocked by the snap_metadata_redflag check. Could you please take a look?

1 Like
11

Hi , @jslarraz, and @store,

Thank you both for the thoughtful review and for guiding us toward strict confinement , that was exactly the right direction, and we’ve fully moved away from the original classic request.

Following your July feedback, DockSky is now packaged with confinement: strict and standard plugs (home, network, network-bind, x11, wayland, desktop, desktop-legacy, opengl). Config and data live under $SNAP_USER_COMMON via XDG_CONFIG_HOME -XDG_DATA_HOME, no personal-files plug. We tested locally with sudo snap install --dangerous before uploading.

Revision to review: please focus on rev #5 (0.9.382, strict). Revisions 1–4 were part of our migration path (classic → strict) and can be ignored or cleared from the queue.

@jslarraz : thanks for flagging the snap_metadata_redflag blocker and looping in@store@store. We’re happy to adjust store metadata or provide snappy-debug logs if anything else is needed.

@store@store : could you please take a look and help unblock the pending strict revision? We’re keen to get DockSky published properly under strict confinement.

Thanks again for your patience and support.

Robert DockSky