nostr-protocol
NIP-10 / NIP-18 conflict on mention/quote
If someone adds an nevent:... to a note that they post, gossip has been adding an 'e' tag with a 'mention' marker according to NIP-10.
NIP-18 now mentions a q tag.
- If we are to switch to NIP-18, someone should change NIP-10 to deprecate the 'mention' marker.
- The
qtag in NIP-18 isn't defined. In particular, while the README.md indicates it can have a relay URL as second value, the NIP-18 doesn't say this.
I'm happy to make this change, I just want to do it right.
@jb55
We also need to define if q can point to any event or if it must be a kind:1. mention is used for other kinds. If q is just for kind:1, we can't remove mention markers.
I would prefer if q could point to anything. There are good reasons to be able to quote non-kind 1's.
+1 to deprecating mention marker.
Another thing that isn't speced is how to quote replaceable events. How about this:
["q", <event-id>, <relay-url>, <event-kind>, <event-address>]
We get both event id (for clients that don't support replaceables) and address to point to the up-to-date replaceable. Also event kind so clients that don't support the event being referenced can skip it without the need to download it.
["q", <event-id>, <relay-url>, <event-kind>, <event-address>]
This means the address is not indexable. It's also a lot of positional arguments. I think it would be better to quote either the event id or the address, depending on whether the event is replaceable (or if you want to cite a given version of the event).
The kind is in the address already, but aside from that I like it.
@fiatjaf It was for regular/non-replaceables. But I was wrong, kind isn't that important. Pubkey, though, would enable a NIP-65 fallback when relay from <relay-url> deletes the event or is offline. Would be great to stuff it in somehow, also for e tags.
This means the address is not indexable [...] better to quote either the event id or the address
@staab agree. Missed this detail.
How about
["q", <event-id>, <relay-url>, <event-kind>]
["Q", <event-address>, <relay-url>]
kind isn't that important
It would add a way for clients to avoid a REQ if they know they don't support that quoted event.
Pubkey, though, would enable a NIP-65 fallback when relay from
Yep, with NIP-65, pubkey is more important than the relay URL, IMO.
It would add a way for clients to avoid a REQ if they know they don't support that quoted event.
This is what k is for
["q", <event-id>, <relay-url>, <event-kind>] ["Q", <event-address>, <relay-url>]
This isn't necessary, because (as you said in a different post just a minute ago) you can tell the difference between an event id and an address.
@vitorpamplona Yep, with NIP-65, pubkey is more important than the relay URL, IMO.
Yeah, relay hints are a pre-nip65 solution to locating events. So I'm gonna throw this here:
["q", <event-id> or <event-address>, <relay-url>, <pubkey-if-a-regular-event>]
...this also: ["e", <event-id>, <relay-url>, <marker>, <pubkey>]
...ping the relay hint creator @fiatjaf and the nip65 one @mikedilger
and watch if something happens.
Yep, with NIP-65, pubkey is more important than the relay URL, IMO.
I've been thinking the same thing. As long as we can find a 10002 for a pubkey (which is not hard with indexers/DHTs, dare I say), we can find a user's posts. Pubkeys rot far slower than relay urls in most cases. One other assumption here is that when a user swtiches relays, the new relay would replicate that user's posts.
One short-term change we could do would be to simply replace relay hints with pubkeys. This wouldn't really break clients because 1. relay urls get validated anyway, the worst that could happen is clients would attempt to open a websocket connection to a pubkey, and 2. most events still don't have relay hints anyway.
I like the idea behind using a pubkey and a relay list to find events, rather than a relay hint. But I have a couple of reservations. Maybe they are no biggie...
First, I don't like breaking things. I agree with @staab that the break wouldn't functionally cause harm, but it feels dirty. Would we do this to "e" tags as well?
Second, I was under the impression that there is a sizeable developer community that doesn't like or use the inbox/outbox model. I wouldn't want to infer that everybody was using it and could therefore use these kind of hints. But maybe from their perspective hints weren't useful anyways (since they use fixed relays)?
Where I wrote in the original note: "I'm happy to make this change, I just want to do it right." I should clarify I meant making the change to my client, not to the NIPs.
it feels dirty
I agree, it does, this might not be the best option.
Would we do this to "e" tags as well?
I would think so, they're basically the same thing.
a sizeable developer community that doesn't like or use the inbox/outbox model
I don't think this would affect them.
I'm confused. Does the word "address" here refer to NIP-19 nevent identifiers?
If so, I would personally object to having them as part of the protocol in the q tag, particularly as the first parameter of the tag (the second element in the array after the tag name).
NIP-01 hex identifiers are more to the core of Nostr and are easier to query for, while NIP-19 identifiers are good for display and for sharing without errors, but they aren't better to deal with programmatically.
An address is the value of an a tag, so something like 34550:<pubkey>:<d-tag>
What @arthurfranca did looks good to me:
["q", <event-id> or <event-address>, <relay-url>, <pubkey-if-a-regular-event>]
["e", <event-id>, <relay-url>, <marker>, <pubkey>]
Considering #1130 was closed, can we agree with the above usage of e and q? @staab @vitorpamplona
I can open a PR if that's the case
Why do NIP-18 reposts use the e tag instead of the q tag?
On Twitter (and maybe other platform) one can see the number of quotes + reposts. If reposts used the q tag, fetching both would be trivial with one request (by requesting events of kind 1 and 6 with the given q tag). Fetching either of those would be just as easy as it currently is.
Semantically also makes a bit more sense, since the q tag would have the same meaning for event 1 and 6.
I suggest that NIP-18 kind 6 reposts should use the q tag instead of the e tag.
Why do NIP-18 reposts use the
etag instead of theqtag?
Reposts doesn't have the same problem as quotes. See #1074 for the reason why the q tag was added.
If reposts used the
qtag, fetching both would be trivial with one request (by requesting events of kind 1 and 6 with the given q tag).
You can use multiple filters:
["REQ", <id>, { "kinds": [1], "#q": [<event-id>] }, { "kinds": [6], "#e": [<event-id>] }]
Yeah, relay hints are a pre-nip65 solution to locating events. So I'm gonna throw this here:
["q", <event-id> or <event-address>, <relay-url>, <pubkey-if-a-regular-event>]
@arthurfranca why is the pubkey contained only for a regular event? Because of included in <event-address>?