Hello all,
This is something we’ve been discussing for quite some time in some circles, but we haven’t managed to get started on it or even write anything down. You may have heard about this as “entitlements”, and it has some similarities to what is well known as “in-app purchases” as well, except such features may not necessarily have an association with money.
This is an attempt to bootstrap a more formal conversation so we can start the initial steps towards eventually having the whole idea working.
Rationale
In some cases snaps may offer optional features that depend on the authorization of one or more third-parties for the feature to work. The simplest case to imagine is the availability of the entire application being conditional on payment, where the feature is being able to run the application at all, but there’s a gradient of richer use cases that benefit from finer grained control of what specifically is the application capable of doing, and then how to prove that it can indeed do it. For example, a backup snap might use that feature to communicate to the snap that remote backups to one or more storage services is available.
Proposal
Tersely, the idea is this:
- A snap has some optional features locally or that requires access to third-parties
- A snap may ask the store about which optional features are usable
- A snap may also ask the store for a token to provide to third parties as proof
Usage
We still depend on the terminology to settle (see below), but here are some ideas to get our minds ticking:
See what is enabled for a given snap:
$ snap entitlements mysnap
Snap Entitlement Expiration
mybackup storage -
From inside the snap, query to see if an entitlement is supported:
$ snapctl entitled storage
Ask the store for a token to communicate with the third-party:
$ TOKEN=$(snapctl entitled storage --token)
$ curl "https://...?token=$TOKEN"
The third-party can then double check with the snap to make sure that the communicating snap is indeed entitled to whatever it was trying to do.
We can also extend the entitlement latter with individual attributes if necessary. Most probably not the exact command line interface we’d want, but something along the lines of:
$ SIZE=$(snapctl entitled storage --attr=size)
We don’t need to cover that before we have everything settled, and there’s a chance this won’t even be necessary.
Implementation
To get started on this we don’t really need much. The initial implementation might just ask the store for tokens of the authenticated user when necessary. Using assertions might be interesting, but we need to discuss the fact systems would access independent assertions to enable particular entitlements.
The token feature might work similarly on a first version. Ideally the client would handle it as an opaque piece of data that is just conveyed to the third-party for validation with the store, if and when that’s indeed desired.
Terminology
I would like to avoid using “entitlements” in the final implementation of the feature. It feels too long, and somewhat entangled, unfriendly to non-native speakers and hard to type. We discussed “feature”, but that’s going to create plenty of confusion in conversations when talking about snap features. Also considered “permit”, but that’s too bureaucratic… and “subscriptions”, but that has a connotation of recurrence that may not apply. I’m leaning towards “skill” right now… but it still needs more discussions.