This is a UX design page for Flathub. It details user experience and functional goals for the design, along with possible workflows.

• Easy and obvious for an application developer new to Flatpak to build and publish an app .
• Site organisation should be clear and as simple as possible
• Reflect and reinforce Flatpak concepts and workflows
• Modern and attractive in appearance/experience
• Integrate with developer tools

• Part of the process of getting an application into the Flatpak Store
• A way to make builds available to others for testing - making an app public but not offering to every user through the store
• Shared builds between team members
• Automated builds
• Builds on multiple architectures
• A way to explore other people's builds

Developers are likely to start using Flathub after their application is already in development, and after they have started using Flatpak and flatpak-builder.

• Application developers - build, test and publish applications
• Admins - monitor the infrastructure, review published applications
• End users
  • Applications will typically be installed through a local app store app
  • Will likely want to use Flathub as a public/web presence for Flatpak apps
  • Might need information about how to get Flatpak apps, depending on their distribution/desktop environment

• Register and authenticate as a user
• Required information: name, email address, password
• Edit user details
• Picture, name, email address, website/Github URL, bio, password...
• Possibly upload a GPG key for your user account; need to figure out the signing story before deciding about this
• Create apps (each app is a single OSTree repository)
• Identify yourself as the author of the app, or as a member of the official development team (will likely have to be done through the domain)
• We're only going to accept open source projects in the first instance; will need a statement about this somewhere
• Might need to be some statement or argeement about licence compliance
• Edit app properties
• Remove apps
• Apps always belong to a user (or a team, but that'll come later); this is reflected in the URL. Example: "flathub.com/alexl/gnome-contacts"
• This makes it possible for different people to have builds of the same app; or people to fork a build
• Needs to be possible to migrate apps from user to user - say if someone wants to pass on maintainership

• Add and remove branches
• Each branch points to a build configuration (made up of a build file and optional dependent files) that is stored in a Git repo (somewhere else)
• Guide developers to use standard branch organization and naming
• Allow branches to be set up as nightly builds
• Make branches available to install for testing purposes (could be presented as a "public" property)
• Migrate a commit from one repo/branch to another. For instance, you may have a testing repo where you build things. Once tested you can then take the latest build from that and put (+re-sign) in the stable repo that you give to users. (This is the build-commit-from flatpak command.)
• We might want to require branch names to be prefixed with the username/teamname (at least for builds not verified as official). This ensures that they are always parallel installable, and it makes it obvious where the build comes from.

• Trigger a build in a branch through the website, a CLI or an IDE
• Notify developers when a build has finished
• View information about previous builds
• Which version of each module was built
• Useful debug information if a build fails
• Logs for later debug use
• See an overview of builds for each app - build history, queued builds, which builds have been pushed where

• Publish an app in the Flatpak Store for the first time; each new app must be reviewed:
• Ensure that the publisher is the app author
• Check that the app is what it claims to be
• Check that it has appropriate permissions
• Possibly some automatic security tests
• Inform the publisher when their app is on the store (or has been denied)
• Push updates to the Flatpak Store version
• These won't usually require review; possible exceptions - if permissions/app name/icon changes
• Might want to run automated tests each time
• Revert an update to the Flatpak Store version
• Remove an app from the Flatpak Store? How would this work?

• Commandline utility to upload build inputs, trigger builds
• Application reporting and revocation - users need a way to report an application if it misbehaves in a serious way; it should be possible to remove apps from the store and notify users who already have it installed
• Automatic scanning of builds, useful for everyone, but very important as a first step in reviewing for pushing to the app store

• Present an attractive, easy to understand landing page for new visitors to the site
• Should explain Flathub to potential users, invite them to try it out
• Browse and search for apps and show details about each one
• What details to show?
• Developer documentation will be needed for the site; how will this fit with developer documentation on flatpak.org?

• Interface for reviewing apps before they are published in the Flatpak Store
• Notifications for admins when new apps require review
• ???
• ???

• Allow releases to be signed using GPG. Current running theory: the infrastructure will automatically generate a key for each repository. The user will then optionally be able to authenticate using their personal GPG key in order to make a release.
• What gets signed exactly: branches, repos, releases?
• Will we require installable versions to be signed? This could just apply to the Store or to any installable version.

Functionality and features that we might want to add later:

• Organizations - to make it easy for groups of people to work on multiple projects at the same time
• It will be possible for apps to belong to either a user or an organization
• Will need to include permissions for organization members: start builds, add/remove branches, publish to the store, add/remove apps, able to install certain builds (beta/alpha, etc), and so on
• For users: a web-front end for the app store, which allows apps to be installed and managed on your device via the website, like Google Play
• Conflict resolution for claims to names and trademarks - in case someone who isn't the author registers the name of an app
• Allow app developers to view status information about the apps they've published in the Flatpak Store
• Ratings
• Number of installations (segmented by distro, version, etc)