Add audio track NIP #1043

staab · 2024-02-12T22:53:47Z

Prior art:

32123 published by wavlake do zap splits wrong and are not published by the artist. Metadata is also json-encoded in the content.
31337 is published by zapstr.live and includes c tags which could be added here, although t probably would suffice. The media tag is missing lots of possible metadata. subject could be a good alternative to title.
1808 isn't replaceable, but includes different urls for download/stream, hash, and waveform.
Create NIP 71 for Video Events #923 re-defines metadata and doesn't support multiple urls for different uses.

This NIP relies on conventions established by NIPs 94 and 92 to support multiple urls and complete metadata simultaneously. It's extremely minimal, and can easily be extended to support:

Categories (NIP 32, t, or c tag)
Text tracks (via NIP 92 imeta)
Albums (kind 30029 lists)
Zap splits (as defined in NIP 52)
File metadata via NIP 94

blastshielddown · 2024-02-12T23:39:31Z

It would be helpful to state the main goal of this NIP. I am totally with you that it would be valuable to center around a standard way of sharing and describing media but without a clear purpose I'm afraid we'll just end up trading opinions about implementation details that might have vastly different objectives.

From my perspective, I would love to be able to publish events so that a user of any client could listen to the song(s) contained in the event and see any relevant metadata. I'm interested to hear if you have other use cases in mind.

A few questions and points of clarification:

Can you please elaborate on wavlake do zap splits wrong?
To the point that events "are not published by the artist", one of our major constraints here is most of our artists do not use Nostr. We would like to change this but it will take some time and will require artists opt-in and secure an nsec (as of now I'm not keen on storing keys for artists and signing on their behalf).
What is the problem with metadata being stored as a json in the event itself?

staab · 2024-02-12T23:57:28Z

Sure, the goal of this nip is just to have a standard that everyone likes for publishing audio tracks. I think this probably requires that it be 1. replaceable, and 2. support multiple urls with different content types. So no current standard works yet. Of course there are slight differences between what exists so far:

Stemstr is doing remixes, and so has e tags to link things together.
Wavlake is re-posting as a feed, as a proxy for the artist, so pubkey != artist in this case
zapstr.live is more straightforward.

But the three use cases have the same core, and should be interoperable. I would use a separate event kind referring to these base events to implement more targeted use cases if the distinction is really needed (probably only necessary for stemstr).

According to NIP 57 zap tags look like this: ["zap", "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2", "wss://nostr.oxtr.dev", "1"] but wavlake publishes ["zap", "zap@www.wavlake.com", "lud16"]. I get sort of why this probably happened, since not all artists have a pubkey, but in that case I'd just leave it off and make sure the profile's lud16 is the correct fallback.
Totally get this. The new format should support that use case. If the artist joins, the events could be deleted and re-posted, or we could add some kind of "redirect" tag that points to the new canonical event.
Nothing necessarily (this is how kind 0 works), but if we're starting from scratch a more idiomatic way to do nostr metadata is in tags. New specs should also try to make event content human-readable so social clients can read the events without special casing rendering for them.

I of course recognize that existing apps probably won't migrate, and some apps probably won't even want to use this spec. The proprietary kinds can be supported if clients want access to that content, but continued development should go off a spec that will actually support everything. We could maybe work off of zapstr's kind 31337, but media would have to be added for backward compatibility.

Edit: I managed to argue myself into hijacking zapstr.live's kind 31337 instead of creating a new kind. The media tag is deprecated, but required for compatibility.

joshr4 · 2024-02-13T02:16:24Z

Love to see the discussion on this. Yeah, Wavlake zaps ought to be updated now that the lud16 zap tag is no longer within spec. Wavlake zaps were implemented almost a year ago when the NIP-57 spec had this:

Client calculates a recipient's lnurl pay request url from the zap tag on the event being zapped (see Appendix G), or by decoding their lud06 or lud16 field on their profile according to the lnurl specifications

When an event includes a zap tag, clients SHOULD calculate the lnurl pay request based on it's value instead of the profile's field.

[ "zap", "pablo@f7z.io", "lud16" ]

staab · 2024-02-13T03:00:51Z

Wavlake zaps were implemented almost a year ago when the NIP-57 spec had this

Very interesting, I didn't remember that. Maybe we should even bring this back, it seems useful for zapping people that don't have nostr accounts, which is what wavlake uses it for I believe. It probably shouldn't have been removed. But that's all orthogonal to this discussion anyhow.

xx.md

pablof7z · 2024-02-13T09:47:13Z

xx.md

+The following tags are optional:
+
+- `website` is an external url to a website related to the track.
+- `creator` is the pubkey (or plain text name) of the track author(s).


I think this should be indexable, probably a p tag and if it's not a pubkey n or something else; the use case of "more songs by this artist" is very normal

please use "something else" instead of n cause the tag is being used to add events to unbounded lists - set to the name of the list - like in this example.

In theory, any event kind, specially replaceable ones, would be able to use the n tag for adding events to these lists.

I've updated this to use creator + p tag (creator so a mark can be added, p tag so that we have a standard format). This is slightly incompatible with zapstr's current p tags, but not enough to break anything (zapstr's role will be interpreted as a relay hint).

sorry about the missing relay hint

is the idea then that each creator will be tagged twice? once as a creator and once as a p?

Right, so you can query by p, but you can still tag people who weren't creators using p tags. Without the creator tag the semantics of p becomes overloaded, so it's necessary to denote the person's role in contributing to the track (and support plaintext creator names, which wouldn't have an accompanying p tag).

fiatjaf · 2024-02-13T12:41:57Z

Looks simple, I like it. But didn't read yet.

staab · 2024-02-13T17:15:28Z

@pablof7z it seems 31337 is used both in NIP 89 and for zapstr.live. Any preference for how to handle that collision? I think probably creating a new kind for this nip would probably be preferable.

pablof7z · 2024-02-13T17:23:21Z

@pablof7z it seems 31337 is used both in NIP 89 and for zapstr.live. Any preference for how to handle that collision? I think probably creating a new kind for this nip would probably be preferable.

NIP 89 doesn't use it, it just mentions it as an example 😅

staab · 2024-02-13T17:30:03Z

NIP 89 doesn't use it, it just mentions it as an example 😅

Oh hey, I didn't read closely enough, that's perfect. Back to using 31337. The one area of incompatibility is the p tag, since zapstr uses an unusual version of it. I've added creator tag with a required p tag so plain text is still supported.

For everyone else's reference, here's an example 31337 from zapstr.live to compare against the new spec:

{
  "id": "4688579eb15107da01fb2fcd43b4e72c32fd0d7f75673b543c8c1e7d0a3fcb74",
  "pubkey": "38b405e49614835c083ae103398c510315c3a0366cfa27115995e79e92451058",
  "created_at": 1693135050,
  "kind": 31337,
  "tags": [
    ["d", "wrh81br2ifcfq11un6ah8"],
    ["p", "38b405e49614835c083ae103398c510315c3a0366cfa27115995e79e92451058", "author"],
    ["c", "Electronic"],
    ["media", "https://nostr.build/av/b057855ba5c38a598575e231a82175801d97a0a013d90c6b5761c05a40fecdf4.mp3", "http"],
    ["cover", "https://i.ytimg.com/vi/MCe2pAIMAzg/maxresdefault.jpg"],
    ["subject", "PilotRedSun - useful"],
    ["zap", ""]
  ],
  "content": "PilotRedSun - useful\n\nhttps://zapstr.live/t/naddr1qq2hwung8qckyu3jd9nxxen3xych2m3kv95rsqsqqvzqqqr6dyntly6j\n\nhttps://i.ytimg.com/vi/MCe2pAIMAzg/maxresdefault.jpg",
  "sig": "e040023e0435b787a64ef9bddff1dd6d22808279ac1e05a090406484aace2734e81f5832df4051f3e53134248f78781fc3b7b40993935146913fa1a63fd39499"
}

xx.md

blastshielddown · 2024-02-15T15:48:23Z

xx.md

+
+The following tags are optional:
+
+- `i` is an external GUID.


What is the distinction between this tag and the d tag? In other words, what are some examples of needing both?

I originally had it in the d tag, but thought it might be useful to be able to change the GUID if a different standard is chosen, or include multiple guids (e.g. music vs podcast if a track qualifies as both).

I recall there being an actual ["d", <value>] (in the deprecated NIP-33), but I don't even see a reference to a d tag in NIP-01.

~~Are d tags used at all? Looks like the d tag value only exists within the a tag, but not as an actual tag itself.~~
I missed the d tag in this PR... 😅

It is only mentioned here in NIP-01:

The a tag, used to refer to a (maybe parameterized) replaceable event
for a parameterized replaceable event: ["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]

for kind n such that 30000 <= n < 40000, events are parameterized replaceable, which means that, for each combination of pubkey, kind and the d tag's first value, only the latest event MUST be stored by relays, older versions MAY be discarded.

so is an i tag basically the new d tag? Or does NIP-01 need to be updated to explicitly define the d tag?

i and d might be the same in some cases, but emerging best practices are to make d tags random UUIDs with no semantic meaning. i is a reference to an external source. In this case, it might even be beneficial to have more than one (multiple d tags would result in undefined behavior).

So if I understand you correctly, it sounds like the d tag is mainly used as a way to identify the content contained in the event, and the i tag(s) can be used to reference related content?

The way I see us using this is to put our internal content identifier guids in the d tag and then use the i tag(s) for any related content. For example, if a podcast contained some songs, the guid for the podcast would go in the d tag and the song guids in the i tags. At this time I don't see any reason to create and use another random identifier for d

So if I understand you correctly, it sounds like the d tag is mainly used as a way to identify the content contained in the event, and the i tag(s) can be used to reference related content?

Yep, d should not be semantic, because anything semantic can change, even if it's not supposed to. The approach you're suggesting makes a similar assumption to NIP 72, that a community's name will never change (the name is contained in the d tag). A podcast GUID is going to be more stable, but the nature of conventions is that they change.

Also, i isn't a new tag, it's described in NIP 39 using very similar semantics, so I think it's a good fit for this.

if a podcast contained some songs, the guid for the podcast would go in the d tag and the song guids in the i tags

Interesting idea, it would be hard to sort out if the i tag is referring to the track itself or some other thing if it can do both. If that's useful, maybe we could use the same pattern I did with creator and p.

Now I wonder if i makes sense here. Based on NIP-39 and the i tag being used for identities, I don't think it makes sense to use this tag for arbitrary id's. I'm still not totally clear on the use case for i

As for referencing other tracks that this piece of content might contain, that sounds like something we could add later as an extension of this NIP. I can see the eventual benefit but trying to get there now might add unnecessary complexity to this proposal.

This is a different context, so it's ok if the meaning of i varies a bit. The sematics of tags are defined by the kind the tag is applied to. We only have so many one-letter tags, better to re-use i than introduce a new one.

blastshielddown · 2024-02-15T15:55:02Z

Not sure what the best practice is for this kind of thing, but since this is intended to be a parameterized replaceable event: would it be helpful to add the a tag to the example so it's explicit what needs to be included? Or maybe there is a better way to reference this requirement without also having also update this doc if NIP-01 changes, that also could work.

From the NIP-01 spec:
["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]

staab · 2024-02-15T16:01:19Z

would it be helpful to add the a tag to the example so it's explicit what needs to be included?

Just so people know what it looks like to a tag the event? I don't think that's necessary, since a tags are pretty well defined and widely used. I did add a reference to NIP 01 though so people know where to look up the term. Let me know if you had something else in mind.

blastshielddown · 2024-02-22T23:30:57Z

If you're up for it @staab we could publish some test events using this draft spec and see how it behaves in practice

staab · 2024-02-23T00:05:23Z

Go for it! I'm hoping to hit this in the next week or two. If you want to use Ainsley's music as a pilot I think that would be awesome.

xx.md

blastshielddown · 2024-03-14T18:56:42Z

I've just published a test event of one of Ainsley's tracks according to this draft spec, event id: 1d8d62cf5f11d6cb6ce9944170753a0fdbf25ec26573ff68b2eecc761323f46d. It should be readable from our relay (relay.wavlake.com)

Let me know how it works @staab , and if you have any questions or feedback.

pablof7z · 2024-03-15T08:59:20Z

I've just published a test event of one of Ainsley's tracks according to this draft spec, event id: 1d8d62cf5f11d6cb6ce9944170753a0fdbf25ec26573ff68b2eecc761323f46d. It should be readable from our relay (relay.wavlake.com)

Let me know how it works @staab , and if you have any questions or feedback.

https://njump.me/nevent1qqspmrtzea03r4ktdn5egstsw5aqlkljtmpx2ulldzewanrkzv3lgmgprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqgs8wk0myn8v2m79w4g82n9g7mfvvqvrmgjn0j8nsyy0mu5rkg9qukqnkg2aj

Few questions:

What's the a tag in this event?
Looks like it's missing the backwards-compatible media tag
Is it possible to have Ainsley Costello's pubkey tagged or you don't have that data mapped locally?

staab · 2024-03-15T15:49:04Z

Mostly repeating what @pablof7z said:

It looks like the a tag is pointing to the same event, which seems nonsensical to me.
I'd like to see at least creator (and maybe zap too) pointing to Ainsley if possible.
media and subject tags should be included for compatibility with zapstr.live
Instead of using artist it would probably be better to do ["creator", <ainsley-pubkey-if-possible-or-name>, "Artist"] following the spec: "creator is the pubkey or plain text name of the track creator. This tag MAY have a mark denoting the creator's role."

blastshielddown · 2024-03-15T16:33:18Z

Thanks @staab and @pablof7z Just pushed up a revised event.

Per your questions/comments:

The a tag follows the spec for parameterized replaceable events. From what I can tell it's accurate but maybe I'm misinterpreting the spec
I'm going to leave the zap tag as-is for now (this approach remains the best way for us to tally zaps for tracks) but will add Ainsley's pubkey to an additional creator tag. This should make it easy for a user to zap the artist directly if they want to. Please note: many of our artists do not have npubs so this should not be an expectation (yet)
Added media, and subject tags while removing artist, these were oversights

Additionally, I think it might be useful to add a version tag. I've been thinking this for a little while now as I've seen these NIPs evolve and introduce breaking changes. This would at least give clients some reliable expectation in case any event kind were to change in some subtle or dramatic way. I added one in this latest test event as an example.

staab · 2024-03-18T22:34:00Z

The a tag follows the spec for parameterized replaceable events. From what I can tell it's accurate but maybe I'm misinterpreting the spec

a tags are intended to point to a different event, not itself. So replies to this event would include the tag, but the event itself wouldn't.

I'm going to leave the zap tag as-is for now

I can't argue with this, but be aware that there probably aren't any clients that support the current format.

Additionally, I think it might be useful to add a version tag.

This is an interesting idea, but I'm inclined to think it's not a good solution. If we're going to support multiple formats, we should just create a new kind. Shifting specs are bad, and while I haven't paid much attention to it in the past I think we should be more careful about changing stuff in incompatible ways going forward.

Phantom-Power-Music-JC · 2024-06-20T18:09:13Z

I'm not seeing anything; this link just takes me to NostrAinsley with nothing in the feed? Also, Wavlake can't publish video so I think I'd need to host it at that paid relay site? I can't remember what you had recommended, pretty sure we let it lapse?

…

________________________________ From: hodlbod ***@***.***> Sent: Thursday, June 20, 2024 1:06 PM To: nostr-protocol/nips ***@***.***> Cc: Phantom-Power-Music ***@***.***>; Manual ***@***.***> Subject: Re: [nostr-protocol/nips] Add audio track NIP (PR #1043) Awesome, I've created a feed that pulls this event (really, anything by Ainsely published by wavlake). You can view it here: https://coracle.social/notes/naddr1qvzqqqrujgpzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3camnwvaz7tmgdajxccn0vshxxmmjv93kcefww3hk7mrn9uqsuamnwvaz7tmwdaejumr0dshsqyfn8yerwd3jxcenxdej8qmnjvfsxcpmdvgf — Reply to this email directly, view it on GitHub<#1043 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BDOV7MT4WUKZMP2Y6YRM3OLZIMKZXAVCNFSM6AAAAABDFQQBW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBRGI2TGMJTG4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

arkin0x · 2024-07-09T19:02:11Z

@staab Thanks for this! We are going to be using it. We'll utilize kind 31338 for podcasts on fanfares.io but they will have some additional tags because our episodes are paywalled:

tags: [
        ["price", "1234", "SATS"]
        ["encrypted", "ChaCha20"]
        // ... and an i tag linking to the podcast:guid:<guid> in addition to the i tag linking to the episode
    ]

arkin0x · 2024-07-09T19:13:27Z

For anyone wondering, I was curious about kind 1808 and after searching on nostr.band found that it's used by stemstr.app for audio stems.

prcolaco

love the simplicity of this proposal, just a few comments...

README.md

51.md

staab · 2024-08-05T16:30:04Z

I split tracks into music vs podcast, @MerryOscar @arkin0x let me know if that messes anything up for you.

0a.md

51.md

README.md

ebrakke · 2024-09-03T12:51:39Z

Might be worth updating NIP-73 with some of the external formats for audio tracks?
e.g. mbid:release:a1812b30-e3ea-4ea7-b7bd-f2f3bfdc08f0 for a music brainz identifier, or spotify:track:2liDEMyPVzDDLXKUnyiznA to find on spotify?
Unsure about the latter, since that would potentially require figuring out the external identifier for many different streaming platforms, but having the format for music brainz would be nice.

staab · 2024-09-03T15:54:45Z

Fewer formats is probably better, especially if they're proprietary ids that are platform-specific (this is partly why the url hint component of nip 73 tags was added). But music brainz seems reasonable to add — would you be willing to open a separate PR for that?

Also, @blastshielddown @MerryOscar is this in production and ready for merge?

0a.md

arkin0x · 2024-09-10T20:32:29Z

0a.md

+    ["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>", ...]


@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)

For that matter, how do we indicate streaming vs download using an imeta tag?

Multiple imeta tags MAY be included to provide for different use cases (e.g. streaming vs download).

If necessary, we could add an attribute to imeta, something like content disposition, e.g. ["imeta", "url https://example.com/cover.png", "x <hash>", "disposition cover"]. For streaming vs download we could do the same thing, but in the near term I think it'll be clear enough which url to use for what, m3u8 is suitable for streaming, mp4 for download for example.

That sounds good to me

arkin0x · 2024-10-04T14:15:56Z

0a.md

+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.


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 :(

genre

subgenre

artist

record_label

producer

what other fields should be expected?

composer

album

track_number

tracks

bpm

year

https://soundcharts.com/blog/music-metadata might provide helpful insight on doing this right

["c", "Pop", "genre"] <<< this is backwards compared to most other tags :(

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. #c: ["Pop"]) than to filter by what categories are defined.

Also added a list of categories to the NIP.

It's more important to be able to filter by category values (e.g. #c: ["Pop"]) than to filter by what categories are defined.

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.

arkin0x · 2024-10-09T13:16:35Z

I'd like to see more clarification around the imeta disposition and other podcasting 2.0 features that are missing from this spec, such as defining timestamps and artwork changing based on those timestamps. I can work on it but I wanted to see what others thought. In it's current form, this NIP doesn't really provide a full equivalent for RSS-based podcasts.

staab · 2024-10-09T15:22:39Z

I think we should merge this, then add additional features in additional NIPs. This is a good core feature set, and is far short of replacing podcasting 2.0, which I'm not sure is quite the same project.

staab · 2024-10-09T15:24:36Z

@blastshielddown @MerryOscar just waiting on a final review from you guys.

joshr4 · 2025-02-09T21:13:05Z

0a.md

+
+The following tags are required:
+
+- `d` is a unique identifier randomly generated by the client.


So the publishing client will randomly generate the d tag? Can the GUID in the optional i tag be used here as the d tag value?

Yes, it should be random. Meaningful d-tags are an antipattern, since you can't really anticipate when something might change, even guids.

joshr4 · 2025-02-09T21:37:19Z

0a.md

+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).


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 d tag be re-used or randomly re-generated?

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.

joshr4 · 2025-02-09T21:42:01Z

0a.md

+- `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.


What are the consequences of a p tag's petname not matching a c tag's value?

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 p and c tags?

Petnames are arbitrary, and aren't assigned by the pubkey owner. If they don't match, then clients would have to treat the c tag as an arbitrary string and the p tag as a normal mention.

staab mentioned this pull request Feb 12, 2024

Create NIP 71 for Video Events #923

Merged

staab requested a review from pablof7z February 13, 2024 00:05

staab mentioned this pull request Feb 13, 2024

Bring back non-pubkey zap tags #1044

Closed

pablof7z reviewed Feb 13, 2024

View reviewed changes

xx.md Outdated Show resolved Hide resolved

pablof7z reviewed Feb 13, 2024

View reviewed changes

staab marked this pull request as ready for review February 13, 2024 17:57

staab requested review from vitorpamplona and pablof7z February 13, 2024 17:57

blastshielddown reviewed Feb 13, 2024

View reviewed changes

xx.md Outdated Show resolved Hide resolved

blastshielddown reviewed Feb 15, 2024

View reviewed changes

staab mentioned this pull request Feb 28, 2024

Nostr integration : Search AntennaPod/AntennaPod#6945

Closed

fiatjaf reviewed Feb 28, 2024

View reviewed changes

xx.md Outdated Show resolved Hide resolved

staab mentioned this pull request Feb 28, 2024

draft NIP-54 for podcast publishing #1093

Draft

prcolaco suggested changes Aug 2, 2024

View reviewed changes

README.md Outdated Show resolved Hide resolved

51.md Outdated Show resolved Hide resolved

staab force-pushed the music branch from 24b8aff to fedc503 Compare August 5, 2024 16:29

arkin0x reviewed Aug 6, 2024

View reviewed changes

0a.md Show resolved Hide resolved

fiatjaf approved these changes Aug 6, 2024

View reviewed changes

prcolaco suggested changes Aug 9, 2024

View reviewed changes

51.md Outdated Show resolved Hide resolved

README.md Outdated Show resolved Hide resolved

staab force-pushed the music branch from fedc503 to 97253e1 Compare August 9, 2024 18:51

staab force-pushed the music branch from 97253e1 to 619c531 Compare August 21, 2024 18:24

This was referenced Aug 28, 2024

convert url.com/noteID to nostr:noteID prior to publication; naddr; npub; nevent nostrability/nostrability#76

Open

WIP: publish music listens as nostr events nostrability/nostrability#79

Open

prcolaco reviewed Sep 6, 2024

View reviewed changes

0a.md Outdated Show resolved Hide resolved

staab force-pushed the music branch from 619c531 to 213ff32 Compare September 9, 2024 17:43

arkin0x reviewed Sep 10, 2024

View reviewed changes

MerryOscar mentioned this pull request Sep 20, 2024

NIP-22 - Comment #1233

Merged

staab mentioned this pull request Sep 26, 2024

NIP-XX Proposal for Reviews Kind #1515

Closed

arkin0x reviewed Oct 4, 2024

View reviewed changes

Jon Staab added 2 commits October 9, 2024 08:23

Add audio track NIP

a693c15

Add a list of categories

d4321f4

staab force-pushed the music branch from c69be5f to d4321f4 Compare October 9, 2024 15:23

joshr4 reviewed Feb 9, 2025

View reviewed changes


		The following tags are required:

		- `d` is a unique identifier randomly generated by the client.

		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).

Add audio track NIP #1043

Are you sure you want to change the base?

Add audio track NIP #1043

Conversation

staab commented Feb 12, 2024 • edited Loading

blastshielddown commented Feb 12, 2024

staab commented Feb 12, 2024 • edited Loading

joshr4 commented Feb 13, 2024

staab commented Feb 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fiatjaf commented Feb 13, 2024

staab commented Feb 13, 2024

pablof7z commented Feb 13, 2024

staab commented Feb 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joshr4 Feb 15, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blastshielddown commented Feb 15, 2024

staab commented Feb 15, 2024

blastshielddown commented Feb 22, 2024

staab commented Feb 23, 2024

blastshielddown commented Mar 14, 2024

pablof7z commented Mar 15, 2024

staab commented Mar 15, 2024

blastshielddown commented Mar 15, 2024

staab commented Mar 18, 2024

Phantom-Power-Music-JC commented Jun 20, 2024 via email

arkin0x commented Jul 9, 2024

arkin0x commented Jul 9, 2024

prcolaco left a comment

Choose a reason for hiding this comment

staab commented Aug 5, 2024

ebrakke commented Sep 3, 2024

staab commented Sep 3, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arkin0x commented Oct 9, 2024

staab commented Oct 9, 2024

staab commented Oct 9, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staab commented Feb 12, 2024 •

edited

Loading

staab commented Feb 12, 2024 •

edited

Loading

staab commented Feb 13, 2024 •

edited

Loading

joshr4 Feb 15, 2024 •

edited

Loading