M3.x website links

[BigLep]

Note: this issue will be marked as closed once all the links have been set in the demo app.

Main page links

• IPFS Gateway render: https://ipfs.io/ipfs/${cid}/${filename}
• IPFS Gateway download: https://ipfs.io/ipfs/${cid}/${filename}?filename=${filename}.car
• Provider: https://pdp.vxb.ai/calibration/providers/${providerId}
• Piece CID (Piece Explorer): https://pdp.vxb.ai/${network} || 'calibration'}/piece/${pieceCid}
• Download from SP: https://${serviceProviderDomain}/ipfs/${ipfsRootCid}?filename=${filename}.car
  • 2025-10-14 notes:
    • This isn't what was originally scoped. We instead wanted to trigger a download of the uploaded file. This requires feat: download from SP returns uploaded file rather than CAR #24, which we won't get to before 2025-10-15. As a result, we're just falling back to allowing a download of the CAR that was uploaded.
    • We use /ipfs instead of /piece, because /ipfs will cause the resulting file to have a .car file suffix, which is more accurate and self-documenting.
• View proofs: https://pdp.vxb.ai/calibration/dataset/${datasetID}

❓ Why are we using ipfs.io rather than dweb.link?
It would be ideal to use dweb.link rather than ipfs.io because:

1. ipfs.io is more likely to get whole-sale blocked at various levels in the internet stack. It's historically been a "dirtier" domain. One example of the domain being blackholded: https://blog.ipfs.tech/2021-08-27-IPFS-io-gateway-outage-resolution/
2. dweb.link has origin isolation because it's a subdomain gateway.

That said, we've seen some odd certificate issues recently with dweb.link and we don't currently have time to debug them.

Documentation Links

Ensure that the links for learning more and documentation are filled in. This is part of the larger M3 documentation story.

This list includes:

• Filecoin Pay Account:
• Warm Storage Service:
• CAR: https://docs.ipfs.tech/concepts/glossary/#car
• Filecoin Piece CID:
• IPNI: https://docs.ipfs.tech/concepts/ipni
• Left-hand-side Learn More:
• GitHub Action: https://github.com/filecoin-project/filecoin-pin/tree/master/upload-action
• CLI: https://github.com/filecoin-project/filecoin-pin
• Clone this demo: https://github.com/filecoin-project/filecoin-pin-website/fork
• Piece explorder: https://pdp.vxb.ai/calibration/piece/$pieceCid

Reference:

We'll fill this in as they get decided and/or determined.

[BigLep]

I expanded the issue to cover the main page links as well (extracting out from what was at https://www.figma.com/design/CIlBfFz5pCJ1RL3Ih8T2zb/Filecoin-Pin )

[BigLep]

The issue description has been updated to also include notes about what to l link to in the main part of the page.

A few callouts:

1. We're just going to switch to ipfs.io rather than dweb.link
2. As much as possible, we want to link to the actual file rather than the CAR itself. As a result, links update to be /ipfs/$ipfsRootCid/$filename
3. For "Download from SP", we won't be able to download the uploaded file. We can only download the resulting CAR that was uploaded. We'll improve this soon with feat: download from SP returns uploaded file rather than CAR #24

[BigLep]

@rvagg : for "download (car) from SP", I wanted to be able to do https://${serviceProviderDomain}/ipfs/${ipfsRootCid}&download=true&filename=${filename} so I could get file.extension.car but it doesn't look like Frisbii / Curio support download and filename query parameters. Is that expected?

[rvagg]

@BigLep it should. Maybe it's your URL that's mangled, you have & first and not ?.

You don't even need download=true, and filename must have .car at the end of it, but it should work just fine:

https://polynomial.pro/ipfs/bafybeia466paw3rzvel46slrpwbc4w7bckalt3u4xf5jc47pz4r5cv4c5q?filename=mydata.car

[BigLep]

@BigLep it should. Maybe it's your URL that's mangled, you have & first and not ?.

Doh - thanks @rvagg ! I have updated the issue descriptions and created #70

@SgtPooki : are you to handle/review/merge? There is an optional string I didn't work through in one of the parameters...

[SgtPooki]

that work is done @BigLep with #74