search

Podcastindex-org / podcast-namespace

A wholistic rss namespace for podcasting
Creative Commons Zero v1.0 Universal
386 stars 116 forks source link

[WIP] Namespace support for IPFS #136

Open dellagustin opened 3 years ago

dellagustin commented 3 years ago

I'm still researching IPFS, but I decided to create this Work In Progress issue as a placeholder.

The general idea is to add support for IPFS content identifiers for the feed itself, and content linked in the feed (podcast website, enclosure, etc...).

Maybe this should be a separate namespace, as most of the use cases are not specific to podcasts, but for content distributed through feeds in general.

Is there already any namespace addressing IPFS in feeds? This could branch into a parallel working stream.

References

Jayman2000 commented 3 years ago

Maybe this should be a separate namespace, as most of the use cases are not specific to podcasts, but for content distributed through feeds in general.

I agree. In fact, I don't think that it should be IPFS specific. I'm a big fan of IPFS, but at some point in the future, we'll probably decide that it makes sense to switch from IPFS to something that's even better. Plus, if someone wants to distribute a podcast over FTP, more power to them!

From my perspective, the poblems with using IPFS in an RSS feed are the same as the problems with using any new protocol in an RSS feed:

  1. According to the RSS spec, an enclosure's URL must be an HTTP URL.
  2. HTTP(S) fallbacks are needed to allow feeds that use the new protocol to work with existing apps.

For enclosures, I found Enhanced "enclosures" support in RSS and ATOM Syndication. I haven't fully read that document yet, but it seems like a feed could have a standard enclosure with an HTTP URL and an enhanced enclosure with an IPFS URL (or any type of URL for that matter).

For the rest of the standard RSS elements, IPFS URLs can already be used, but this would leave users without an HTTP(S) fallback.

At the moment, the Podcast namespace elements reqire HTTPS. One possiblity is to use IPFS HTTP gateways (this could also be done for the standard RSS elements). Podcast apps that don't support IPFS would see them as normal HTTP(S) URLs, and podcast apps that do support IPFS could automatically do a protocol upgrade.

theDanielJLewis commented 3 years ago

The RSS spec is from 2001. I think HTTPS was considered only for banks or sites that took payments back then. So shortsighted, yes. But I think there have been no problems using HTTPS enclosures.

daveajones commented 3 years ago

@Jayman2000 Thank you for researching prior art, and for the thorough comment. Very helpful.

We should get some IPFS devs in here if we can.

daveajones commented 3 years ago

@theDanielJLewis Agreed. HTTPS wasn't even formalized in RFC form until 2000. It was just an afterthought back then.

swschilke commented 3 years ago

Isn't that something like a p2p protocoll?

vv01f commented 3 years ago

a kind of, it's distributed storage. I still think a URI shouldn't be limited to a protocol at all.

swschilke commented 3 years ago

I could agree with this, as long as it makes sense and you can reach the content.

vv01f commented 3 years ago

if there can be multiple storages (maybe with different protocols) that might help. just not sure where to get that started.

as mentioned on image, the picture element allows for different files to be added so it can fit the device better. this would be a comparable idea to make file locations more diverse. there also is the URN to refer to a piece without enforcing the location. and magnet links have shown that kind of power for torrents.

beaudryj commented 3 years ago

Was thinking about IPFS on my drive today and podcast 2.0... Glad to see there is a thread..

I was thinking about this similar to you @vv01f

why not work on adding a

<rss xmlns-ipfs:podcast...> and work on helping Podcast 2.0 Developers build their apps to check for a feed on http.. if NULL then parse for an IPFS source?