nips
nips copied to clipboard
nostr-protocol
Update Readme for NIP 20
I added what we discussed in a little more details to the ReadMe. Please take a look, and update however you see fit.
I don't know how helpful this is, but would it be beneficial to add a standard for nested comments?
Afaict this would allow for nested comments, ie threads, where POST TYPE in <MY WEBSITE NAME> <POST TYPE> <POST ID> is perhaps a Reply, but without standardizing this it might leave things a little too open to interpretation given how common/desirable threads are.
Fiatjaf asked me to review and this is the only deficiency for an SN use case that stands out. It's also apparently doable without such a change though.
Note: I'm unfamiliar how NIPs handle cases like these typically and its probably best to conform to the level of under/over specifying of use cases that is typical.
On Thu, Aug 11, 2022 at 01:13:05PM -0700, Keyan wrote:
I don't know how helpful this is, but would it be beneficial to add a standard for nested comments?
Afaict this would allow for nested comments, ie threads, where
POST TYPEin<MY WEBSITE NAME> <POST TYPE> <POST ID>is perhaps aReply, but without standardizing this it might leave things a little too open to interpretation given how common/desirable threads are.
nested comments/threads is just nip10. Any threaded discussion note type should just implement that.
On Thu, Aug 11, 2022 at 08:28:23PM -0700, William Casarin wrote:
On Thu, Aug 11, 2022 at 01:13:05PM -0700, Keyan wrote:
I don't know how helpful this is, but would it be beneficial to add a standard for nested comments?
Afaict this would allow for nested comments, ie threads, where
POST TYPEin<MY WEBSITE NAME> <POST TYPE> <POST ID>is perhaps aReply, but without standardizing this it might leave things a little too open to interpretation given how common/desirable threads are.nested comments/threads is just nip10. Any threaded discussion note type should just implement that.
After taking a look at nip20 it looks like the r tag could be
considered the root tag, so it's a bit simpler than nip10. Each reply
just needs to include the r tag + e tag of the note you're replying to.
It's still probably a good idea to add a reply marker to the e tag
though.
Cheers,
You mean to use the
subjectfield to put the identifier that is currently suggested for thertag??
["r", "github.com/nostr-protocol/nips/pull/19"] ["subject", "Github Pull_Request 19"]
Okay.
Btw, the subject field can be included in the query filter, right??
meaning I can construct a query like:
sub({ cb: ()=>{...} filter: [ {"subject": "..."} ] })
meaning I can construct a query like:
sub({ cb: ()=>{...} filter: [ {"subject": "..."} ] })
Maybe I did that wrong, but when I tried using this, it seemed that the subject field isn't used when filtering the events returned currently.
Maybe I did that wrong, but when I tried using this, it seemed that the
subjectfield isn't used when filtering the events returned currently.
you need to add "#" on the query, so use filter: {"#subject": "..."}
Okay. Btw, the
subjectfield can be included in the query filter, right?? meaning I can construct a query like:sub({ cb: ()=>{...} filter: [ {"subject": "..."} ] })
sure but usually you wouldn't want to search on a subject, these are more useful for things like hashtags #t and urls #r not arbitrary text content. what's your use case here?
what's your use case here?
As I mentioned in the NIP, the reason why I'm suggesting the use of something more "stable\constant" such as this, is because the URLs can change. And although this might not be something that happens very commonly or frequently, but it happens. And if we are only depending on the url tag to query these comments, then that means we will all the comments if the URL change.
But if we manage to generate/extract a unique identifier for a page, that won't change even if we change the URL, and we put it for example in a <meta> tag in the page headers, then we can almost guarantee that we will be able to get all the comments for this post/article/question/page/whatever.
And we can also keep the URL tag for the cases where the comments client knows the URL but can't get this identifier, so it'll still be able to get them.
you need to add "#" on the query, so use filter:
{"#subject": "..."}
Ohh, good to know. It's working now correctly 👍
As I mentioned in the NIP, the reason why I'm suggesting the use of something more "stable\constant" such as this, is because the URLs can change. And although this might not be something that happens very commonly or frequently, but it happens. And if we are only depending on the url tag to query these comments, then that means we will all the comments if the URL change.
I don't think there's a way to solve this is in general. web clients are going to be using the url as the root id anyways. I don't see how they would could know about this unique identifier? If it's created from the first note that comments, then you might as well just use nip10 + the first note id as the root id.
If you want something like a chatroom with a stable channel id you can just use that chatroom NIP that people are working on.
I don't see how they would could know about this unique identifier
Yeah... I agree with you on this, that there isn't really a perfect way for other clients to get this identifier. But at least there is one page (the original webpage) that has access to this identifier where all the comments can be seen. For other external clients who don't have access to this identifier, they can use the URL, keeping in mind that they might be missing some comments. So I think it's still useful.
And if the external clients want to access this identifier, there might be a way to expose it:
1- Including it in the URL as a query parameter.
2- Fetching the page then scraping the <meta/> tag, but this most likely needs to be done on a server to avoid CORS issues, and the identifier be cached somewhere so that it's not fetched each time.
But still, even considering that external clients won't be able to get the identifier and only the URL, at least the original client has access to all the comments.
