I’m proposing a new draft ENSIP for a JSON package manifest format for ENS names.
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.
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.
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?
I’m a big fan of distributing software (both packages and applications) using ENS, because it gives you notarization without centralized intermediaries (like Apple). Happy to see you pick up this work!
Your approach makes sense as an abstract idea, but it’s unclear to me what the use case is. Is this for any particular language ecosystem? What tools do you see adopting such a standard?
Distribution - this seems very redundant to me. If you are already using content addressing (e.g. IPFS) why wouldn’t you just bundle all contents? Allowing for https here for example is very counter productive. Imo, the ideal format here is that instead of setting the ENS contenthash to a JSON file, you actually set it to a folder (e.g. in IPFS) then have a `/enspkg.json` file, and you can include all other files needed by the package as well in the same bundle.
Signatures - Not sure I follow what value signatures would add here. One benefit of putting packages on ENS is that a signature is required to update the blockchain state. You could add additional security by having a multisig control the ENS name and adopt the signing process to suit the need of your organization. Imo, adding sigatures as something inside of the package that a consumer needs to consider harms the usability of this standard.
The goal of the ENS Package Manifest standard is to allow for more ways to resolve verifiable data using ENS. IPFS is just one method that the standard supports. IPFS has pros and cons. The main point of friction for IPFS is that it is a “special” system that developers have to learn, and they must use special software to host and resolve it, which creates developer friction. Also, the pinning ecosystem is tiny compared to standard cloud hosting services.
The new standard has the flexibility built in to allow for redundancy, for example, multiple URL endpoints or even mixing IPFS with URL endpoints. The goal is to allow developers to use what they know and still be able to create packages that can be indexed and displayed as part of a standard. Signatures are needed to verify that the data resolved offchain is the same as the signature stored onchain or verified onchain.
That being said, this draft is intended to be a first draft that can be revised into a final draft proposal. My hope is that through experimentation and working with the standard, we will learn what works and what doesn’t, eventually arriving at a final draft standard that allows for a greater number of methods for resolving package data using ENS.
This point doesn’t really make sense to me. if you add ipfs: as a thing the protocol you’re proposing should support, the software that downloads dists needs to support it anyway. So the friction is already there.
Sounds more like what you want is a checksum rather than a cryptographic signature?
That’s great. I still think you need to focus this on a particular use case, e.g. a language ecosystem. For example, I think a package manager for Solidity would be an amazing first use case for such a system!