RFC 0008 — Media Assets, Package Managers, Execution Requirements & Push-Ping Protocol

1. Motivation & Historical Diagnosis

For over two decades, the shareware industry relied on the Association of Shareware Professionals (ASP) PAD XML format. PAD XML established vital patterns for software catalogs: rich multi-resolution icons, annotated screenshots, clear hardware requirements, and distribution channels. However, PAD XML suffered from fatal design vulnerabilities: lack of cryptographic signatures, no domain ownership authority, reliance on unstructured text fields, and an exclusively passive pull model that overloaded web networks with uncoordinated crawlers and exposed directories to Server-Side Request Forgery (SSRF).

MSR JSON 2.0 solved the security and governance architecture through Ed25519/ECDSA signatures, canonical domain binding (/.well-known/msr.json), SemVer compliance, strict JSON Schema validation, and interfaces for modern AI agents and MCP servers. Yet MSR JSON 2.0 omitted standard visual media declarations, ecosystem package manager mappings (e.g. PyPI, Homebrew, Docker), structured execution requirements, and real-time push notifications.

RFC 0008 introduces four high-impact extensions for the MSR JSON v2.1 specification, bridging visual catalog presentation, agent execution safety, and real-time indexing.

2. Standardized Media Block (entity.media)

Catalogs, software directories, and discovery agents require verified visual assets to present software without relying on brittle HTML screen scraping. RFC 0008 adds an optional entity.media object:

"media": {
  "icon": {
    "svg":     "https://example.com/assets/icon.svg",
    "png_32":  "https://example.com/assets/icon-32.png",
    "png_64":  "https://example.com/assets/icon-64.png",
    "png_128": "https://example.com/assets/icon-128.png",
    "png_256": "https://example.com/assets/icon-256.png",
    "png_512": "https://example.com/assets/icon-512.png"
  },
  "screenshots": [
    {
      "url":    "https://example.com/assets/screen-main.webp",
      "title":  "Main Dashboard",
      "width":  1920,
      "height": 1080,
      "lang":   "en"
    }
  ],
  "video_demo_url": "https://example.com/assets/demo.mp4"
}

3. Distribution & Package Managers (distribution)

Modern software is consumed through diverse package registries and application stores. Declaring these identifiers enables directories and autonomous AI agents to generate installation instructions (e.g. brew install, pip install, docker pull) automatically.

RFC 0008 introduces distribution as a root-level property:

"distribution": {
  "package_managers": {
    "pypi":     "my-pkg",
    "npm":      "@org/my-pkg",
    "crates":   "my_crate",
    "homebrew": "my-tool",
    "flathub":  "org.example.MyTool",
    "docker":   "org/my-tool"
  },
  "app_stores": {
    "google_play":     "com.example.app",
    "apple_app_store": "id1234567890",
    "microsoft_store": "9NBLGGH42THL"
  }
}

4. Execution & Hardware Requirements (capabilities.requirements)

To prevent autonomous agents or users from downloading and attempting to execute incompatible binaries or models, RFC 0008 standardizes structured machine requirements inside capabilities.requirements:

"requirements": {
  "architectures": ["x86_64", "arm64"],
  "operating_systems": [
    { "os": "linux",   "min_kernel":  "5.15" },
    { "os": "darwin",  "min_version": "13.0" },
    { "os": "windows", "min_version": "10.0.19041" }
  ],
  "hardware": {
    "min_ram_mb":         512,
    "recommended_ram_mb": 2048,
    "min_storage_mb":     100,
    "gpu": {
      "required":   false,
      "min_vram_mb": 4096
    }
  }
}

Recognized architectures include x86_64, arm64, aarch64, riscv64, wasm32, and universal. Recognized operating systems include linux, darwin, windows, freebsd, android, and ios.

5. Push-Ping Ingestion Protocol

Rather than waiting for registry crawlers to poll their domain, publishers can notify the registries listed in telemetry.ping_endpoints when they publish a release. The ping is an unauthenticated hint that carries only the domain; it is never a source of data:

POST https://registry.example.org/api/v1/ping
Content-Type: application/json

{
  "domain": "example.com"
}

Normative Ingestion Rules for Push-Ping:

1. Domain Authority: Registries MUST NOT index unverified payload bodies submitted via ping. On receiving a ping, the registry enqueues the domain and independently fetches https://<domain>/.well-known/msr.json according to RFC 0001.
2. SSRF Mitigation: All pre-flight DNS and IP-range safety checks mandated by RFC 0007 (Section 3) MUST be enforced prior to dispatching outbound HTTP requests.
3. Cryptographic Verification: If the fetched manifest contains a trust.signatures block, the signature MUST be verified before promoting the new release into canonical public indexing.
4. Polling: A registry that honors pings MAY poll less often, but MUST keep polling with the cache validators of RFC 0007, because a ping can be lost and is never required.
5. HTTPS only: Every URL declared under entity.media and every telemetry.ping_endpoints entry MUST use https://; the schema rejects other schemes.

6. Compatibility

The properties defined in this RFC ship in MSR JSON 2.1 (schemas/msr-2.1.json). Existing MSR JSON 2.0 manifests stay valid, and 2.0 validators keep rejecting these properties under additionalProperties: false: a manifest that uses them declares the 2.1 schema.

7. Security & Safety Considerations

• SVG Media Sanitization: Registries MUST NOT render publisher-provided SVG images directly inline in browsers without prior sanitization, preventing embedded script execution (Stored XSS).
• Image Proxying: Registries SHOULD cache and proxy screenshot and icon assets to prevent publisher tracking of registry visitor IP addresses.
• Ping Flooding: Registries MUST apply rate-limiting per IP and per target domain on their ping endpoints to prevent distributed denial-of-service amplification.