Add reviews NIP #879
Add reviews NIP #879
Conversation
|
Great, that was too generic, this is very specific...
Oops. Just kidding. I think this may be at the right level of abstraction. |
|
What about making the scores from 0 to 100 to allow us to do just integer math instead of dealing with floating points? |
Are we sure we don't want more precision? I could see an AI leaving reviews for things that are more precise than 1%. |
|
What's the point of the Same thing for the |
L tag is required by NIP 32, but you're right it's not super useful in this case. I chose |
I assume you want the In my mind the most typical use case would be getting reviews of known things, so you would get a list of things and query for their reviews ( Is that what you have in mind? |
Yeah, exactly, coracle currently does this for the relay browse view. It's a valid use case for pretty much any product or service, e.g. |
|
can we just keep it to use the |
|
NIP 32 specifies that any event can self-label, so it would be inconsistent to not require it here. We could make L tags optional, which could be fine since clearly not every use case needs them. |
|
Eh, started editing it, I think it's better to keep |
a8c8140 to
df3a7ad
Compare
|
Coracle now has support for this. |
85.md
Outdated
| "kind": 1986, | ||
| "content": "This relay is fast!", | ||
| "tags": [ | ||
| ["L", "review"], |
There was a problem hiding this comment.
Should L for 1986 always be 'review'? If so then maybe it's redundant and could be replaced with t tag?
If not then maybe it could be removed from this nip - nip32 already states that 'events can label themselves', and repeating it here will only cause a lot of 'where is the ontology for reviews' questions?
Or maybe those question could be answered by a list of 'review/XXX' standardized labels added to this nip? But then we'd be forced to amend this nip all the time.
I'd prefer labels removed from here, nip32 already applies for everyone who wants to label their reviews.
There was a problem hiding this comment.
t tags should always be user-provided. Mixing user generated content with semantic data is a recipe for disaster.
I'm sympathetic about l tags, because you're probably right, 1986 will probably always have L=review. But NIP 32 requires L for good reasons, so you can't really omit it. And you do need to identify the type of review in an indexable way, and I can't think of a better tag than l. So I don't really see what else you could do here apart from introducing yet another tag.
85.md
Outdated
| "content": "This was a great episode.", | ||
| "tags": [ | ||
| ["rating", "1"], | ||
| ["r", <podcast guid in a standard format>] |
There was a problem hiding this comment.
Is post guid a url? If not - how would a general reviews app know how to render this guid? r should contain a url.
There was a problem hiding this comment.
In the case of podcasts, the guid is a cross-platform standard. In this example there's no l tag, so clients will be pulling reviews based on the r value, presumably they know what that value means. r doesn't need to necessarily contain a url, just a "a reference (URL, etc)" per the README.
|
After some discussion with @arkin0x we'd like to propose this approach for reviewing places with a QTS approach: The "L" tag specifies the type of review. The "l" tags then are used to specify categories for the review. Each category can have an arbitrary number of ratings of either 0 (negative), 0.5 (neutral) or 1 (possitive). The rating name is set with the category in the third element of the rating array. The total score for a category would then be the sum of the ratings divided by the total number of ratings, for a final decimal score. |
For anyone who isn't familiar, QTS (qualitative thumb system) is an approach to reviews that quantifies a user's sentiment without asking them to translate their feelings into a number. My original article about QTS was written in the context of the old NIP-32, but it works great as @satoshisound shows above with this NIP: https://habla.news/u/arkinox@arkinox.tech/DLAfzJJpQDS4vj3wSleum Additionally, @satoshisound and I agreed that the specific QTS implementation in my original article is more geared toward products ( I'll be updating my article with this new information to help others implement more useful reviews using this NIP. |
fff36ec to
b1432b7
Compare
|
I'm working on a client which will include book reviews. After reading through this PR's comments, I decided to use QTS (thanks for the article @arkin0x !), but I implemented it sticking to what is currently described in the PR files. Looks something like this, but very much WIP: {
kind: 31985, // New kind, for external content reviews
content: "this is the review comment",
...
tags: [
["d", "isbn:9780684832722"],
["rating", 0.75], // this is the total rating, calculated per the QTS system
["rating", 1, "recommended"], // the user gave a thumbs up to this book
["rating", 1, "Label 1"], // the user associated Label 1 to the book
["rating", 0, "Label 2"], // the user didn't associate Label 2 to the book
]
}My thinking was that a client following QTS can ignore events which lack the |
non-technical interjection
As a end user facing scores between 0 and 100, 0 to 1, or 1 to 5, and so on, the review reviewer may have the question: what does 79 or 81 mean? What is the difference betwee 0.7 and 0.6? I've noticed that the user friendly review reviewer apps provide an explanation, or a text qualification, as opposed to only providing a raw metric. See example from used car site Edmunds: "Fair, good, great". I'm not sure if the above belongs in the reviews NIP, or is an implementation choice in nostr apps implementing reviews NIP. |
|
added nostrability tracker nostrability/nostrability#136 |
|
Also based on @arkin0x's QTS reviews approach, the below structure is what I'm using for product reviews: The "thumb" rating label would represent 50% of the score weight and would be decided with a "good" (1) or "bad" (0) overall sentiment. The rest of the arbitrary rating labels would also be scored "good" (1) or "bad" (0), but with equal weight across the remaining 50%. The labels here are exactly what I am using, but aren't necessary; client side I am just calculating the score based on the formula outlined above. (i.e.; totalScore = thumbScore * 0.5 + ((0.5 / numberOfRatingLabels) * eachArbitraryRatingLabel)) |
@pmrcunha Will you create a NIP for this? Or maybe a PR to update NIP-73 with the review kind. |
It would be great to resurrect this again and make a few adjustments now that Bookstr is storming the scene! For Open Librarian I've used the structure below. I made a specific design choice in using the hash of the ISBN rather than having it in the |
|
@RydalWater I'm working on Coordinators rating for Robosats and I find it fits my needs. Let's push on this one! |
Co-authored-by: KoalaSat <koalasat@satstralia.com>
Awesome to see we are both interested in this! I tried to base my review event on what had already been discussed in this thread, so we're pretty much aligned.
Here's how my book reviews are currently structured: Hope this helps and excited to collaborate on this! |
|
Is there an event that represents a book? Basically, a request is made asking for a specific {
"kind": 31985,
"tags": [
["d","isbn:9781529100624"],
["k", "isbn"],
["e", "<event-id-of-book-event>"],
["rating", "0.8"]
],
"content": "Good book",
}The rationale for that is that if I have the events saved locally but don't have access to internet, I wouldn't be able to figure out which book it is just by the |
The answer to this is that not all reviews are for someone else. Indeed, a user may just want to track for themselves what they thought about the book so that a client can use that information when creating recommendations, or summary statistics for reading habits. I've added a little more on my reasoning for this route over on the NIP-XX Progress Event discussion (100% not 'privacy', just 'hidden').
Cool, same here.
This was added as an optional fallback it isn't essential but could allow clients to see how it was provided to the user at the time. |
Yes I am coming around to this idea, not for adding them to reviews, but so that we can break the dependency on external APIs. @marykatefain you'll come to see when Open Library goes down (as the archive has 10000 suffered a few outages) that it can be painful. An ideal future would be to build book-details objects into the fabric of nostr. That said I think we probably want to take this discussion elsewhere so that it doesn't hijack this thread. |
| ["rating", "1", "speed"] | ||
| ], | ||
| } | ||
| ``` |
There was a problem hiding this comment.
| ``` |
Book Review
Kind 31025 indicates a review of a book. The d tag SHOULD take the form of a NIP 73 id or resulting hash of the id.
The k tag MUST be isbn.
The raw tag provides an optional field for raw rating values to be added as a fallback mechanism or for reference.
One or more t tags may be included as descriptive qualifiers to accompany reviews.
{
"kind": 31025,
"content": "Really enjoyed this book!",
"tags": [
["d", `"isbn:9780141030586" or "648370d3279993b70d7f75625d765e08ddcbb4db5262ebd2e9db0d666c0b8412"`]
["k", "isbn"]
["rating", "0.8"]
["raw", "4/5"]
["t", "heartwarming"]
["t", "captivating"]
],
}|
I added book reviews using kind
|
|
No problem dropping the Regarding the Kind number I used was |
|
Robosats users will start rating their Coordinators with the next release following this NIP https://github.com/RoboSats/robosats/pull/1817/files#diff-0e8a2db3ba01fe63468e4c52e2018e371a6a1726c60834ed13202085fad5b911R61 |
|
I read all the discussion about and I saw the following issue: Add Nostr events for some rating cases can be problematic for some reasons. If I want to create a system to review my favorite shoes or perhaps review a market in my city? An Uber driver? Perhaps a specific product like Coca Cola? It can probably generate a little chaos with people arbitrary creating new rating kinds for each minimal case they want. Not sure if it's a real problem. But I think it's a good idea to define a general pattern to review stuffs instead of create a separated event kind for each stuff. There are some stuffs that can be rated/reviewed. In my case, I'm working in a system for rating people for a Web Of Trust in a justice protocol: Private Law Society. In our specific case, we are using a binary rating system. We want to create a graph schema to describe if a people is trustful based on our social cycle (who I positive or negative rated and who we had business and the people that my trusted parties had business and/or trust). In our case, we have only binary values for rating and had business fields. By the way, instead of create a specific kind to review books, why not define a fixed kind for any review? My idea is something like this:
So, for books rating, it could be like this: {
"kind": 31986,
"content": "This book is very great!",
"tags": [
["d", "isbn:9781529100624"],
["rating", "0.8"],
]
}For the Relay review we can do something like: {
"kind": 31986,
"content": "This relay is very fast!",
"tags": [
["d", "relay:wss://relay.example.com"],
["rating", "1"]
]
}In PLS case it could be something like this: {
"kind": 31986,
"content": "This arbitror is very trustful!",
"tags": [
["d", "pls-rating:56fff0a8bd6a54973f39edf70ce058e4495d2a8024e2caf1c965822fc2f3dca2"],
["rating", "1"], // Should be 0 or 1 for our specific system
["had-business", "0"], // A flag for our internal using
]
}Particularly I think it's not so good to PLS use tags for rating (it's a completely personal opinion). So, if I could define the way it would be implemented in PLS system, I would do something like this: {
"pubkey": "0b884d0dd72c37fe0dbb4a3c422bf8cd632fb0bdc7be51749e545a449abbd54a", // As you may know, there's the rater pubkey
"kind": 31986,
"content": JSON.stringify({
"score": true, // True for trustful, false for untrustful
"businessAlreadyDone": true,
"description": "This arbitror is very trustful"
}),
"tags": [
["d", "pls-rating:56fff0a8bd6a54973f39edf70ce058e4495d2a8024e2caf1c965822fc2f3dca2"] // this hex is the rated pubkey
]
}I see the result is not human readable, but if the client implements the correct interpretation for this data, it's ok to do it. For PLS there's not a problem. BTW, it's a decision for each project that want to implement something using this way. There was my 2 cents about this discussion. Sorry if it doesn't makes sense. I'm still learning about this all. Perhaps it can be helpful to y'all or can give some idea to anyone. |
| "kind": 31987, | ||
| "content": "This relay is fast!", | ||
| "tags": [ | ||
| ["d", "wss://relay.example.com/"], |
There was a problem hiding this comment.
Imo it should be namespaced otherwise there could be collisions with urls of other protocols that use websockets
A concrete use case of #878, which was too abstract. Reviews are useful for a lot of things, and a very simple concept.