https://wiki.gnome.org/GUADEC/2019/Hackingdays/FlatpakStore https://docs.google.com/document/d/1zE_QbB6mtdhjH5bsFdf9kPrYvjKAMBRl4uSRYDt-BqQ/edit?ts=5d6509ad#heading=h.4e7b49ri8p2g

Agenda

• libflatpak API changes
• Authenticator D-Bus API
• Generic authenticator/auth server design
• P2P support?

Two completely distinct parts:

• How does this work technically?
• How do we apply this to flathub/what model do we want to use?

How does this work technically?

Quick high-level overview of how it all works Note that it’s all ‘best effort’ — this is not hardcore DRM, and cannot, will not be Start with one authenticator implementation; will probably end up with a few distro-specific ones eventually P2P verification requires public/private keys for token signatures Need to iterate over specific API a few times/D-Bus XML blah blah do that in merge requests

Verbs

Can we add ‘verbs’ to tokens which authorise the user to do different things: download, run, upgrade, export (to USB), etc. Requires an internet connection when you’re running the app? Need to cache the tokens and they need a long validity period Can we do it without a D-Bus daemon running? (i.e. just within the flatpak process) It’s fine to talk to D-Bus (and use the network) at installation time; less so at run time

• Why do we need to not talk to D-Bus?

How does this integrate with the idea of leaving the token format open? Perhaps use whatever token format for downloading/installing (so OCI can use its own format); and require JWT for tokens with other verbs Apple and elementary stores have a way of saying that an app upgrade should be paid for again (elementary always allows payments to be optional)

• Idea is to handle major rewrites of applications; the new version is essentially a completely new app
• ⇒ Motivation for ‘upgrade’ verb

D-Bus API

Should be made more similar to other D-Bus APIs Race conditions need fixing

CDN/Caching

Idea is that we separate authorisation from actually serving the content objects So people can’t get the object hashes without showing a vallid authorisation token to get the commit object So CDNs and caches just cache all the objects as before The commit object is fetched from a server which does the authorisation checks (flat-manager)

• Delegating these authorisation checks to CDNs is not possible

Similarly for delta data blocks (cf content objects) vs delta superblocks (cf commit objects) There are many ways of working around the protection mechanism; that’s fine

How do we apply this to flathub?

Strawman:

• Do what elementary does
• Add a donation nag screen on flathub: every time you install/upgrade/whatever, it sends you to a donation page before bringing you back and providing the token

End goals:

• People who publish apps are able to make money from it
• So more people are incentivised put apps in flathub
• Might limit that capability to FOSS apps on flathub
• Want to avoid the moral hazard of becoming a proprietary app store

Aside: gnome-software now has donation links for users on the details page for each GNOME app in gnome-software; points to the Friends of GNOME page

Do we do this for every app, or only for apps which opt in?

• Would be weird if we started collecting money for apps whose authors are unaware

Do we want to integrate between flathub and Friends of GNOME? e.g. Friends of GNOME have essentially already paid, so just get a thank you instead of a donation nag?

• Similarly for KDE and whatever donation system they have

Other people might use the same plumbing for their own app stores (e.g. Endless, elementary) Potential implementation: Stripe

• Allows easy routing of percentages of payments to stakeholders in an app (authors, app packager, flathub)
• Tax handling needs doing; Neil’s problem; selling digital goods between countries; who is liable for paying the tax? (flathub, or the app authors, or what?)
• Because of the complexity of this, we might need to incorporate in the EU, or have per-country representatives; or something
• Requires some economies of scale in order to justify the legal expenditure of setting up ($10^4)
• Donations (from consumer to app author?) are easier; purchases or subscriptions are problematic due to the taxes they incur
• Donations to app authors may always count as taxable payments (depending on jurisdiction?)
• tl;dr: Lawyers need to be involved \o/
• Do we start with all countries enabled for payments? What does Stripe support?
• Support the US first (note: some states are special for sales tax), then EU?
• Some countries could never be supported due to trade sanctions which mean no payment system will service them (Iran?)
• Do all the app authors need accounts with Stripe? Neil handwaves; probably not; Stripe has some account options for something mumble

Do we want to enable proprietary applications on the platform?

• What do we mean by ‘proprietary applications’? Technical definition requires a lawyer; varies between jurisdictions
• How does this fit in with flathub’s mission?
• We think it’s OK to require non-zero payments for FOSS apps, because we’re providing the convenience of compiling, distributing them

Would flathub get a percentage of each donation, for paying for infrastructure costs?

• Does that fit in with the user’s intents when they make the donation? They’ve chosen to donate to a specific app, not necessarily flathub
• Would we allow the user to set this specifically when making their donation?
• Alternative model: allow apps to choose how much of their donations to give *back* to flathub/GNOME Foundation/etc.
• flathub does have fixed overhead costs (infrastructure, sysadmin time, invested money setting up what we already have); marginal costs from each app download are pretty low

Side note: How does Patreon work?

• It’s similar to Kickstarter: you support the artist as a concept, not guaranteed any particular digital or physical goods

Side note: We don’t yet have a terms of use or contributors’ agreement

• Mostly there yet, Neil is grumbling
• They are drafted but not implemented yet
• I’m going to be sacked as note taker
• Carry on please

Is this going to drive people away from flathub?

• Will people just install snap to get apps for free?
• Do we want to get something similar into (for example) Ubuntu?
• Making it possible to monetise apps is a diversity thing: making it possible to make money by writing FOSS makes it possible for people to choose that as a career (in situations where they wouldn’t otherwise have hobby time for writing FOSS)

How do we split contributions to uploaders vs the actual app authors?

• Verify that the two are the same?
• flathub already has a policy that the upstream maintainers should ‘win’ if they+others are flatpacking the same app; so leave it up to them to be proactive or lazy?
• Adding verification would add a barrier to uploading apps to flathub
• What about the situation where two people believe they’re the real upstream?
• We already experience this (sad panda); there are already mechanisms for handling it
• More cool things quickly in flathub is great
• Document a way for people to claim their already-packaged flathub app
• Donations before that point legitimately go to the non-app-authors who originally flatpacked the app
• Have to hold funds in escrow once a claim is put in place (that’s legally acceptable), release them + future donations once claim is resolved
• Claims have to come with a good way of identifying people
• If we allow non-author-flatpackers to flatpack apps they aren’t the authors of, we need to ensure that the packaging metadata is clearly licensed, otherwise we don’t know whether the actual app authors can reuse the same packaging when they eventually come to claim the app; license needs to allow us to redistribute the metadata
• Technically we already redistribute this metadata, so we should probably make sure it’s licensed appropriately already
• Just have the packaging metadata always belong to the platform?
• Make that part of the contributor agreement before we first enforce the contributor agreement

We are going to need a better website: web app that handles publishing, downloading, receiving payments, etc.

• Bart was volunteered by Rob and Neil
• (Accountabiity is important)

Timeline:

• Depends on how much Foundation help we can get on this
• Who can work on this? Everyone says maybe

Actions

• flathub: Roll out the CLA
• Foundation: Look more closely at the legal side of things
• Endless: flat-manager/flatpak authorisation D-Bus stuff (first part of the BoF)