Request for interface for sarala app

store-requests privileged-interfaces
1

To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.

  • name: sarala
  • description: | Sarala is a fast, distraction-free WYSIWYG Markdown editor (Tauri 2 + SolidJS, base core22). It styles Markdown live as you type while keeping the underlying source intact, and renders code, math (KaTeX), Mermaid and D2 diagrams. Files are read and written as plain Markdown, so documents are never locked into a proprietary format.
  • snapcraft: sarala/snap/snapcraft.yaml at main · solancer/sarala · GitHub
  • upstream: GitHub - solancer/sarala: A seamless WYSIWYG Markdown editor — no preview pane, no split view. · GitHub
  • upstream-relation: I am the upstream author and sole maintainer (publisher == upstream).
  • interfaces:
  • removable-media:
  • request-type: auto-connection
  • reasoning: | Sarala is a general-purpose Markdown editor whose core function is to open and save the user’s own documents wherever they keep them. Users routinely store and edit notes/Markdown directly on USB sticks and external drives (mounted under /media and /mnt), which the home interface does not cover. Without auto-connection, opening or saving a file on an external drive silently fails until the user discovers and runs snap connect sarala:removable-media, which is poor UX for a desktop editor where “open this file” is the primary action. The snap only performs user-initiated file reads/writes via the native open/save dialog (no background or bulk access), so auto-connecting removable-media matches the least-privilege expectations for an editor.
2

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

3

Hey @solancer

As stated in the Process for aliases, auto-connections and tracks - Snap documentation , removable-media is usually restricted as user frequently store sensitive information in these external devices. Part of the criteria is “the application itself is a mature, well-known application”. I don’t think that sarala meets it as of now. Thus, -1 from me for the auto-connection request.

All in all, for new graphical applications I believe using the File Chooser portal is the right choice over removable-media anyway.

4

Hi @jslarraz, thanks for the clear explanation and the pointer to the process docs, that’s fair, and I agree the File Chooser portal is the right approach for a new graphical app rather than leaning on removable-media.

I’ve moved Sarala’s file dialogs over to the XDG File Chooser portal (switching the underlying Rust file-dialog library to its xdg-portal backend instead of GTK). With the portal handling open/save, user-picked files, including anything on removable media are granted through the document portal, so the removable-media interface isn’t needed for that flow.

So I’d like to withdraw the auto-connection request for removable-media. I’ll keep the plug declared for now as a manual fallback, but it no longer needs to auto-connect. home (auto-connected by default) plus the portal covers the normal editing workflow.

I’ll get this into the next release now. Thanks again for the review!

1 Like