Add ENSIP: ENS Package Manifest#80
Open
nxt3d wants to merge 3 commits into
Open
Conversation
- HTML manifest at contenthash listing files via URI or ERC-8121 hooks - File entries: data-path, data-hash, data-hash-algorithm; URI (href) or hook (data-hook) - Optional JSON manifest with bin (name→path), default (command name) - Source indicators: ipfs: path (linked) or hook: path (non-link span) - Full example with ensx CLI pseudocode Made-with: Cursor
Switches the draft from an HTML wrapper with per-file URI/hook entries
to a plain JSON manifest using familiar package metadata fields, with
a top-level { manifest, signatures } envelope so signatures can attest
to the canonical manifest object.
Manifest fields now follow npm conventions where possible: name,
version, description, author, contributors, license, repository,
dependencies, devDependencies, scripts, files, bin. Distribution moves
to a dist object with exactly one of tarball or directory, addressable
via https, ipfs, data, or other URI schemes, and an SRI integrity
string for non-content-addressed sources.
Drops the HTML manifest wrapper, per-file hash/source entries, and the
ERC-8121 hook source mode. HTML or other human-facing UIs can still
load the JSON via fetch and present it; that layer is out of scope.
Adds an optional signatures array carrying EIP-191 signatures over the
manifest object so publishers can attest to releases without altering
the package metadata being signed.
Tightens path safety: package-relative paths MUST NOT be absolute,
URLs, or contain '..' segments. Security Considerations call this
out explicitly.
dist can now be either a single distribution object (unchanged) or a non-empty array of distribution objects. When an array, clients try entries in order; the first that successfully resolves and verifies is used and the rest are ignored. All entries MUST resolve to the same package contents. This lets a manifest carry, e.g., an HTTPS tarball as the primary source plus an IPFS fallback in the same release, without forcing publishers to pick one or republish for each mirror. Updates the worked example to demonstrate the array form (HTTPS primary with SRI integrity, IPFS fallback by CID). Updates the Client Behavior steps to read 'try entries in order' on array dist. Integrity rules are unchanged per entry: required for non-content- addressed sources, optional for content-addressed ones.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a new draft ENSIP defining a JSON package manifest format for ENS names.
An ENS name points to the manifest via its
contenthashrecord (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
contenthashresource as a JSON document; recommended MIME typeapplication/ens-pkg+json.{ manifest, signatures }so optional signatures sign the manifest object without mutating it.name,version,distrequired; standard package metadata (author,contributors,description,license,repository,dependencies,devDependencies,scripts) optional;filesandbinoptional with npm-style semantics.distobject with exactly one oftarballordirectory. URIs may usehttps:,ipfs:,data:, or any other client-supported scheme. SRI-styleintegrityis required for non-content-addressed sources and optional for content-addressed ones (e.g. IPFS CIDs).signaturesarray, with EIP-191 as the recommended scheme, signing the canonical JSON serialization of themanifestobject.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
distartifact / directory with package-level integrity.Request
Requesting:
ENSIP-XXplaceholder in the heading).Open to feedback on field names, signature conventions, the
distshape, and whether the top-level envelope is the right place for signatures.