Add ENSIP: ENS Package Manifest

Premm.eth · June 3, 2026, 5:38pm

I’m proposing a new draft ENSIP for a JSON package manifest format for ENS names.

github.com/ensdomains/ensips

Add ENSIP: ENS Package Manifest

master ← nxt3d:ens-pkg

opened 10:01PM - 29 May 26 UTC

nxt3d

+225 -0

## Summary Adds a new draft ENSIP defining a JSON package manifest format for E…NS names. An ENS name points to the manifest via its `contenthash` record (per ENSIP-7), and the manifest tells clients the package name, version, files, executable commands, and where to fetch the package contents. The format reuses familiar package metadata conventions (npm/yarn/bun style) so existing package tooling concepts carry over, while letting package contents be distributed through ENS-compatible systems such as IPFS. ## What it specifies - **Manifest location**: published at the ENS name's `contenthash` resource as a JSON document; recommended MIME type `application/ens-pkg+json`. - **Top-level envelope**: `{ manifest, signatures }` so optional signatures sign the manifest object without mutating it. - **Manifest fields**: `name`, `version`, `dist` required; standard package metadata (`author`, `contributors`, `description`, `license`, `repository`, `dependencies`, `devDependencies`, `scripts`) optional; `files` and `bin` optional with npm-style semantics. - **Distribution**: a `dist` object with exactly one of `tarball` or `directory`. URIs may use `https:`, `ipfs:`, `data:`, or any other client-supported scheme. SRI-style `integrity` is required for non-content-addressed sources and optional for content-addressed ones (e.g. IPFS CIDs). - **Signatures**: optional `signatures` array, with EIP-191 as the recommended scheme, signing the canonical JSON serialization of the `manifest` object. - **Client behavior**: resolve `contenthash` → fetch manifest → verify signatures (optionally) → fetch package contents → verify integrity → select file or executable. ## Why a JSON document instead of HTML An earlier draft of this proposal embedded the JSON inside an HTML document so the manifest could double as a human-readable page. After feedback, the spec was simplified to a plain JSON document: clients have a single canonical format, and any HTML or other UI can load the JSON via `fetch()` and render it however it wants. That presentation layer is now explicitly out of scope of the spec. ## Out of scope - HTML or other human-facing presentation layers (clients may build them on top of the JSON). - Per-file URI/hook entries — replaced by a `dist` artifact / directory with package-level integrity. - ERC-8121 hook sources — removed; if on-chain file resolution is needed it can be layered on top in a separate proposal. ## Request Requesting: 1. Review of the spec. 2. Assignment of an ENSIP number (currently uses the `ENSIP-XX` placeholder in the heading). Open to feedback on field names, signature conventions, the `dist` shape, and whether the top-level envelope is the right place for signatures.

The basic idea is that an ENS name can point to a package manifest using its contenthash record, following ENSIP-7. That manifest would then describe the package name, version, files, executable commands, and where clients can fetch the actual package contents.

The format is intentionally familiar. It follows the general shape of package metadata used by tools like npm, yarn, and bun, so existing package tooling concepts should carry over naturally. The difference is that the package can be discovered through ENS and distributed through ENS-compatible storage systems like IPFS.

What it specifies

Manifest location: published at the ENS name’s contenthash resource as a JSON document; recommended MIME type application/ens-pkg+json.
Top-level envelope: { manifest, signatures } so optional signatures sign the manifest object without mutating it.
Manifest fields: name, version, dist required; standard package metadata (author, contributors, description, license, repository, dependencies, devDependencies, scripts) optional; files and bin optional with npm-style semantics.
Distribution: a dist object with exactly one of tarball or directory. URIs may use https:, ipfs:, data:, or any other client-supported scheme. SRI-style integrity is required for non-content-addressed sources and optional for content-addressed ones (e.g. IPFS CIDs).
Signatures: optional signatures array, with EIP-191 as the recommended scheme, signing the canonical JSON serialization of the manifest object.
Client behavior: resolve contenthash → fetch manifest → verify signatures (optionally) → fetch package contents → verify integrity → select file or executable

Please feel free to give feedback, including proposed improvements to the format. The main goal of this post is just to get the dialogue started around a canonical ENS-based package format.

jkm.eth · June 4, 2026, 1:21pm

Users can already use contenthash to point to a package manifest using an existing format. It looks to me like the only new thing included in this ENSIP is the definition of a new package manifest format, which is unrelated to ENS functionality. Can you explain a realistic use case that can’t be achieved with existing standards and features, that this ENSIP would solve?