Discussion: IPFS Support

[wilwade]

Currently supported URL schemes do not support IPFS

• Announcements: Eg: Broadcast Announcement.
• Activity Content: https://spec.dsnp.org/ActivityContent/Overview.html#supported-url-schema

I suggest both of these should be updated to include IPFS URI support: https://docs.ipfs.tech/how-to/address-ipfs-on-web/#native-urls

[wilwade]

Frequency // DSNP Spec Meeting Notes for 2022-10-13

• IPFS increases the complexity for those consuming the data
• IPFS lag is an issue for fetching lots and lots of individual announcements
  • Example: IPFS doesn't have a 404 or common (short) timeout like HTTP.
• Can this just be a product and business choice? Choosing if you want to use it or ignore it
• Easy to add it later and give assistance in how to make content available quickly
• What about some way to get it faster. aka give an IPFS as well as a URL, URL for short-term and IPFS for long term

Action Items:

• IPFS lag data for next time
  • https://github.com/ipfs-inactive/js-ipfs-http-client/issues/781
• WW to reach out to IPFS about speed, timeouts, and https+ipfs ideas.

[wesbiggs]

Consider addressing IPFS as HTTPS URLS e.g. https://ipfs.io/ipfs/Qme7ss3ARVgxv6rXqVPiikMJ8u2NLgmgszg13pYrDKEoiu.

This approach looks to be endorsed by IPFS. The slight disadvantage is that an IPFS-aware consumer would need to perform a prefix comparison if it wanted to do native IPFS retrieval.

[wesbiggs]

Can this just be a product and business choice? Choosing if you want to use it or ignore it

I wanted to elaborate on this question to propose a somewhat contrarian option I was thinking through after the 27 Oct spec meeting.

What if we don't specify URL methods at all?

Yes, this could affect the ability of downstream services and applications to fetch content. But services and applications are not part of the spec. If a given scheme is useful/popular, support is sure to be added. Consumers of DSNP data might simply choose not to display, or display as broken, content that they don't know how to load. I think this is mostly a theoretical problem, because if a URL method (e.g. "ipfs://") becomes common, then the ecosystem of supporting software will evolve to enable it. My analogy would be to building a web page. The web page might contain links to content that a particular browser is unable (remember "gopher://"?) or unwilling (e.g. "file://") to load. This choice is pushed to the consumer level; it doesn't mean that I as a producer can't put up the web page.

In spec terms, this would be a proposal to remove the mandate for HTTP/HTTPS where present.

[wilwade]

Consider addressing IPFS as HTTPS URLS e.g. https://ipfs.io/ipfs/Qme7ss3ARVgxv6rXqVPiikMJ8u2NLgmgszg13pYrDKEoiu.

This sounds good enough for now.