Request for auto-connect: avahi-observe, avahi-control (and removable-media) for aviator-archive

store-requests privileged-interfaces
1

Hi store team,

Requesting auto-connect on the `aviator-archive` snap (publisher:

aviatorarchive, registered 2026-08-06). Revision 1 is published and installable

now on `latest/edge` — `snap install aviator-archive --edge` if it is useful to

look at the real thing.

```yaml

name: aviator-archive

description: offline-first pilot logbook that syncs device-to-device over the local network

snapcraft: PRIVATE (closed-source — happy to send the snapcraft.yaml or a build for review)

upstream: PRIVATE

upstream-relation: author (we are upstream; the publisher is the developer)

plugs:

avahi-observe:

request-type: auto-connection

reasoning: browse for the peer's \_http.\_tcp service over mDNS. Device-to-device

  sync over the local network is the app's primary feature and discovery is the

  first step of it. Unconnected, discovery returns nothing and fails silently.

avahi-control:

request-type: auto-connection

reasoning: advertise our own \_http.\_tcp service so the other device can find us.

  Both directions are needed because pairing starts from whichever device the

  user picks.

removable-media:

request-type: auto-connection

reasoning: pilots move logbooks between machines on USB sticks — importing from

  another logbook app, exporting a regulator-ready PDF. Secondary to the avahi

  pair; \`home\` already covers the common case. See the note below.

slots: none (the snap declares no slots)

```

**What the snap is**

Aviator Archive is a pilot logbook. It is offline-first and has no server-side

copy of a user’s data: a pilot’s flights live on their own devices, and the two

devices reconcile directly over the local network. It is proprietary/commercial

software (`license: Proprietary`), distributed free-to-install with licensing

handled by our own backend.

**Why avahi**

Discovery is mDNS, via the `bonsoir` Flutter package, which on Linux talks to

the Avahi D-Bus interface. With both plugs connected, a PIN-paired sync between

this snap and an Android peer completes in both directions under

`confinement: strict`, including a full profile transfer. We verified that

first on a local build (2026-08-06) and again on 2026-08-12 against revision 1

installed from the store, on a clean install with a fresh profile — so this is

the shipping artifact’s behaviour, not a development build’s.

With them unconnected, discovery **fails silently**: there is no error the app

can surface that distinguishes “no peer on this network” from "this plug is not

connected", so the user experience is simply that the feature does not work.

That is the specific harm we are asking to avoid. `snap connect` as a

documented workaround is not realistic for our audience — working pilots, not

Linux administrators.

We are NOT requesting `classic` confinement. Strict works, and this request is

the only thing standing between a strict build and a usable one.

**On `removable-media`**

This one is a convenience rather than a blocker, since `home` covers the common

case. If it is not something you grant for this class of app, we are happy to

drop it and keep the avahi pair.

**Not requested: `password-manager-service`**

It is declared in our snapcraft.yaml and we want to flag that we are

deliberately *not* asking for auto-connect on it. We originally assumed our

credential storage needed it. Testing showed otherwise: under confinement

libsecret uses its file backend and obtains the keyring secret through

`org.freedesktop.portal.Secret` via the `desktop` plug, so

`org.freedesktop.secrets` is never used. We confirmed this by disconnecting the

plug and verifying the app still opened an existing encrypted database with an

unchanged file header, and again on the store install above, where the plug was

never connected at all and a brand-new encrypted profile was created and synced

without it. We have left it declared as a safety net in case libsecret’s backend

selection changes, but it should stay manually connected.

Thanks,

Daniel — Aviator Archive

2

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

3

Hey @aviatorarchive

I believe that both, avahi-observer and avahi-control, make sense for the use case described. Given that aviator-archive is closed source and you mentioned that it is proprietary/commercial I think that it still makes sense for you to apply for a Verified Accounts. It helps users to identify that it is distributed by an authoritative source and would back the decision of granting the requested auto-connection. Would this work for you?

On the contrary, I don’t think that auto-connection to removable-media is appropriate in this case. It does not really fit the range of applications that usually get it auto-connected. If you consider it appropriate, sometimes a good practice is to use snapctl is-connected to identify if the interface is connected and prompt the user (if needed) during application initialization. It might be something like a hint the first time the user opens the application.

Thanks!

4

Thanks Jorge — that is helpful on both counts.

**removable-media: dropping it.** No argument — `home` already covers the

ordinary import/export path, so this costs a convenience rather than a

feature. Please treat the request as `avahi-observe` + `avahi-control`

only, and thanks for the snapctl is-connected pointer — we will use it for

the hint.

**Verified Account: yes, that works for us**, and I would rather flag the

awkward part now than have it surface mid-review. The policy asks how our

company has worked, collaborated or partnered with Canonical — and we have

not. Aviator Archive is a small independent commercial project and this is

our first snap. The policy anticipates that ("if your institution,

foundation or company hasn’t so far, let’s start a conversation"), so I am

starting it here rather than filing into policy-requests and hoping.

Two questions, then I will file:

1. Given that criterion, is Verified Account realistically open to us? What

we can evidence is that the publisher is genuinely the author of the

software and that the company behind it is real and reachable. If that

is the substance you need, we can supply it. If a prior Canonical

relationship is a hard requirement, I would rather know before taking up

two policy-reviewers’ time.

2. Does the avahi decision wait on verification completing, or can it

proceed with verification tracked separately? No urgency either way —

the snap stays on `edge` until this settles. I only want to set the

right expectation with our beta testers.

Thanks,

Daniel — Aviator Archive

5

Hey @aviatorarchive

  1. Given that criterion, is Verified Account realistically open to us?

I believe so. My understanding is that a prior Canonical relationship is not a hard requirement at all.

  1. Does the avahi decision wait on verification completing, or can it proceed with verification tracked separately?

Considering that avahi interfaces are not a extremely common request and the closed source nature of the snap I would feel more comfortable waiting for the verified account process to complete

Thanks

6

Not a problem at all Jorge. I’ll get the process started for the Verified Account and will report back here when that is complete.

1 Like