Conversation
|
@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:
#1093
Commit Summary
- 1f1ee42
<1f1ee42>
draft NIP-54 podcasts NIP.
File Changes
(1 file <https://github.com/nostr-protocol/nips/pull/1093/files>)
- *A* 54.md
<https://github.com/nostr-protocol/nips/pull/1093/files#diff-99a863eb17d36f246560c9d130451f7e0e8c54bb37e706091eb8f91121e846c0>
(80)
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
<#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 |
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 |
| ["title", "<episode title>"], | ||
| ["image", "<optional episode image>"], | ||
| ["description", "<a brief description>"], | ||
| ["audio", "https://.../", "<optional_media_type>"], // can be specified multiple times |
There was a problem hiding this comment.
I would suggest imeta instead, since it can contain more metadata. Users might want to download a lower-fidelity version of the episode for example.
| ["description", "<a brief description>"], | ||
| ["audio", "https://.../", "<optional_media_type>"], // can be specified multiple times | ||
| ["t", "<optional tag>"], // can be specified multiple times | ||
| ["alt", "<optional NIP-31 short description for displaying in incompatible clients>"] |
There was a problem hiding this comment.
There are some other fields in #1043 that might be worth adding (creator, website, duration, published_at). If they're useful for music publishers, they're probably useful for podcast publishers. But they can be added later too.
In particular, I think an i tag (or whatever) referring to the RSS version's GUID would be useful for linking duplicate content across protocols. Single-letter, because you might want to find an event by guid.
There was a problem hiding this comment.
Might it not be better to add (website, creator) as tags to the Kind 0 event?
There was a problem hiding this comment.
No, because a single pubkey might publish events on behalf of multiple creators (e.g. wavlake). Website should also be more than a domain name, maybe that's the wrong word.
There was a problem hiding this comment.
The reason I made the suggestion is because according to the 'podcast profile' section, a podcast indicates it's info, so I assume each podcast might have their own profile.
There was a problem hiding this comment.
Ideally yes, but wavlake currently publishes everything under the same key. Maybe it would be better to use a separate key for each creator even if you're publishing on behalf of someone else, but we probably shouldn't force that here.
There was a problem hiding this comment.
As for Wavlake, does some form of delegation make sense, ideally in the manner of @alexgleason 's mostr?
There was a problem hiding this comment.
Yeah, I think use of the proxy tag could be appropriate here, although I don't think it needs to be in the spec.
| } | ||
| ``` | ||
|
|
||
| (It's unclear if it's best to use this or a generic kind for commenting on stuff that isn't `kind:1`.) |
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. |
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.
Nothing is impossible. 😉 Just unlikely enough to make it a big waste of time IMO.
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.
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
<#1093 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAWDT4RWOR254INUJAIKLYV6KNFAVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZHA4TSNJVGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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
<#1093 (comment)>:
> +
+Podcast episodes are `kind:54` with some tags:
+
+```jsonc
+{
+ "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
+ "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
+ "kind": 54,
+ "created_at": 1700682555,
+ "tags": [
+ ["title", "<episode title>"],
+ ["image", "<optional episode image>"],
+ ["description", "<a brief description>"],
+ ["audio", "https://.../", "<optional_media_type>"], // can be specified multiple times
+ ["t", "<optional tag>"], // 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
<#1093 (comment)>,
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
<#1093 (comment)>:
> +
+Podcast episodes are `kind:54` with some tags:
+
+```jsonc
+{
+ "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
+ "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
+ "kind": 54,
+ "created_at": 1700682555,
+ "tags": [
+ ["title", "<episode title>"],
+ ["image", "<optional episode image>"],
+ ["description", "<a brief description>"],
+ ["audio", "https://.../", "<optional_media_type>"], // can be specified multiple times
+ ["t", "<optional tag>"], // 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
<#1093 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAWDVPAYRZQHS7T42XFJLYWWWCXAVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMJWGY3DCNBRG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
What is the use case? |
|
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
<#1093 (comment)>,
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
<#1093 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAWDWQLE7ODEXQD4HHW2LYXB725AVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBTG4ZDKNBYGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
It might be a good idea to model this as closely as is reasonable after podcasting 2.0's spec |
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 |
|
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 |
|
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. |
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 |
|
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
<#1093 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAWDSKAHTQXZZA2G4AKN3YY4KDPAVCNFSM6AAAAABD6HOAS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBUGQYTCNZRGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
9 participants
text: https://github.com/nostr-protocol/nips/blob/podcasts/F4.md
These are mostly ideas and if someone has better ones I'm ready to change everything.