Skip to content

IPNS/IPLD/Unixfs path handling investigation #17

@Arlodotexe

Description

@Arlodotexe

Overview

Investigation into IPFS/IPNS path handling for entity data and webpage integration, determining technical approach for linking IPLD DAGs to unixfs content.

Background

We need to understand how to properly handle IPFS/IPNS addressing for our infrastructure migration, particularly:

  • Converting custom IPLD DAGs to unixfs DAGs for webpage viewing
  • Path handling and referencing strategies
  • Integration with existing entity system

Key Technical Questions

IPLD to Unixfs Conversion

  • How do we go from a User/Publisher/Project DAG to a unixfs DAG which can serve as a generated webpage?
  • Is it enough to simply add the data as a connection value and extract it during referencing webpage generation?

CID vs IPNS Strategy

  • Can we get away with using immutable CIDs instead of creating more IPNS IDs?
  • Since connection uses a string value, from an SDK perspective we'd have to use a serialized DAG link
  • The type won't be built-in, as we only expose SDK interfaces or primitives through SDK interfaces, avoiding IPFS-specific types
  • Since this is linking a normal immutable CID, the user can decide to publish this via IPNS on their own terms

Webpage Integration Constraints

  • We need to avoid embedding ipfs (helia) in the generated webpage as much as reasonably possible
  • Are we linking to CIDs in the webpages themselves?
  • How are we extracting and providing them?
  • Do all references need to be updated when the content changes?
  • While we could do that for the discord bot, we can't do that distributed

IPNS Reuse Strategy

Before we decide that this means creating two IPNS keys-- can we reuse the existing entity IPNS for unixfs data?

  • We can store unixfs data as a field, but we can't reference that field as a unixfs path when viewing the data in the browser
  • Testing with our CLI application, yes we can reference IPLD links using relative paths from the browser

Current Investigation Results

Path Referencing Validation

Confirmed: We can reuse the existing entity IPNS address for webpages or direct file links!

Example working pattern:

  • User at ipns://k51qzi5uqu5dgkmafpmiri9plf8ablqb7gu8sk5t3ps4rs4hgq2bq7mqrgd0ya has a DAG link under Projects[0].Role
  • Viewing ipns://k51qzi5uqu5dgkmafpmiri9plf8ablqb7gu8sk5t3ps4rs4hgq2bq7mqrgd0ya/Projects/0/Role displays that DAG directly
  • This should also work with unixfs!

Recommended Technical Approach

Since the field name decides the path, we might not use the Connections field for this.

Instead, we may need to design a proper extension to the SDK-- something that inherits existing code and extends it to include new methods and event stream data.

A proper Nomad extension (rather than relying on the existing Connections list) will allow us to create links like ipns://k51qzi5uqu5dgkmafpmiri9plf8ablqb7gu8sk5t3ps4rs4hgq2bq7mqrgd0ya/blog that directly gives you the unixfs files for the website.

Related Components

This investigation directly impacts:

  • Blog Generator Tooling (needs unixfs webpage publishing)
  • Entity Profile Tooling (needs IPLD to webpage conversion)
  • Appathon Event Tooling (may need both of the above)

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

Status

New

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions