Clarify quote reposts

[staab]

This change is fairly opinionated in terms of dictating best practices. I'm also not sure if address support is desired/implemented anywhere, so I'm happy to take that out if appropriate.

The diff is kind of hard to read because I moved the quote reposts section to the bottom of the NIP for better readability.

[mikedilger]

I agree that the q needs to be explained.

Allowing an address on the same tag is a bit risky (we didn't do that with 'e' we created 'a' instead).

I sure wish references just worked simply and worked everywhere (e.g. instead of the id being a hash it was a construction that could be replaced, and the hash was just a hash). But that is a pipedream, don't get distracted by my musing.

[mikedilger]

Also, I'm not sure why we have quote reposts at all. I have no idea when my user intends to send a kind-6 repost or a kind-1 quote repost or a kind-1 mention. So gossip only generates kind-6 reposts and kind-1 mentions.

[pablof7z]

Agreed. I think we should make it explicit to say that a quote should also have the k tag in addition to the q tag.

[staab]

Also, I'm not sure why we have quote reposts at all. I have no idea when my user intends to send a kind-6 repost or a kind-1 quote repost or a kind-1 mention. So gossip only generates kind-6 reposts and kind-1 mentions.

IMO kind 1 quote reposts are the same as kind 1 mentions semantically. e tags with a mention mark are evil when they're not in the reply tree.

[1l0]

I think the "Quote repost" is unnecessary. Only the quotes should be there. Also NIP-10 should be deprecated.

recommend k tag for quotes

If you have multiple q tags (though I'm not sure if this is allowed), how do you handle the k tag?

[dluvian]

I think the definition of q is misplaced under this nip, but I also don't know where else to put it. Maybe nip24. Here's the comment I made regarding this issue:

I like the q tag. I forgot that it exists. Going over the main README, I find nothing that describes quotes/references. It's kind of hidden under the Reposts nip. (#1233 (comment))

[dluvian]

If you have multiple q tags (though I'm not sure if this is allowed), how do you handle the k tag?

Get rid of the k tag. Is there any case you want to query the kind of a referenced event?
It should be a requirement to encode the kind number in the nevent. note is assumed to be kind 1 and naddr always has a kind.

[1l0]

I think the definition of q is misplaced under this nip, but I also don't know where else to put it.

I suggest merging into NIP-27.

[AsaiToshiya]

I'm also not sure if address support is desired/implemented anywhere

For this reason, I feel there is no need to support the addressable for now.

[staab]

Ok, I've dropped the stuff about k and address . This is now a pretty trivial change. I do think that based on the comments, quote reposts should be moved out of this NIP, and NIPs 10, 24, and 27 should be combined and heavily edited for clarity.

[arthurfranca]

NIP-21, in fact

[AsaiToshiya]

Yes, I know😅

[vitorpamplona]

How are we thinking about solving the address issue? I am one that needs to quote the address, not just the event id.

It's weird to write a nostr:naddr in the .content and then force it to a given version in the q tag. If the user wanted to quote a given replaceable version he/she would write a nostr:nevent but that's not what's happening.

[mikedilger]

Also, I'm not sure why we have quote reposts at all. I have no idea when my user intends to send a kind-6 repost or a kind-1 quote repost or a kind-1 mention. So gossip only generates kind-6 reposts and kind-1 mentions.

I was wrong. Gossip is using q tags, not e tags with mention markers.

Also, +1 on this PR as it currently is.

[staab]

It's weird to write a nostr:naddr in the .content and then force it to a given version in the q tag.

I agree. My vote would be to have a different version of the q tag for addresses (since they don't need the pubkey hint). This may break some clients, but it's really just due to forward incompatibility.