Proposal: Nostr NIP-32 Podcast Labels

[MerryOscar]

Summary:

This is a proposal to use Nostr NIP-32 Labels as the basis for linking nostr events to podcasts reliably using the existing podcast:guid and podcast:item:guid as the label namespaces - thereby creating a cross-app commenting system for podcasts that not only works but also integrates with the wider nostr ecosystem.

---

Motivation:

Nostr is a protocol for decentralised social media and app data sharing that could be incredibly beneficial to Podcasting.

Podcasting is uniquely suitable for using nostr because it is highly fragmented with a long-tail of apps and hosting providers. This fragmentation has meant that up until now there have not been social podcasting features that have ever really worked because the conversation is trapped in one app which probably has only a small portion of the show's audience.

This proposal would deliver the following benefits:

• Cross-App Comments - nostr kind 1 notes can allow users of different podcast apps to view and reply to each others comments
• Distributed Payment Stats - boost + streaming payments from different apps can be aggregated together and also verified using trusted payment provider signatures

Ultimately this will lead to better discovery for podcasters because boosts / comments made in Podcasting 2.0 apps will not only travel from one app to another - but they will also travel out into the wider nostr ecosystem.

This solution has the added benefit that there would be no need for podcasters to enable anything in their feeds - it would work out of the box if apps chose to implement it - bypassing the adoption issues we've faced with other tags.

---

Goals:

• users of different podcast apps should be able to view and reply to each others comments
• we want comments sent from Fountain and other Podcasting 2.0 apps to show up natively on other nostr clients to improve discovery and avoid the 'post twice on different platforms' problem
• ideally the payment value and the action label can be optionally rendered by podcast apps - meaning the payment metadata should be in the nostr event tags

---

Proposal: NIP-32 Podcast Labels:

NIP-32 is part of the nostr spec that allows labelling notes according to some defined namespace. It introduces a new tag L which denotes a label namespace, and a new tag l which denotes a label.

We can use these label tags to link nostr events to podcasts - either at the feed level or the item level.

All that is required is agreeing on the label namespace for podcasting - luckily we have the Podcast Namespace which includes the <podcast:guid> and item <guid> elements which would be perfect for this.

Therefore I propose we formalise the format of the NIP-32 Podcasting Namespace as follows:

• podcast:guid - label that references the feed guid
• podcast:item:guid - label that references the item guid
• podcast:payment - label that references a payment to a podcast
• podcast:payment:verification - label that references a payment verification by some 'semi-trusted' provider (PodcastIndex, Fountain, Alby, Curiocaster, Podverse, Wavlake, RSS.com etc)

---

Examples:

A regular podcast episode comment represented by a nostr kind 1 note with the podcast:guid and podcast:item:guid namespace labels:

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

	# podcast feed label
	["L", "podcast:guid"],
	["l", "917393e3-1b1e-5cef-ace4-edaa54e1f810", "podcast:guid"],

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

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

An episode boost comment represented by a nostr kind 1 note with the podcast:guid, podcast:item:guid, podcast:payment, and podcast:payment:verification namespace labels:

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

	# podcast feed label
	["L", "podcast:guid"],
	["l", "917393e3-1b1e-5cef-ace4-edaa54e1f810", "podcast:guid"],

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

	# podcast payment label
	["L", "podcast:payment"],
	["l", "BTC:0.0001", "podcast:payment", "{BLIP_10_METADATA}"]
	
	# podcast payment verification label
	["L", "podcast:payment:verification"],
	["l", "{verifier_pubkey}:{signature of podcast:payment label + payer_pubkey + created_at}", "podcast:payment:verification" ]

  ],
  "content": "This was a great episode - have 10,000 sats!",
  ...
}

The 4th item in the podcast:payment label tag is used for additional metadata and could include the BLIP_10_METADATA as a json string - this way the tags are extensible as the value spec expands to include other metadata.

---

Replies:

Replies to either boosts or comments would be handled according the standard nostr spec NIP-10 - On "e" and "p" tags in Text Events (kind 1) where the parent comment event id is included as an e tag:

{
  "kind": 1,
    "tags": [
      ["e", "<parent-event-id>", "<relay-url (optional)>", "reply"], // reference to parent comment
      ["e", "<route-event-id>", "<relay-url (optional)>", "route"] // reference to route comment in thread
    ]
    ...
 }

---

Benefits of Using NIP-32 Labels:

• comments on episodes should show up in generic nostr clients - great for discovery and also avoids the 'post twice, once on each platform' problem that nostr is supposed to solve
• allows podcast apps to reliably query events related to a show / episode - importantly this will work with any current or future event kind so would also work with any liveItem chat rooms that may be built on nostr (👀)
• we don't need to change the nostr protocol or get other nostr clients to adopt anything new - everything just works

---

Why Kind 1 Events?

Using kind 1 events for podcast comments as opposed to a new kind specifically for this use case is fundamentally important because:

• The comments are rendered by default in other nostr clients
• Podcast comments are no different from normal posts and so won't be contextually confusing when viewed in generic nostr client feeds - especially if the episode links are included in the content field for context
• We solve the 'post twice on different platforms' problem where people leave a podcast comment in a podcast app and then re-type the exact same thing on social media. If we don't solve this problem there's not much point using nostr as the conversation will remain fragmented

---

How Will Apps Implement?

There are multiple options for podcast clients to support this:

• podcast clients become nostr clients themselves - Fountain is planning this
• web clients can use NIP-07: window.nostr capability for web browsers - Alby already supports NIP-07 so these would work out of the box on web for everyone that uses Alby: (Curiocaster Podverse Web, Podfans, etc) - the extra cool thing about this is any site that integrates NIP-07 could display comments and allow commenting (PodcastIndex site, PodNews, Hosting Companies, Podcast Page Builders etc.) - users can just use Alby to comment!
• mobile apps that don't want to deal with keys can use signer api services which I'm sure are coming very soon

---

Steps to Move Forward:

All we really need to do is agree the label namespace formats:

• podcast:guid
• podcast:item:guid
• podcast:payment
• podcast:payment:verification

Then we can add these to maybe the existing podcast:guid doc in the namespace and we'd be off to the races!

---

Supporters:

I thought it might be useful to add a list of supporters of this proposal - I will update as and when people comment with thoughts / feedback / support:

• Fountain ✅ - supports the proposal and will implement
• Alby ✅ - supports the proposal
• Wavlake ✅ - supports the proposal
• Podfans ✅ - supports the proposal
• ...

[samsethi]

Pls add Podfans. We already store the users npub so very easy for us to extend with this NIP. The X.api is broken so we can't use it reliably.

[MerryOscar]

Done - great to hear @samsethi!

[blastshielddown]

Any thoughts on including the r tag as an optional but recommended tag for these kinds of events? In addition to the unique identifiers, adding a reference url in the r tag could be a convenient way to provide a standard link to source material.

[MerryOscar]

yep I think makes a lot of sense

[dhk2]

I'm curious how this can work with the nostr support in @valcanobacon's boostbot. If Ditto works out it could easily bridge the existing ActivityPub cross-app comments.

[daveajones]

How can Alecks’s JPT proposal fit in with this for payment verification? Any thoughts?

#490

[blastshielddown]

Seems related, adding for reference: https://primal.net/e/note1zkdsjjffjtlc5nrnyjvr9whz32cy0xy92ymqxhrswsuw2dneq99sy38hse

https://www.ontolo.social/