What is did:ipfs and the did:ipfs service provider?

did:ipfs is a new Decentralized Identifier (DID) method designed to enhance the identification of files in the InterPlanetary File System (IPFS). did:ipfs unlocks the full potential of IPFS and addresses some of its core limitations. Additionally, did:ipfs offers distinct DID properties that augment existing DID methods, enriching the overall landscape of DIDs. More on did:ipfs can be found in its official documentation.

The did:ipfs service provider is an API that can be run locally and accessed through Swagger UI. This service provider enables users to create and resolve did:ipfs identifiers while managing the usage of did:ipfs services.

What inspired me to create did:ipfs?

I was motivated to enrich the landscape of DIDs by providing a DID method with unique properties. did:ipfs introduces several distinctive features that enhance the existing DID ecosystem, making it more versatile and capable of supporting a wider range of use cases. For a deeper exploration of these unique properties, please see the section on utility of did:ipfs as a DID method.

My additional inspiration for creating did:ipfs was to unlock the full potential of IPFS - a technology I am very passionate about. By enhancing the identification of files stored in IPFS, did:ipfs lays the fundament for a path that leads to the full potential of IPFS. For more details, please refer to the section on utility of did:ipfs for identifying IPFS files.

What I learned creating did:ipfs and the did:ipfs service provider?

Through the process of creating did:ipfs and the did:ipfs service provider, I significantly deepened my understanding of DIDs and became more familiar with the W3C's standard for DIDs. This knowledge has equipped me with valuable insights into the principles and practices surrounding DIDs and their implementations.

Moreover, I had the opportunity to learn new technologies, particularly in TypeScript, which has improved my programming skills. Working with frameworks such as NestJS and integrating Pinata's APIs further expanded my technical abilities.

How I built did:ipfs and the did:ipfs service provider?

I developed did:ipfs in accordance with the W3C's standard for DIDs. To create the did:ipfs service provider and its user interface, I utilized NestJS alongside Swagger UI. This service provider enables users to create and resolve did:ipfs identifiers while managing the usage of did:ipfs services, which are currently showcased in the implementation but not yet functional. For efficient and user-friendly interactions with IPFS, the did:ipfs service provider leverages Pinata's Web3 API. In addition, Pinata's File API is used by the did:ipfs service provider to give its users the option to store did:ipfs DID Documents in a private IPFS environment powered by Pinata. Overall, the integration of Pinata services equips the did:ipfs service provider with high data availability in IPFS, resulting in fast resolution of did:ipfs identifiers and enhanced user experience. Moreover, Pinata pins did:ipfs DID Documents in IPFS, ensuring their data permanency.

What challenges did I face during creation of did:ifps?

Ensuring compliance with W3C's standard for DIDs was crucial for creating did:ipfs, particularly when addressing self-referential CIDs in DID Documents.

What's next for did:ipfs?

  1. Enhance error handling for the did:ipfs service provider.
  2. Scrutinize the current compliance of did:ipfs with the W3C DID standard. If compliance is violated, did:ipfs will be adapted till full compliance is attained. The goal is to get did:ipfs included in DIF’s Universal Resolver.
  3. Conduct a comprehensive comparative analysis between did:ipfs and other DID methods.
  4. Develop did:ipfs services, such as the IPFS search engine and the Machine Learning data provider. As of now, all did:ipfs services are only showcased and not functional in the current implementation of the did:ipfs service provider.
  5. Strengthen IPFS data permanence by a dedicated did:ipfs service which facilitates the connection between file uploaders and IPFS nodes for exchanging storage proofs to ensure permanence guarantees.
  6. Implement trustworthy timestamps within did:ipfs DID Documents, potentially through the integration of Qualified Trust Service Providers (QTSPs).

Built With

Share this project:

Updates