nips
nips copied to clipboard
nostr-protocol
draft NIP-54 for podcast publishing
text: https://github.com/nostr-protocol/nips/blob/podcasts/54.md
These are mostly ideas and if someone has better ones I'm ready to change everything.
It was also pointed out to me by @staab that it could be better to just keep using RSS but add Nostr for social interaction on top, which is a fine first step for me, but it only gives us part of the benefits.
@daveajones is building ActivityPub podcast integration with Lightning. Nostr integration would be more seamless with Lightning.
There's a bunch of movement in the Podcast 2.0 space and I think it would be a mistake to try and support a bunch of it, but a transcript tag might be useful for a number of reasons including being able to index for better search results given the advantages of decoupling the episodes from the larger feed
On Wed, Feb 28, 2024 at 10:24 AM fiatjaf_ @.***> wrote:
You can view, comment on, or merge this pull request online at:
https://github.com/nostr-protocol/nips/pull/1093 Commit Summary
- 1f1ee42 https://github.com/nostr-protocol/nips/pull/1093/commits/1f1ee425b7c347c8e16cd7cde049c47d936c5619 draft NIP-54 podcasts NIP.
File Changes
(1 file https://github.com/nostr-protocol/nips/pull/1093/files)
Patch Links:
- https://github.com/nostr-protocol/nips/pull/1093.patch
- https://github.com/nostr-protocol/nips/pull/1093.diff
— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/pull/1093, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAWDXCQSDDE2D57C2XZK3YV5D2TAVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGE2TSMRSGQYTIMY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Please don't try to replace RSS. It's been tried many times and always fails. The latest example was JSONfeed. It's like trying to replace HTML. Big waste of labor.
Better to do what @fiatjaf mentioned and keep RSS but utilize the <podcast:socialInteract> and/or <podcast:chat> tags to hook into Nostr. Both are purposely flexible enough to accommodate any social protocol. There is a Nostr example in the <podcast:chat> documentation already.
Please don't try to replace RSS.
I agree with this 120% . But not sure it's a fair description of what is being proposed. Relays do a lot more than accommodate social interaction IMHO
It's been tried many times and always fails.
Can you give me some examples besides JSONFeed?
Maybe because all of the attempts didn't offer anything new, but were just syntax sugar?
In any case, Nostr is already trying to replace Twitter, Facebook, Wikipedia, blogs, Instagram, YouTube, Twitch. Is RSS so much more impossible than this?
Also, Atom has successfully replaced RSS (for a percent of the sites) in one of the most stupid moves of the entire internet: they literally made the exact same thing but with different names and got away with it and now every client has to support the two protocols forever, amazing.
The creation of Atom is only comparable to the creation of Deno: the thing that was invented by creator of Node to fix all the problems associated with Node, but after many years ended up in the exact same place as that.
Can you give me some examples besides JSONFeed?
XMPP was going to kill RSS. Then AMP. But, what I meant was mostly API based services. Twitter is an example of an "RSS killer" because of their API back when it was fully open. Also YouTube. Spotify aimed to "move beyond the limitations" of RSS podcasting and have now given up that endeavor and re-embraced RSS by buying Megaphone. There is also an RSS 3.0 spec that never went anywhere.
Is RSS so much more impossible than this?
Nothing is impossible. 😉 Just unlikely enough to make it a big waste of time IMO.
Also, Atom has successfully replaced RSS...
RSS and ATOM are interchangeable in my mind. I use the term "RSS" as a catch-all to mean any static uri based XML feed of published items. I agree that ATOM was dumb.
Maybe because all of the attempts didn't offer anything new, but were just syntax sugar?
There is a $2 billion dollar podcasting industry built on the creation AND consumption of RSS feeds with years of know-how on both sides. It's not a question of technical merit. It's a question of inertia. RSS podcasting is a 2000 pound flywheel. It's just not going to change, because after all of the hours of dev work to switch to something new, you'll end up back with essentially the same thing at base level: publishing audio urls to a podcast app.
It took us 3 years of advocacy to get people to build new podcast features on top of the existing RSS. Getting them to replace RSS entirely would be a feat of evangelism to rival the New Testament. If you can pull it off, you'll have my eternal respect. But, I've been in the trenches of this for a long time now and I think there are bigger fish to fry. Sometimes the best format just doesn't win. HTTP, SMTP, etc. None of them are ideal, but they are all heavy flywheel's.
I don't see the potential here as competing with RSS, more like getting your existing podcasts into a new platform. You wouldn't maintain anything extra besides setting it up the way you set it up for Apple, e.g.
Once the data is rolling into Apple, or anyone that creates a directory of podcasts, they don't simply store the XML, they index it and make it available to their platform in the best way.
In Nostr that's events on relays. It's opt in anyway.
On Wed, Feb 28, 2024 at 3:53 PM Dave Jones @.***> wrote:
Can you give me some examples besides JSONFeed?
XMPP was going to kill RSS. Then AMP. But, what I meant was mostly API based services. Twitter is an example of an "RSS killer" because of their API back when it was fully open. Also YouTube. Spotify aimed to "move beyond the limitations" of RSS podcasting and have now given up that endeavor and re-embraced RSS by buying Megaphone. There is also an RSS 3.0 spec that never went anywhere.
Is RSS so much more impossible than this?
Nothing is impossible. 😉 Just unlikely enough to make it a big waste of time IMO.
Also, Atom has successfully replaced RSS...
RSS and ATOM are interchangeable in my mind. I use the term "RSS" as a catch-all to mean any static uri based XML feed of published items. I agree that ATOM was dumb.
Maybe because all of the attempts didn't offer anything new, but were just syntax sugar?
There is a $2 billion dollar podcasting industry built on the creation AND consumption of RSS feeds with years of know-how on both sides. It's not a question of technical merit. It's a question of inertia. RSS podcasting is a 2000 pound flywheel. It's just not going to change, because after all of the hours of dev work to switch to something new, you'll end up back with essentially the same thing at base level: publishing audio urls to a podcast app.
It took us 3 years of advocacy to get people to build new podcast features on top of the existing RSS. Getting them to replace RSS entirely would be a feat of evangelism to rival the New Testament. If you can pull it off, you'll have my eternal respect. But, I've been in the trenches of this for a long time now and I think there are bigger fish to fry. Sometimes the best format just doesn't win. HTTP, SMTP, etc. None of them are ideal, but they are all heavy flywheel's.
— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/pull/1093#issuecomment-1969899552, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAWDT4RWOR254INUJAIKLYV6KNFAVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZHA4TSNJVGI . You are receiving this because you commented.Message ID: @.***>
Getting them to replace RSS entirely would be a feat of evangelism to rival the New Testament.
I must say I laughed a lot from this line here, ahahah
I don't know, I agree with everything you said but I still think we can pull it off eventually, let's stop here for a while and give it more time and thought. I agree there are other areas that could be prioritized first and RSS is already good enough.
One of things ATOM did do that the RSS (2.0) spec didn't was move the channel info into the feed item, so that an item could move away from feed and still have all channel info inside it.
Eventually RSS 2.0 could also do that by adding the ATOM namespace.
Nostr events are more loosely coupled than an RSS feed.
The point being that there is great advantage to getting the item or event with all the channel info in it, so they can be aggregated into multi-source feeds without having to do extra queries back to the channel (profile here) to get that info
On Thu, Feb 29, 2024 at 2:15 PM KotlinGeekDev @.***> wrote:
@.**** commented on this pull request.
In 54.md https://github.com/nostr-protocol/nips/pull/1093#discussion_r1508080065:
+Podcast episodes are
kind:54with some tags: + +```jsonc +{
- "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
- "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
- "kind": 54,
- "created_at": 1700682555,
- "tags": [
- ["title", "
"], - ["image", "
"], - ["description", ""],
- ["audio", "https://.../", "<optional_media_type>"], // can be specified multiple times
- ["t", "
"], // can be specified multiple times - ["alt", "<optional NIP-31 short description for displaying in incompatible clients>"]
As for Wavlake, could some form of delegation work, ideally in the manner of @alexgleason https://github.com/alexgleason 's mostr?
— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/pull/1093#discussion_r1508080065, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAWDRN2XGYXZB2WNYFQ6DYV5633AVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMBZGY4DQNZSGA . You are receiving this because you commented.Message ID: @.***>
Discussion about whether trying to replace RSS is a good idea or not aside, I do have a use case where I'd like to make a feed of URLs.
My initial thinking was to use lists and just replace the list every time
there was a new entry, but if this was more generic or I could
alternatively use a ["type", "feed"] that might be better than a
replaceable list, or not
On Tue, Mar 5, 2024 at 6:46 AM KotlinGeekDev @.***> wrote:
@.**** commented on this pull request.
In 54.md https://github.com/nostr-protocol/nips/pull/1093#discussion_r1512688177:
+Podcast episodes are
kind:54with some tags: + +```jsonc +{
- "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
- "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
- "kind": 54,
- "created_at": 1700682555,
- "tags": [
- ["title", "
"], - ["image", "
"], - ["description", ""],
- ["audio", "https://.../", "<optional_media_type>"], // can be specified multiple times
- ["t", "
"], // can be specified multiple times - ["alt", "<optional NIP-31 short description for displaying in incompatible clients>"]
Got it.
— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/pull/1093#discussion_r1512688177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAWDVPAYRZQHS7T42XFJLYWWWCXAVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMJWGY3DCNBRG4 . You are receiving this because you commented.Message ID: @.***>
A service that monitors your timeline and creates a digest of articles that your followers link to. Nuzzel for Nostr. It's a port of something I built for Mastodon, but since we are on Nostr, it seems a better fit that the results would be an event or group of events, rather than an email. Rabble also suggested a long form content event which also has advantages. I'd like to support all options
On Thu, Mar 7, 2024 at 5:23 AM fiatjaf_ @.***> wrote:
What is the use case?
— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/pull/1093#issuecomment-1983199881, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAWDTQ77G4XKNRBOYZ2D3YXA52PAVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBTGE4TSOBYGE . You are receiving this because you commented.Message ID: @.***>
Digests of articles people link to? I don't quite get it. Why not just reply to the notes that link to articles with a digest of these articles?
No, like all the articles shared by your friends (and perhaps friends of friends) in a nice newsletter type format. See Nuzzel for prior art https://daringfireball.net/linked/2021/05/05/nuzzel
On Thu, Mar 7, 2024 at 10:13 AM fiatjaf_ @.***> wrote:
Digests of articles people link to? I don't quite get it. Why not just reply to the notes that link to articles with a digest of these articles?
— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/pull/1093#issuecomment-1983725483, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAWDWQLE7ODEXQD4HHW2LYXB725AVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBTG4ZDKNBYGM . You are receiving this because you commented.Message ID: @.***>
it could be better to just keep using RSS but add Nostr for social interaction on top
This seems simpler.
A thought: NIP-84 (or "highlights") could be extended for a use case like this, when you want to reference something that has a relatively stable URI that is not a Nostr event but you want to enable interactions around it. For podcasts, you could point the r tag to the feed URL (or better yet, include the podcast UUID per the Podcasting 2.0 spec in a d or i tag). You also could include references to the episode and more granular details like timestamp in supplemental tags, to point clients to exactly the spot a user wants to share. The NIP-84 spec already makes some references to media so this would follow its original intent.
no matter what happens with this proposal or any other proposal that attempts to link nostr to rss - the simplest primitive that we should try and agree on is how to reliably reference podcasts in nostr events.
Because there are so many existing nips that are relevant to podcasts (nip01 notes, nip53 live events, nip38 statuses, nip58 badges, nip84 highlights) I think the easiest way to do this is with tags.
I outlined some options for this last year - and it seems the preferred approach was to use r tags to reference podcasts via the existing guids that are defined in the rss feed:
"tags": [
# podcast feed reference
["r", "podcast:guid:123"]
# podcast episode reference
["r", "podcast:item:guid:1234"]
]
I just skimmed a bit of this very funny discussion, here are my two sats:
comparing previous attempts to replace RSS for podcast distriibution with replacing it with nostr is not a good comparison:
Replacing with nostr is not simply a schema modification that might be simpler/saner/faster/more-extensible than RSS 2.0. A debatable marginal improvement over RSS.
Podcasts on nostr is not about the schema, is about the social graph and network effects of all other use cases. The schema changing is a mere byproduct but leveraging the rest of your social graph is an orders-of-magnitude improvement over RSS.
Publishing podcasting data as nostr events will lead to apps that fully leverage nostr instead of shoehorning some nostr coating on top of existing implementations.
All the use cases we're rebuilding on nostr seem like a Quixotesk pursuit at first, but that's the nature of overtaking any network effect.
@pablof7z
Podcasts on nostr is not about the schema, is about the social graph and network effects of all other use cases.
You still get the social graph and network effects if you use nostr as the social layer but keep rss as the hosting mechanism. If interacting with podcasts on nostr requires the audio to be hosted on nostr - then you don't get any network effects because 90% of the content is not hosted on nostr
If social features in a nostr podcast app only work for <10% of the shows then it's a terrible experience for users
If you can allow nostr social features to apply to any existing podcasts then you can provide a great experience that doesn't require any buy-in from the existing podcast industry - it just works out of the box
There are 400m+ podcast listeners that are using podcast apps with zero social features and nostr is a great solution for them - but if using these features only applies to a tiny subset of what they listen to then it's going to be pretty hard to get them to use it
We use r tags for linking to websites so why not use them to link to podcasts which are just xml websites
We use r tags for linking to websites so why not use them to link to podcasts which are just xml websites
What you you be referencing once the episode is no longer in the feed? I recognize it's a guid but for it to be meaningful you need the surrounding context and metadata, which is basically duplication of the RSS no?
On Mon, Mar 18, 2024 at 12:39 PM Oscar Merry @.***> wrote:
@pablof7z https://github.com/pablof7z
Podcasts on nostr is not about the schema, is about the social graph and network effects of all other use cases.
You still get the social graph and network effects if you use nostr as the social layer but keep rss as the hosting mechanism. If interacting with podcasts on nostr requires the audio to be hosted on nostr - then you don't get any network effects because 90% of the content is not hosted on nostr
If social features in a nostr podcast app only work for <10% of the shows then it's a terrible experience for users
If you can allow nostr social features to apply to any existing podcasts then you can provide a great experience that doesn't require any buy-in from the existing podcast industry - it just works out of the box
There are 400m+ podcast listeners that are using podcast apps with zero social features and nostr is a great solution for them - but if using these features only applies to a tiny subset of what they listen to then it's going to be pretty hard to get them to use it
We use r tags for linking to websites so why not use them to link to podcasts which are just xml websites
— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/pull/1093#issuecomment-2004411711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAWDSKAHTQXZZA2G4AKN3YY4KDPAVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBUGQYTCNZRGE . You are receiving this because you commented.Message ID: @.***>