Auto-connect request for russet

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: russet
  • description: Russet is a private, on-device AI assistant for Linux that runs local GGUF models with hardware acceleration. The three interfaces requested below are used read-only (hardware-observe / system-observe) or for user-initiated file access only (removable-media); none modify system state.
  • snapcraft: Private
  • upstream: ‘PRIVATE’
  • upstream-relation: I’m the author and sole developer/publisher
  • interfaces:
    • hardware-observe:
      • request-type: auto-connection
      • reasoning: Used (read-only) to record the accurate device model in each chat’s provenance and in diagnostics. Russet reads /sys/devices/virtual/dmi/id/{product_name,product_version,product_family,sys_vendor} (or /proc/device-tree/model on ARM) to show e.g. “ThinkPad X1 Carbon” in the chat info sheet and in exported/transferred chats. Without this connection it falls back to the raw CPU name from /proc/cpuinfo, so first-run users see an incorrect device model and may assume the app is broken.
    • system-observe:
      • request-type: auto-connection
      • reasoning: Used (read-only) to report the host operating system. Inside the snap, /etc/os-release describes the base runtime (“Ubuntu Core 26”), which would misattribute the host distribution; this interface exposes the host’s /var/lib/snapd/hostfs/etc/os-release so the chat info sheet can show the real distribution (e.g. “Ubuntu 26.04 LTS”). Without it the OS is shown as generic “Linux“.
    • removable-media:
      • request-type: auto-connection
      • reasoning: Russet stores and loads multi-GB GGUF model files, which users may keep on external/removable drives to save internal storage. This interface lets the model browser save to / load from drives mounted under /media and /mnt. Access is limited to those mount points and is always user-initiated through a “Save to:” destination chooser.

The snap is already published at Install Russet: Private on-device AI on Linux | Snap Store

2

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

3

Hey @ndl_linux

Sorry for the delay in my response. Could you please point me to any public documentation about russet?

Thanks

4

Hey @jslarraz,

Some public info on Russet:

Apologies if the above are irrelevant. Happy to share snapcraft.yaml with those who request if that’s a possibility too.

Thanks!

5

Thanks for sharing this information. Given the reasoning, I’m ok with granting auto-connection to hardware-observe and system-observe. +1 from me for these two

On the other hand, I don’t think we can grant auto-connection to `removable-media`, as per the criteria defined in the Process for aliases, auto-connections and tracks - Snap documentation . -1 from me for the auto-connection of removable-media as of now.

6

I agree with @jslarraz here, it doesn’t comply with the criteria for removeable-media autoconnection, I would rather give +1 for manual connection to removable-media and +1 for auto-connection of hardware-observe and system-observe interfaces.

7

Thanks @jslarraz @0xnishit! Here’s my updated request per your sound reasoning: auto-connection for hardware-observe and system-observe. I’ll handle the removable-media connection in-app: the app defaults to internal storage and will guide users to run snap connect russet:removable-media if they choose an external destination.

Appreciate the feedback!

8

+2 for, 0 against granting russet auto-connection to system-observe and hardware-observe interfaces. This is now live!