AAP

Application Announcement Protocol

What is Application Announcement Protocol (AAP)

AAP is a decentralized discovery and metadata publication protocol for applications. It allows you to announce the availability of applications (web, native or otherwise), and allows clients to manage, organize and discover new applications.

Why would I use AAP?

AAP provides machine-readable application discovery for agents, aggregators, and cross-platform catalogs.

With the increase in web applications, it can be hard to keep track useful tools. Outside of walled gardened appstores There is no consistent way to present information about applications, and no mechanism to discover when new applications are released, or to find curated lists of trusted tools.

AAP provides app creators with a consistent way of structuring metadata about their applications to make it easier for users to discover, curate and manage applications.

AAP does not provide a central registry of tools or feeds, although third parties may choose to use AAP to create such a service. Due to it's open nature, users will always be able to subscribe to any independently provided feed without being dependent on a single central authority

What can you do with AAP

• Subscribe to applications and view metadata
• Receive updates about applications
• Organize apps in a single location
• Follow individuals or companies for new releases

• User-collated application catalogs or stores
• Developer/Publisher follow-feeds.
• Aggregated discovery platforms.

What isn't AAP

AAP provides metadata only. It specifically is not a protocol to handle:

• Installation, authentication, or payment.
• Execution or sandboxing environments.
• Global trust or reputation systems.
• Guarantees of safety, quality, or correctness.

Trust decisions are delegated to clients, aggregators, and users. AAP provides the mechanisms for feed integrity, identity, and optional publisher identification.

AAP does not aim to replace existing web standards.

RSS/Atom syndicate time‑ordered content such as articles, posts, or media. While they could be used to announce software releases, their data model is optimised for human‑consumable content rather than structured application metadata. AAP focuses specifically on application identity, rich metadata, and long‑lived discovery, rather than episodic content updates.

OpenSearch and Web Manifests define how applications and websites describe their own capabilities, behaviour, or integration points, typically from the perspective of a single application instance. AAP provides a catalogue‑oriented feed designed to describe multiple applications, versions, or releases in a consistent, machine‑readable way that can be aggregated, indexed, and curated by third‑party clients.

AAP is concerned with announcing and discovering applications, not rendering content (RSS/Atom) or describing runtime behaviour (manifests). These standards can be used together: an AAP entry may reference RSS feeds, manifests, repositories, or other resources as part of an application’s metadata.

Principles

AAP aims to obey these five tenets:

1. Easy to understand and get started. Non-engineers users should be able to create and understand an aap.json file. The most basic possible aap.json file is simple and easy to get started with.
2. Use standard web technologies. AAP consists of files that can be hosted on websites in json.
3. Require no specialist tools or infrastructure. AAP consists of text files that can be hosted on a website.
4. Extensible for advanced information and clients. While easy to start, AAP contains enough fields and capabilities to allow advanced metadata features that may not be used by most clients, but are possible. The easy things are easy and the hard things are possible.
5. Future versions must maintain backwards compatibility. New versions of the specification will add additional capabilities, and will not introduce breaking changes.

To assist with these five tenets, AAP has developed a number of conventions:

• All keys are in camelCase
• Strings are represented as singular nouns, arrays are plural nouns
• Any field that expects a URL is named nameUrl.
• Any field that expects an email is named nameEmail.
• All dates are in ISO 8601 format.
• The json structure consists only of strings, ints, doubles and arrays.
• The json structure for each application is intentionally flat.
• When a value allows multiple values (tags, categories etc) these should be represented as an array of items, not as comma separated values within a string.
• Extensions beyond the specification are possible, but restricted to the custom object so as not to interfere with future possible extensions.

{
  "name": "Minimal App Feed",
  "description": "A feed containing only the absolute requirements.",
  "url": "https://example.com",
  "applications": [
    {
      "name": "Example App",
      "description": "A simple application entry.",
      "url": "https://example.com/app",
      "guid": "https://example.com/app/unique-id-123"
    }
  ]
}
                

<meta name="application-announcement-protocol-location" 
      content="https://example.com/feeds/aap.json" />

{
  "custom": {
    "accent_color": {
      "label": "Secondary Brand Color",
      "value": "#ff0000"
    },
    "api_endpoint": {
      "label": "Custom API Gateway",
      "value": "https://api.example.com"
    }
  }
}