hodlbod

Went to go work on this, and a couple other things: - It looks like that example event is p-tagging its own author, which doesn't make much sense to me....

> I would prefer to have an optional album / track number tag Tracks could show up on multiple albums, with or without the explicit authorization of the event publisher....

I agree it's getting quite messy. The change you suggested still doesn't solve the problem of indexing plain-text `creator`s, and I'm still not sure about overloading `p`. Maybe we should...

> Sorry I don't follow how you can't index plain-text values in the creator tag. Wouldn't this also be true for an l tag? Only single-letter tags get indexed by...

That would be fine, I've just gone over to the position of "names are bad, use meaningless numbers", since we don't know how the NIP will evolve over time (for...

@blastshielddown sorry, I just realized I'm falling into the NIP 32 trap of using labels for actual values. I've updated the NIP to overload the `c` tag similar to how...

> @staab just a thought - if you added a `medium` tag these events would work for podcast episodes too - `["medium", "music / podcast / audiobook"]` We could, but...

Interesting. I've gone through about 4 designs with "claim" before getting here, so it hadn't occurred to me that they could be the same thing. But I think it would...

> Why not use a different dedicated event kind and send these claims with a simple `["EVENT", ...]`? > > I imagine the idea behind using `AUTH` is that these...

I also went down that path, but it's much harder to add support to relays for new verbs than for new events.