Protocol v2.0.0
← Back to RFC Index

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

RFC: 0008
Title: Media Assets, Package Manager Distribution, Execution Requirements & Push-Ping Ingestion Protocol
Author: Protocol Stewards & Registry Interoperability WG
Status: Working Draft — in msr-2.1-draft.json only, not ratified
Date: 2026-09-21

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 (such as MySoftRank), 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://www.youtube.com/watch?v=dQw4w9WgXcQ"
}
Field Type Description
icon object Standardized icon formats and pixel dimensions (svg, png_32 to png_512).
screenshots array Array of screenshot objects with mandatory url, optional dimensions, title, and BCP 47 lang tag (RFC 0006).
video_demo_url string (URI) Authoritative HTTPS URL to a video walkthrough or demonstration.

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 forcing registry crawlers to hammer hundreds of thousands of publisher domains daily, publishers can dispatch an authenticated Push-Ping webhook when publishing a release: 

POST https://mysoftrank.com/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. Bandwidth Reduction: Adopting Push-Ping eliminates continuous polling loops, decreasing registry outbound bandwidth and publisher server load by more than 90%.

6. Compatibility

The properties defined in this RFC reside exclusively in the experimental schemas/msr-2.1-draft.json schema. Existing MSR JSON 2.0 manifests and production 2.0 validators are unaffected and will reject these properties under additionalProperties: false until the 2.1 protocol is formally ratified.

7. Security & Safety Considerations