URL/contact fields in snap metadata

As far as I know, the snap store currently has two URL/contact fields for snaps:

In comparison, Apple’s App Store has:

  • Support URL (displayed as “{App title} Support”) — required
  • Marketing URL (displayed as “Developer Web Site”) — optional
  • License Agreement (not to be confused with code license) — optional
  • Privacy Policy URL — required for “Made For Kids” or data-collecting apps, optional for other apps.

And Google Play has:

  • Website — optional
  • Email — required
  • Phone number — optional
  • Privacy Policy — required for “Designed For Families” or data-collecting apps, optional for other apps.

Snaps are broader than just apps, but still, this suggests a couple of issues with the current snap metadata fields.

  1. Apple has no fields for e-mail addresses, while Google requires an e-mail address. So I understand why we’d allow contact to be either a Web or e-mail address. Unfortunately, this could surprise end users: for different snaps, the same link would sometimes open a Web page, and sometimes open their e-mail app. We could rely on clients to visually distinguish them based on protocol :earth_africa:/:email:, but perhaps having separate fields to begin with would be more reliable.

  2. In Apple’s App Store, a support URL is required; in the snap store, it’s deprecated. I don’t understand either of these choices.

  3. Both Apple and Google require a privacy policy URL for some apps, to comply with (at least) Californian law. I’m not a lawyer, but I understand that the EU’s GDPR will require this as well. Perhaps we should have a specific field for it.

1 Like

FWIW the deprecation of support_url is AFAIK because it was renamed to contact.

though support for contact never made its way into snapcraft, cc @mvo

Also, our store allows (and even suggests) to enter email addresses

But when you look at the app in the store, it says “Developer Website” - which is a mailto link, which is a bit janky.

Can we at least get the wording the same between the store and the … store.

Planning that might be easier in a separate thread.

Yes, I linked above to @cprov’s bug report about that. At the time I specced “Developer Web site”, it didn’t even occur to me that e-mail addresses might be allowed.

Ok, in the absence of rationale for the current field(s), here’s a straw-person proposal:

  • Web site: http:/https: — required (we leave it up to each snap’s site to link to relevant forms of tech support)
  • E-mail: a valid e-mail address — optional
  • Privacy policy: http:/https: — optional for now (maybe required for some snaps later)

(Migration: contact would be migrated to Web site or E-mail depending on the protocol of the current value. After that, you wouldn’t be able to promote a snap beyond edge without populating the Web site field. For snaps already beyond edge, we’d e-mail their publishers to let them know they had ~1 month to populate the field.)

1 Like

Thanks to Daniel Manrique for pointing me to @mvo’s bug report where support_url became contact: “The rational[e] is that ‘support-url’ sounds a lot like people can expect support. With ‘contact’ it feels less formal.”

I think my proposal above also avoids the expectation that “people can expect support”, while also avoiding the surprise of the same link sometimes opening a Web page and sometimes launching your mail client.

Thanks for the discussion @mpt. I’m happy with website/e-mail and would like to get this moving forward. I created a trivial PR to snapcraft https://github.com/snapcore/snapcraft/pull/2164 for the website.

Fwiw, I don’t mind either contact or website/email/privacy policy but I would like to see this moving forward because right now its pretty hard to find out more about a given snap and/or contact a developer.

1 Like

The store API currently has contact and website fields. website must be an http or https URL, while contact can be either a URL or a mailto address. If we want to repurpose contact to mean contact e-mail I would insist on tightening the validation. Also the relabel of contact to email (the field is called something in one place and something else in another place) might lead to confusion. Or, contact could be allowed to have a URL (e.g. a contact form), in which case it can keep the existing validation and naming (but to reiterate, don’t label it email if we’re going to allow a URL in that field).

to some extent, website is not full exposed to snapd.

I suspect the review tools will need to support this as well. Can we start using cross-project bugs to coordinate, please?

So far I gather:

  1. expose website fully to snapd (@pedronis can you please clarify why it’s not fully exposed right now?)
  2. Verify review tools support for website and contact fields.
  3. Verify snapcraft supports contact and website (for metadata updating - this is optional, these can be updated via snapcraft.io/account developer UI).
  4. Decide if we need dashboard.snapcraft.io support for updating website. Given the previous point and emphasis on the account UI, I’d say no.
  5. At this point snapd could start handling website, and it should already handle contact.

To get to the “website and email” world I would prefer adding an explicit email field and eventually deprecating contact’s current hybrid semantics. Or, if desired (@mpt what do you think?) we can keep contact as is, an “either email or URL” thing.

And finally, we would need to decide what to do with the “privacy policy” field.

Ideally this will help clarify the work needed on each project. A cross-project bug like @kyrofa suggested might become unwieldy if there’s a lot of discussion to be had, so I thought I’d at least lay out a broad roadmap before going there.

  • Daniel

it is not one of the supported fields in v2 APIs for example afaict

Of course. I’m just saying, when the time comes to do this work, several projects need to coordinate.

https://bugs.launchpad.net/snapstore/+bug/1778068 seems to be about this.

It is indeed! We’ve just discovered this missing field while moving our API calls to v2.

1 Like

Thanks @mvo!

I prefer the first approach, so that it’s more obvious to developers what the field requires.

if you go with email-only fields, please keep the ability to set a subject via the entry like


or add an additional “mail subject” field to the form that will get automatically used.
as someone who owns a bunch of snaps being able to distinguish/sort via the mail subject is very helpful.

@mpt The store already has an email for the account, so we can already get in touch via email with anyone if that’s necessary.

That said, forcing people to provide an email that will be made public sounds unwise as people often won’t have that email and won’t want to make their own email public.

On the other hand, forcing people to provide a URL instead of an email is also not a great improvement, since a URL isn’t really a protocol that defines what kind of system will be waiting on the other side of the click.

So what we have is really something that tells a human being how to take the next step towards reaching someone that can respond for the snap. As such, I quite like the idea of leaving it up to the publisher to decide how they wish to be contacted in that specific case, with either an email or via a system pointed to by a URL.

@ogra That looks bad on a terminal and doesn’t copy & paste properly. One can easily filter that by customizing the email itself.

@niemeyer well, if you check i.e.

It gets masked as “Contact Oliver Grawert” in the store UI currently.

I agree it doesnt look particulary sexy, snapd also seems to be filtering out the mailto protocol prefix in the terminal output so the normal “ctrl+click” you can do on most modern desktops to auto-spawn the mailer from a terminal for protocol addresses sadly doesnt work (so yeah, the mangling makes you end up with a copy/paste job):

$ snap info mjpg-streamer|grep contact
contact:   ogra@ubuntu.com?subject=mjpg-streamer

Despite its ugliness, I really like the current freedom the field gives me as a devloper/snap maintainer (and I actually get regular emails though the contact link with user feedback, so it cant be too bad) and i’d be happy if it could be kept that freely configurable.