-
Notifications
You must be signed in to change notification settings - Fork 0
Description
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 underProjects[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
Projects
Status