# hAppStore Spec
###### tags: `specs` `hApp`

## Context

- We need a public facing hApp that will be tightly integrated with the Launcher to let end-users pick hApps to install on their machines.
- Holo needs a hApp that publishers/proividers can pick from to start publishing/providing hApps

## Assumptions
- We need a distributed app for distributing happs
- The hApp store is targeted to end-users, to enable them to install apps.
- The hApp store will be integrated with the Launcher
- The hApp store will be enabled by default on MOST holochain installs
- Because it will have such a large userbase of end-users, we want to keep it lightweight, so the WASM and source code of apps will be stored in DevHub
- hApp store will download apps via bridged calls to nodes that are using DevHub.
- Users need to be able to search the hApp Store
- The available hApps should be filtered automagically for the users context so they don't get results they can't use

## hApp Filtering Ontology

**Automatic Filters** set for the user by their context
- Distribution type
- Holochain Version
- OS-Platform: mac, pc, linux (flavor)

**Manual Filters** available to users to set
- Categories
- Keywords (for free-text searching)
- Review threshold(s)
- Free/Paid
- Tags (folksonomic)
- Membrane requirements: email address, mobile number, Eth Address, KYC verification, invitation code, etc.
- Open source

## hApp Graph
We will use the PATH module to create link sets for the filter criteria that we can do set logic with to produce filtered results.

There are some other link types that are NOT blended into the combined filters, but used independently (e.g. publisher, featured apps, etc.)

## Distributions

- *dna: A single dna app service w/o UI
- *.webhapp: multi-dna app bundle with webUI
- standalone_[mac/win/linux/android/ios/occulus/steam]_url: (Electron/Tauri/QT) // points to external file where you can download the asset, i.e. binary not stored in DHT
- webskins: Additional UI for an app
- holo hosting compatible
- we compatible
- neigbourhood compatible
- ad4m compatible

## Entries

### dev hub requirements:
// in the devHub there should be a:

struct ProjectBundle {
  stewards: Vec<AgentPubKey>,
  name: String,
  oneliner: String,
  ...
}

An a name-space tree with links that point to project bundles (validation allows only one per agent). MVP uses first-come first server to display, later we prove first-come with rough-time name-space service.

On the AppStore side, the happ record (see below) stores a tree path name and looks up the one link by the developer AgentPubKey.

### happ entry types

struct Happ {
  name: String,
  icon: String,
  one_liner: String,
  screenshots: Vec<String>, // base64 encoded 
  description: String,
  project_path: String, // pointer to path tree on devhub for locating current ProjectBundle
  developer: AgentPubKey, // Hash of developer on the DevHub
  publisher: EntryHash, // publisher Hash
}

struct Publisher {
  name: String
}

## Zome calls

[incomplete]

## Gaps

- Vetting on the DevHub and how this relates to thresholds of things showing up in the hAppStore
- How to modularize so vetting types/methods can be added?
- How to vet vetting?
- "Permanent" Project "Bundle" on DevHub
- Managing different Distributions & Versions on DevHub and keeping linked to the correct app store listings
- Vetting binaries, (store on cloudflare pages? R2)
- User ratings