Open MerryOscar opened 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.
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"]
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?
I personally prefer the namespaced version over marks, positional arguments are evil.
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?
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.
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 👍
@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:
r
tag - [“r”, “podcast:guid:123”]
l
tag - ["l", "123", "podcast:guid"]
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.
@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.
@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 guid
s.
Happy to go with i
tags if that is preferred.
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.
👍
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.
I've created a PR to formalise using the i
tag for external content ids - https://github.com/nostr-protocol/nips/pull/1185
It would be great if nostr apps / clients / services could reliably reference podcasts in nostr events.
This would enable:
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. Theguid
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:Option 2 - NIP-32 Labels:
Option 3 - NIP-48 Proxy Tags:
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 thatpublishers 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 ther
tags?Thanks!