Referencing Podcasts in Nostr Events

MerryOscar commented 1 year ago

It would be great if nostr apps / clients / services could reliably reference podcasts in nostr events.

This would enable:

using nostr for cross-app podcast comments
using nostr for livestream chat that can be surfaced in podcast apps
clipping / highlighting services to reference the source material
nostr clients to open podcast links in the user's app of choice (e.g. fountain link 1-click open in overcast)

Because podcasting is fragmented across many apps and service providers - the only real way to reliably reference a show or episode is to use the <podcast:guid> and the <item> <guid> podcast namespace elements which exist in the rss feed. The guid at both the feed and episode level are supposed to be honoured when podcasters switch hosting providers meaning that any external references to these guids won't break if the podcast moves to a different rss feed url.

From reading through the NIPs I think there are 3 ways to potentially do this:

Option 1 - `r` Tags:

{
  "tags": [

    # podcast feed reference
        [“r”, “podcast:guid:123”]

        # podcast episode reference
        [“r”, “podcast:item:guid:1234”]
  ],
  "content": "This was a great episode!",
  ...
}

Benefits:
- very simple
Drawbacks:
- kind of arbitrary?

Option 2 - NIP-32 Labels:

{
  "kind": 1,
  "tags": [

    # podcast feed label
    ["L", "podcast:guid"],
    ["l", "123", "podcast:guid"],

    # podcast episode label
    ["L", "podcast:item:guid"],
    ["l", "1234", "podcast:item:guid"],

  ],
  "content": "This was a great episode!",
  ...
}

Benefits:
- specifically linked to a defined namespace
Drawbacks:
- not the right use of NIP-32?

Option 3 - NIP-48 Proxy Tags:

{
  "kind": 1,
  "tags": [

    # podcast feed reference
    ["proxy", "podcast:guid:123", "podcast"],

    # podcast episode reference
    ["proxy", "podcast:item:guid:1234", "podcast"],

  ],
  "content": "This was a great episode!",
  ...
}

Benefits:
- specifically linked to a defined namespace
Drawbacks:
- not really referring to a protocol

Feedback / Discussion:

It would be great to get people's thoughts feedback on the right path forward here.

Originally I was drawn to the option of using NIP-32 because the language in the NIP that states both that it could be used for use cases such as content recommendations to reviews and ratings. and that publishers SHOULD ensure they are unambiguous by using a well-defined namespace - it seemed to me that it would be sensible to specifically reference the podcast namespace - but maybe it's fine just to use the r tags?

Thanks!

staab commented 1 year ago

A good heuristic for nip 32 labels is that >1 event should match any given label (i.e., it's not intended to be a key/value store). The downside of the proxy tag is that it's not going to be indexed, and I think searching by guid is something you were hoping for. So door number 3, r seems right to me.

pablof7z commented 1 year ago

I'm with @staab wrt the specific tag usage here, just one comment about it:

If the item already contains a UUID and thus we are not that concerned with collisions, can we skip the podcast prefix -- we could have any number of non-nostr things that we are referencing that could leverage this. Perhaps podcast could just be a marker.

["r", <uuid>, "podcast"]

MerryOscar commented 1 year ago

So @pablof7z with your suggested approach if I wanted to reference both the show and the episode I would include two tags:

["r", <feed_guid>, "podcast"] ["r", <item_guid>, "podcast:item"]

Do you not think setting the markers to podcast:guid and podcast:item:guid are more clear?

staab commented 1 year ago

I personally prefer the namespaced version over marks, positional arguments are evil.

MerryOscar commented 1 year ago

It seems like there is another discussion where NIP-32 labels are being considered for ISO-3166 Country Codes - https://github.com/nostr-protocol/nips/pull/763

I can also imagine them being used in this way for book ISBNs.

My reading of NIP-32 was that it is exactly designed for these kinds of reference tags where there is a recognised namespace.

@fiatjaf I know you are particularly not keen on using NIP-32 labels for this - can you elaborate a bit on why exactly and what you see as the best alternative approach for referencing these kinds of namespaces? Just r tags with the third item as the namespace label?

staab commented 1 year ago

The difference is that country codes work as a "category" that is applicable to many things. A podcast guid isn't the same thing, it's an identity.

An interesting combination of the two would be to use NIP 32's #r namespace: ["l", "podcast:item:guid", "#r"]. But that would really only make sense if you're publishing a 1985 event referencing a comment, as opposed to publishing the comment directly.

MerryOscar commented 1 year ago

The difference is that country codes work as a "category" that is applicable to many things. A podcast guid isn't the same thing, it's an identity.

Aah ok that makes sense 👍

MerryOscar commented 6 months ago

@staab @pablof7z @fiatjaf @alexgleason @v0l it would be great to get your latest thoughts on this issue - it seems like a simple request to include a way to reference an external id from a different protocol. Just as a reminder the options are:

generic reference with r tag - [“r”, “podcast:guid:123”]
NIP-32 l tag - ["l", "123", "podcast:guid"]
NIP-48 proxy tag - ["proxy", "podcast:guid:123", "podcast"]

If there is another option please suggest.

I really would like to move to implementing one of these options as many in the podcast community are moving towards activitypub for cross-app podcast comments and I think that would be a shame as (bridging aside) I believe nostr has so much more potential and is a perfect fit to power the social layer of podcasting.

I have discussed with @blastshielddown from wavlake about using the r tag as that seemed to be the preferred option in the comments above - and we're both happy to go with that - but it would be great to get everyone's latest thoughts on what is better before we move forward.

staab commented 6 months ago

@MerryOscar I'm working on a very similar format with the wavlake guys for music. It could easily be re-used for podcasts, or adapted into a new NIP. I think we've solved a lot of these issues there. Regarding your specific question, we're currently going with i, which is basically the same as the r option here.

MerryOscar commented 6 months ago

@staab thanks the audio track NIP would definitely work for podcast episodes too - especially with a medium tag.

Even with that NIP though, what I'm really trying to get at with this 'references' concept is how to reference content that is not yet on nostr and may never be. Since podcast guids exist there is an easy way to do this. Same with books via ISBNs. Even if someone were to index all podcast episodes using the audio track NIP - it would still be useful for clients to be able to query them based on the existing guids.

Happy to go with i tags if that is preferred.

erskingardner commented 6 months ago

I think it makes sense to have the format here mimic what's going on with other audio files so whether it's an r tag or an i doesn't matter much, as long as they match.

having two r or i tags and using a third positional marker for namespacing to say whether the UUID is for a show or an episode seems like a good approach to me as well.

👍

staab commented 6 months ago

Just updated #1043 to include a separate kind for podcast episodes, @MerryOscar give that a gander and let me know if there's anything missing, or whether podcasting is sufficiently divergent from music to merit its own separate NIP.

MerryOscar commented 6 months ago

I've created a PR to formalise using the i tag for external content ids - https://github.com/nostr-protocol/nips/pull/1185

nostr-protocol / nips