Creating resolvable PIDs without registering them in a registry, through CIDs and IPFS

PID Best Practices and User Stories
7

I am elaborating on the topic since the beginning of 2021 working for ExPaNDS project. I see the following main peculiarities both 2 types of PIDs used in IPFS/IPLD ecosystems have, that can not be overcome by known partially-centralized solutions:

  • CIDs are resolvable from anywhere if only the IPFS endpoint is available, and in any format acceptable by the implementation, with free conversion between the formats within the spec.
  • CID replaces cryptographic data signing, as IPFS block objects linked with the given CID carry their own metadata including the tree of links, so any CID of even partially stored data is verifiable and reproducible on-site.
  • IPLD/IPNS ecosystem separates concepts of data identifiers and endpoint identifiers (PeerIDs) deriving endpoint identifiers from user private keys. Thus PeerIDs are self-signed identifiers that would be minted only by the private key’s owner.
  • IPNS entry keys are resolvable to CIDs.

From my point of view, the enumerated peculiarities allow the creation of decentralized PID infrastructures in an easy way, even without a blockchain, referring mostly to PeerIDs, covering easily the tasks described, for example, here. The only task here that should be left to authority, is trusted verification that the given PeerID is owned by the known publisher. This task does not require a blockchain as it can be solved using an infrastructure similar to Root CA used for WWW TLS verification. Holding and enforcement of this authority is a procedural question.

In this presentation some additional concepts and proposals are described. There is also a Zenodo community including, among other stuff, the information about decentralization of the PIDs elaborated in the ExPaNDS project.

Especially, the described peculiarities of IPFS could be useful, in my opinion, for open-source software and dataset provenance. In a few days, I will publish here a topic with the link to the helper instruments supporting direct IPNS publishing of Git repositories under the IPNS entry key with immutable intermediate stages (there is an existing one, but it does not support IPNS directly).