nips
nips copied to clipboard
nostr-protocol
add nip-20: web comments
https://github.com/nostr-protocol/nips/blob/9f9a864ce1e1ebfdcfdd4835cd60807440f038e8/20.md
Hey @fiatjaf
I know I might be wrong, but do you think that including the post's url as the filter tag is good long-term wise??
Because although it's not common, but the structure of the urls can changes sometimes. Maybe they changed the sluggifing function they are using, or changes the routing strucutre...etc
So if they do that, then that will mean all the comments on the old URL won't appear anymore, right??
Unless for example, instead of replacing the r tag value with the new URL, we just add the new URL to it, so now it contains 2 values.
What I initially thought of was constructing some kind of unique reference for each post without the usage of the url, something like: r: "<HOST_NAME> <POST_TYPE> <POST_ID>.
Where hostname will be something like: Github.
Post type will be something like: Story, question, issue, PR...etc.
Post id will be the id of this post in the database, so it will be unique.
Of course the obvious problem with this approach is that how can other clients construct this Identifier for a post they are linking and they only have its URL??
Because although most websites put the id of the post in their url somewhere, but it's not guaranteed to be in a specific section in the url.
I know posts URLs can change, but what can we do? In a decentralized system we have to make compromises. If this gets widespread enough people will stop changing URLs of their posts.
If they ever do, again, no problem, we just lose some comments. They can still show the comments in their page by referencing the old URL -- we just lose the niceness of compatibility with other clients for that specific URL change case.
Is there a better idea of how to do this?
Maybe the Nostr widget/extension can check for an ID inside a special <meta> tag in the page HTML and use that as a reference, but also include the URL?
Yeah, that makes sense.
I like the idea of a <meta> tag that includes the value of the r identifier.
And as you said, it can be done together with the URL.
So when a new event is posted, it should contain a tag like r with this meta tag value, and another tag like u that represents the normalized URL of the page.
post({ kind: 34, "tags": [ ["r", "<some kind of identifier included in a meta tag>"], ["u", "<normalized URL of the page>"] ], })
This way, when the "Nostr Commenting Extension/Widget" loads on a page, it first checks to see if there is a meta tag with some standardized name, & if it find it, it uses it as the filtering tag for queries. And that's great because it means that it will find all the comments posted for this page.
If it doesn't find such a tag for whatever reason, it fallback to the normalized URL of the page and uses it as the tag filter.
Meaning that it will still get the comments, but there might be ones that won't appear if they were posted on a URL before a change. But as you said, that's probably not a big problem.
sub({ cb: ()=>{...} filter: [ { "#r": "..."}, {"#u": "..."} ] })
Yes.
By "Yes" you mean that we should move with the approach we talked about above?
What are the next steps before starting to use it?
Yes.
The next step is rewriting the NIP proposal and implementing it, in any order.
I giggled when I saw the event kind number but what's the idea behind a new kind instead of just using kind 1?
Also, I'd prefer we keep the r tag pointing to URLs even if they change. Web clients should look for the permalink if available on the HTML header if it's a web page.
Is there such a thing as a permalink HTML header? What is that?
They are called canonical actually: <link rel="canonical" href="https://example.com/dresses/green-dresses" /> these go on the header of HTML pages.
Source: https://developers.google.com/search/docs/advanced/crawling/consolidate-duplicate-urls
@MTG2000 I came to the realization that the approach used by @jb55 in https://damus.io/log/ is much better than what we have here in this proposal.
I didn't know how he was doing it, but I went to inspect and he just publishes an event with a link to the blog post and then uses that "foundational" event id to fetch comments as kind-1 events.
It is great because
- all kind-1 clients are immediately compatible;
- no one loses context because they are replying to a note that has the context already;
- the blog post can change URLs and that doesn't matter since the blog can redirect from the original URL which is in the event;
- in the awful case in which the blog cannot redirect, you can issue a new event with a new URL for the blog post, and then on the website you can aggregate replies from the two events.
The only addition I would make is to maybe include the blog post URL as a tag in the "foundational" event, so it can be found by other clients if they know they are looking for comments to a specific blog post.
What do you think?
By "foundational" event, you mean something like an empty event that gets published when the blog post is first published. It might be empty or contains just the post's URL as you suggested. And is considered as a representation for the post on the Nostr network.
So when you want to query comments, instead of constructing a custom identifier (e.g. "<host> <type> <id>"), we can just simply use the #e of the post "foundational" event.
Did I understand that right??
Yes, exactly that.
Look at this event used in the Damus blog: https://nostr.com/e/4e8b44bb43018f79bd3efcdcd71af43814cdf996e0c62adedda1ac33bf5e1371
in theory you don't even need to publish an event. it could be a random id that all replies reference, so that each one gets picked up in the #e query.
although I like having it as a real event since it adds context for people who see the replies on the nostr side
I see. It's a nice idea indeed.
Especially because of the compatibility point, and most importantly as you mentioned, the context is kept within this foundational event, instead of the comment event object.
Just a few points to consider:
1- How will a comments client/extension running on a post page figure this event id out??
Maybe when the post is created, and the event for it is published to nostr, then this event id is stored together with the rest of the post info in the database, and when displayed in a webpage, this event id is put in a <meta> tag as we previously suggested.
Or do you think there could be a better/easier way??
2- How will external clients that wants to show the comments of some post figure this event id out??
(Not very sure yet...)
3- Should we use use the #e tag to reference the post this comment object belongs to??
Because the #e tag is also used to mark the reply to an event (which is also a comment).
So maybe we should go for a different tag like #r to reference this foundational event in a comment or reply, and keep the #e to mark the reply parent.
4- Finally, who should be the one responsible for creating this event??
Is it for example the backend api that do that automatically each time a new post is created with it? Or should it be done by someone other than the api?
- Yes, let's define a
<meta>tag to put this in. Maybe that one @Cameri mentioned. - The foundational event can have an
rtag with the post URL and clients can use that to query the event, then query its replies, OR they can load the webpage, get the event ID from the meta tag and use that. - I think we can all assume very safely that the comments referencing these special events are comments to the webpage, not to the event that references the webpage. This is just common sense.
- The webpage owner can create it in any way they want and then put it in the meta tag of the webpage.
- Okay. So how can we query these replies if they don't have a reference to the foundational event??
As far as I know all the clients also reference the event at the top of the thread when creating a reply event, not only the immediate event before them.
Okay, makes sense.
So replies should have 2 e tag values, the foundational event id & the reply to object id.
Should we use the #e tag value that refers to the foundation event as is, or should we suggest a convention similar to the one for the replies?
i.e ["e", <event-id> <marker=page>]
Aside from that, any other cases/points that we should think about further ??
Or should we start re-writing this NIP according to the newly discussed ideas above?
No, just use the e tag as normal, for maximum compatibility.
I think we don't even need a NIP. Let's just experiment with it like the Damus blog is doing, then later we write the NIP to just standardize the conventions.
Gotcha Yeah, I thought too that we might not need to write a nip this way.
Let's try it this way and see how things will go.