Add audio track NIP #1043
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,80 @@ | ||
| NIP-0a | ||
| ====== | ||
|
|
||
| Audio Events | ||
| --------------- | ||
|
|
||
| `draft` `optional` | ||
|
|
||
| This NIP defines several new event kinds representing different types of audio track. These events | ||
| are _parameterized replaceable_ as defined in [NIP-01](./01.md) and deletable per [NIP-09](09.md). | ||
|
|
||
| Unlike a `kind 1` event with audio attached, audio events are intended to be surfaced in an audio-specific context | ||
| rather than in a general micro-blogging context. | ||
|
|
||
| The following kinds are defined by this NIP: | ||
|
|
||
| - `31337` represents a music track | ||
| - `31338` represents a podcast episode | ||
|
|
||
| The following tags are required: | ||
|
|
||
| - `d` is a unique identifier randomly generated by the client. | ||
|
There was a problem hiding this comment. So the publishing client will randomly generate the There was a problem hiding this comment. Yes, it should be random. Meaningful d-tags are an antipattern, since you can't really anticipate when something might change, even guids. |
||
| - `media` is the url of the media. This SHOULD NOT be read, but is required for backwards compatibility reasons. | ||
| - `imeta` is as described in [NIP 92](./92.md). Multiple `imeta` tags MAY be included to provide for different | ||
| use cases (e.g. streaming vs download). | ||
| - `title` is the title of the audio track | ||
| - `subject` is the title of the audio track (deprecated, but required for compatibility) | ||
|
|
||
| The following tags are optional: | ||
|
|
||
| - `i` is an external GUID in the format defined [here](https://github.com/MerryOscar/nips/commit/280eb498e0ac56b8f9356c1b7a88cc8b31579801). | ||
| - `c` is the track's value as defined by a given category. | ||
|
There was a problem hiding this comment. This seems too vague. Also, the category should definitely be the mark: ["c", "genre", "Pop"] not ["c", "Pop", "genre"] <<< this is backwards compared to most other tags :( There was a problem hiding this comment.
what other fields should be expected?
There was a problem hiding this comment. https://soundcharts.com/blog/music-metadata might provide helpful insight on doing this right There was a problem hiding this comment.
This looks backward, but like with NIP 32 the intention is to be able to index the value, rather than the key. It's more important to be able to filter by category values (e.g. Also added a list of categories to the NIP. There was a problem hiding this comment.
That's a good point. Too bad this makes the event.getMatchingTags function in NDK totally useless for parsing these audio events, but I can implement my own tag parsing. Thanks for adding those categories. |
||
| - `website` is an external url to a website related to the track. | ||
| - `duration` is the duration of the audio track, in seconds. | ||
| - `published_at` is a timestamp representing the track's original publish date. | ||
|
|
||
staab marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Expected categories may include (but are not limited to): | ||
|
|
||
| - `genre` | ||
| - `subgenre` | ||
| - `artist` | ||
| - `record_label` | ||
| - `producer` | ||
| - `composer` | ||
| - `album` | ||
| - `track_number` | ||
| - `tracks` | ||
| - `bpm` | ||
| - `year` | ||
|
|
||
| Note that artists, producers, SHOULD be referred to using both a plaintext `c` tag AND a conventional `p` tag when pubkey is available. When doing so, the `p` tag's petname MUST be the same as the `c` tag's value. In this way `c` tags can be used to indicate genre, as well as artist, producer, etc. | ||
|
There was a problem hiding this comment. What are the consequences of a If a pubkey updates their petname, must these audio tracks be replaced with an updated version to reflect the new petname to avoid a mismatch of There was a problem hiding this comment. Petnames are arbitrary, and aren't assigned by the pubkey owner. If they don't match, then clients would have to treat the |
||
|
|
||
| If included, `genre` and `subgenre` SHOULD be based on [this list](https://github.com/wavlake/genre-list). | ||
|
|
||
| `content` SHOULD be summary or description of the audio content. | ||
|
|
||
| Example: | ||
|
|
||
| ```json | ||
| { | ||
| "id": <event_id>, | ||
| "pubkey": <author_pubkey>, | ||
| "created_at": <created_at>, | ||
| "kind": 31337, | ||
| "content": "Chill beats", | ||
| "tags": [ | ||
| ["d", "<id>"], | ||
| ["c", "Pop", "genre"], | ||
| ["c", "EDM", "subgenre"], | ||
| ["c", "Columbia Records", "record_label"], | ||
| ["c", "AC/DC", "artist"], | ||
| ["i", "podcast:item:guid:123", "https://fountain.fm/episode/30uEXC25615Ze2ELjY2p"], | ||
| ["p", "2a07724d42fd8004b5c97b62ba03b6baf3919f9e8211667039987866997e97ad", "wss://my-relay.com", "AC/DC"], | ||
| ["title", "Platinum Robots on the Moon"], | ||
| ["subject", "Platinum Robots on the Moon"], | ||
| ["published_at", "<published_at>"], | ||
| ["imeta", "url https://example.com/my-track.m3u8", "x <hash>", ...] | ||
|
There was a problem hiding this comment. @staab I'd like to include the podcast artwork as well as the individual episode artwork. What would be an example of how to include track artwork and podcast artwork and distinguish meaningfully between them so the client knows which is which? For example, when looking up a podcast episode via Podcastindex API, they provide an image for the episode and the podcast image as well. Sometimes they are the same if the podcast does not have unique artwork per episode, but they can be different. Would we differentiate this using summary or alt from NIP-94? (Seems a little messy) There was a problem hiding this comment. For that matter, how do we indicate streaming vs download using an imeta tag?
There was a problem hiding this comment. If necessary, we could add an attribute to imeta, something like |
||
| ] | ||
| } | ||
| ``` | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Being replaceable events, I assume there is no way to change the pubkey (author) of future events, since replaceable events are dependent on the original event's pubkey.
I'm thinking through the problematic scenario of publishing audio tracks under a general Music Feed pubkey, and later supporting an Artist's ability to self-publish their audio tracks using their own pubkey, if/when they are onboarded to nostr and take custody of their own private key.
I suppose the older audio track event can be deleted when this happens, leaving the new Artist's self-published event? In this case, should the
dtag be re-used or randomly re-generated?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, in that scenario you'd probably want to just delete the events and publish new ones. D tag persistence shouldn't matter because the pubkey would be changing anyhow.