Does anyone know if there's something like an `o` tag, for objects?
Like, if I'm rating a book and not a coffeepot or an app, how do I signify that?
#marketplace #ereaders #asknostr
Discussion
What if its a 2025 car or tv? Then it is both. Your tag will need a whole new ontology.
Thinking about it though, you're the best person I know for that challenge!
Any tag is an array. We can just add fields onto the array, like we do with `m` and `M` and `r` and etc. tags.
It's a classification system, yes, but otherwise you can't have a generic ratings app, where you can just search for topics and see lists like Top Ten Books, Favorite Cars, Best Spreadsheet Apps.
For a classification system, schema.org is used and maintained, so maybe a flat representation of that gives you a starting point.
The βoβ could start at the Thing level.
`o` could be for "object" or "ontology", and both have so many uses. π€©
No, I'm not going to use a different kind to rate every different object.
There will be one rating kind and basta.
I actually already need this for three different apps I'm working on, to cover three completely different object classes.
That's why I am not interested in using a different event kind for each of them.
Kind number is 34259 and comes from nostr:npub1cgd35mxmy37vhkfcmjckk9dylguz6q8l67cj6h9m45tj5rx569cql9kfex.
The default object is just "event", but it can be relays, publications, profiles, notes, #marketplace items, etc.
I was thinking maybe the Team Marketplace already has some tag for this. π€
I'm not building a marketplace app, but I have a use case for rating real-life inanimate objects and virtual objects, for engineering purposes.
they have their own spec GammaMarkets/market-spec https://github.com/GammaMarkets/market-spec/blob/main/spec.md#5-product-reviews-kind-31555
Yeah, you can see one major problem, there. In order to fit into the weird d tag rating superstructure, they put their nice a tag into the d tag. An index inside of another index.
I mean, I can just add the `o` and `a` tags, to be compliant with their kind number, but it's like a bug-fix.
searching by d tag is getting weird.
what are you evaluating books, people, git repositories?
I guess they used the d tag to get around having to define using the e or a tag, but that's just two lines of code.
And describing what you are identifying is easiest using a hierarchy.
I am identifying a publication. It is a book. It is friction. It is historical.
I am identifying a concept. It is a plan. It is for software. It is for testing.
I am identifying a place. It is a lake. It is in Europe. It is in Germany.
And so on. That also means that you can look for something, without knowing specifically what you are seeking, as each choice opens up more choices.
It's fiction, sorry. π
Another good example:
I am describing an applicance. It is for households. It is for kitchens. It is for dishwashing.
satlantis already has the data I don't know where, "external data and local research, combining hundreds of data points to create a snapshot of each destination" https://www.satlantis.io/place/ae/dubai/dubai/R4479752/scores
probably you can't create that amount of useful data without external sources.
I only know of the ISO codes for countries and regions. And zip codes within regions.
Credit goes to him, for figuring out that ratings are their own, independent object. Same as polls. They're effectively a special kind of poll.
Then you should take a look at https://github.com/nostr-protocol/nips/pull/879
My implementation is different, since I believe a rating is generic (like a reaction) and can be applied generically.
I use m-tags to differentiate between different kinds of classes. Default is event, but you can rate whatever you want with a single event kind.
This linked NIP argues for different rating kinds for different classes.
I personally think it sucks for discoverability, but it may work.
If you're using an m-tag you need to add the m-tag to the d-tag as well, to be able to make sure the id isn't recurring among other classes
`m` tags are already used for MIME types.
Tags are local to event kinds, they are not global across all event kinds.
Yeah, but if you use the `m` tag for something else, then I can't add the tag to the rating events. I put m tags in all events, to categorize them.
I can't use it twice, for different purposes, within the same event.
That's just a recipe for disaster because even if we don't use it for ratings someone where will and cause it to fail, shouldn't be using global tags anyway.
Almost all tags are global tags. We shouldn't just random-assign tags willy-nilly.
what? tags are not global, they are event-specific, even p-tags have different meaning under different event kinds.
Also just remembered i do kind of have a very rough NIP:
Yes, but convention is that p tags normally contain a hex pubkey. You could also put YouTube hyperlinks or imeta data in a p tag, but that would just be stupid.
yes but you can also place other things after hex pubkey, like contact lists put relays, there are other event kinds that put other data
What happens after the first entry in an index is less-relevant.
There are only 52 possible indexers. If we make them global. All hell will break loose. But 52 or even 49 are more than enough for a signle event.
If you just moving indexers as global, there will be no indexers left for new events to use. I understand you don't want to correct your app. But the argument that all indexers are global is stupid
I won't argue this point, further. I can just choose a different kind number and we agree to disagree.
I appreciate your view that ratings are independent objects, but I need a system that scales up to all animate, inanimate, and virtual objects, and does so with an ontological index, so I think we are building different things and I'm okay with that.
Thank you for helping me think this through, tho. I had a problem I've been muling over for a while, and our discussion has helped clarify it for me and now I can see a path to a solution.
That's exactly what I'm building. Pollerama is going to have movies and books soon π But yeah go ahead and just use a different kind. My parting remarks would be to do them for the right reasons, but if you think they are right then that's your call to make.
I think the scope and scale of what I want to use them for would quickly breakdown under your event structure, and even more so under the mashed-up one you linked to.
I think what Nusa posted is heading more in the direction I am considering.
In my experience, the simpler things are the better they scale, I plan to use this nip to rate everything, including marketplace listings and however complex things you can dream up, I don't see a reason so far as to why it wouldn't scale, though this discussion has given me areas I need to improve on to avoid confusions.
in the case of the film you can have a survey of options to evaluate, in the end it's like several surveys together
There's actually nothing simpler for categorizing all objects in existence, than an ontology.
The simplest thing isn't necessarily the smallest thing. It's the thing that is clearest and easiest to use. Look at the NIP discussion you sent me, and you can see how they pushed all of the complexity into the event, rather than really thinking through the event structure from first principles, and now the events just look random and chaotic.
Mine is chaotic because it's not even a NIP yet π there are multiple points of confusion, though broadly speaking I really don't think you need anything other than the things I've already added on a reaction like rating event.
I've already gone through the discussions on that nip, which is why I refuse to complicate this one.
Any formal ontology discussion doesn't belong on the rating kind itself. You're free to add any more tags that you want. But you only need an id (d-tag) and a marker/ontology tag.
Anything more is complicating it, should be handled by clients themselves.
You only need an`e` and the rating, actually. Replaceable events contain the a tag info and o tags could be in a label.
For everything nostr, yes, outside of nostr still would still need an O tag.
Yes, but you could define the e and ratings tags as mandatory and the o tag as optional, and you'd have everything on earth and in the heavens covered.
How does an hashtag have an e-tag? Or a movie have an e-tag?
Honestly I am done. Do your own thing. I don't think you grasp this fully yet. But if you think you've got it. Awesome!
Okay.
Oh, right, but something like o still shouldn't be a MUST, since it isn't used every time. It should be a SHOULD because you should use it when referencing something off-nostr.
Also replaceable events need a d-tag , unless you want to repeat your etag in your drag(bloat)
It doesn't makes sense to use it duplocatedly l, which is exactly what the older rating nip did as well.
Reactions (which are similar) does it like this
You can't react to a relay or a hashtag or a movie.
Because there is no object event type. We ran into this with hardcover books and ancient scrolls and things. We create an event that represents the item and then you can refer to that event, rate that event, react to that event, etc.
Otherwise, you can have a categorization system to search for people wanting to refer to the same thing, but you have the problem that they'd eventually give it 401740 slightly different names, and then you'd have to figure out which ones apply to your item and drag them all together.
I always think of kitchen appliances.
Who owns the event? What happens when there are multiple such events? That's just a clusterfuck. Again if you think this is the better approach go ahead and do it.
Also take a look at nip-73 for how you usually solve such things.
Yeah, I know about NIP-73. That's what I figured would be used for off-Nostr items that have no matching event.
Why put the i tags and a tags inside of a d tag, tho?
This is what I don't get.
That's what d-tags are actually for. Clustering events from the same topic, from different npubs.
Here's why I find using the d-tag confusing.
If I want to rate the book "Jane Eyre", then I can refer to it by an `a` tag in that `d` tag, and that would give me a review of some particular edition of the book.
If I want to rate the book `Jane Eyre`, as a general novel, then the `d` tag would have to contain another `d` tag, which could refer to the novel as a publication, a wiki page about the novel, an audiobook about the novel, an article about the novel, etc. So, the disambiguation page for "jane-eyre" would have the rating from that d-tag, but not from the other d-tag, correct?
But, if I put an `i` tag to the ISBN in the `d` tag, then it would be rating a different subset, i.e. the publications containing that `i` tag, including from kinds we don't support, and books off-Nostr. And it would exclude all publication events that don't have an ISBN number, even if they were for the same book.
So, you end up with a `d` index that contains a bunch of `i`, `a`, `e`, and `d` entries.
This is what breaks my head and I think I find it confusing because I want to rate different sorts and levels of things within one application.
I wish we could just have events that represent things. Like, why can't we have an event that represents a relay?
Then we could put the rating on that event.
nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q help me out, here. I'm stuck in data structure purgatory.
There's 30402 event type that allows me to identify a particular coffee machine.
A 30040 event type that allows me to identify a publication.
A #communikeys that allows me to identify a relay or cluster of relays.
Can't I just put have refer to those events, directly, rather than ISBN numbers or URIs or whatnot? I feel like having ephemeral ratings is suboptimal. I get why they exist, but they'll make client development a pain.
Is it really too much to ask, that anything rated first be clearly defined, in an event that describes the object? Then we don't need to define the object in every rating of the object; we just define the object once and then refer to that with subsequent ratings. And then everyone writing a rating would know what it will be applied to (whatever is in the e/a tag), instead of it being applied to one set in vlient ABC and another in client XYZ.
Maybe I'm just too stupid for ratings. Whatever.
nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku help me understand this construct. My brain is fighting the whole nested index thingy, but maybe that's a really clever solution because it's like a superduperindex, or something.
the reason for `a` tags being kind:pubkey:dtag is they are parameterized replaceable, the d-tag is their "permanent" identifier for an event type that can be replaced, so its id is not a stable reference
because all of these events are this type, you just need to come up with a scheme for creating the d tags i think, they can be anything really, probably might even be better to make it a nice big thing like an identifier hash so you have no issues with collisions
i think that's what you are having trouble with, not sure
also, the separator for a tags is `:` so you can use comma or hyphen or whatever to add some human readable suffix to the big long hash hex identifier
Oh, you mean the d tag in ratings could always be a hash, so that it's always the same structure?
How do we make the hash?
Would it be formed out of something like
`M` OR `o` tag
AND
name (I don't know, "jane eyre" or "ford fiesta")
AND (optional, for specific Nostr-addressable things)
`d` tag
OR
first 20 chars of hexID
Some of this stuff doesn't have an associated event, is the most-difficult thing, so this would need to create a Nostr address for things not on Nostr and for things on Nostr.
They got around it by just dumping all possible addresses to any thing, anywhere into one d tag, but a hash sounds more sane.
Use a pattern to create a hash and then have a d-tag containing the hash. Did I understand correctly?
yeah, something like the hash of the title of the object, and then like _object_name in snek case
i mean, whatever, you got 100 characters so that should be fine if you limit the title text to 36 characters including the underscores
er, no, that doesn't matter, if you use a hash at the beginning that makes it unique already... maybe make the hash out of the name of the object and a timestamp instead of just the name so you don't get collisions there
Ahhh... I get it!!! π
So, my event would include, for instance, the `i` tag or `a` tag or whatever tag, that identified what I am rating, and the `d` tag would include a hash referring to that data, so that every time I replaced the rating (by changing the content from "Loved this book!" to "Wow, this book totally sucked." for instance), the relay would look for the same d-tag and switch them out.
And the client would use the other tag to figure out what I am trying to rate. And then I could rate anything for which there could be some sort of appropriate tag.
I think what confused me, and what you and nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj just clarified, is that there are actually two different things needed (a unique d-tag, so that the rating is replaceable), and a way to refer to something (so that the client can figure out what is being rated), and that these two things don't have to be within one tag.
You can use the normal i, a, t, whatever indexes for the second, and use any d-tag structure you want, for the first.
1) Yes, events at the top. ISBN, URI, Podcast ids... can all be part of events, but they are not the addressable entity.
Same problem for when you're looking for all articles, replies, etc... on a Bach concerto. Wikis are the solution.
The best wiki entry (for you) on that concerto will aggregate everything around it (tailored to certain niche) and have all the identifiers (event and non-nostr) in there.
And the best Wiki app (for you) will aggregate the best Wiki entries (for you).
2) I think :90percent: of general Rating systems are useless on a protocol where you have replies, zaps, discussions, articles, ... on the thing you're looking to judge/compare.
If you want to know if Jane Eyre is something for you, I think we have better options:
A) Personalized summaries of the data around it.
(data that people are publish regardless of general apecs trying to make them rate stuff according to their standards).
B) Specialized Comparing apps (that use whatever metrics they find useful for the niche they're catering to)
C) Is Jane Eyre even a thing in my network?
Yes! Exactly.
I guess the fact that you can rate and like and zap and reply to nonexistent things sounds really clever, but I just want a thing. π
I think I'm only going to do ratings directly on the publications because Beave really wants them, and otherwise skip them.
They're making my head hurt.
How do I rate "stoic philosophy" without there being a wiki page about stoicism? And am I then rating the philosophy or the page?
If I rate an ISBN of Jane Eyre, am I rating that edition or the content of the novel? What if I loved the story, but didn't like the font and found too many typos?
It's like on Amazon, when you go to look at the reviews of a coffee machine and people are bitching about how the postman dropped it on the doorstep and give it 0 stars.
I was thinking about this, while walking in the forest (literally, LOL) and I love the thought of typing in, for instance, "conclave" into the search bar or URL bar of Alexandria and getting a wiki disambiguation page back, and the top entry being from nostr:npub1229y50ruvq9hjdxsjknh43gq4n9ef7h3h5hc4ezzrkg0q7kgg0tsv9a402 and containing a summary of everything npubs on wss://theforest.nostr1.com have said about the #conclave.
Could run a build hourly and create or update all wiki pages with the newest activity to the various topics.
as i mentioned in another reply, `d` tags are stable identifiers for parameterized replaceable events, because the ID is not stable
This could be a rating. This is enough mandatory data.
```
{
"content": "This is an example of what the most-basic rating could look like",
"created_at": 1746630838,
"id": "d9e2f36649296430b632291fa25b620df8a2f01946e40d81f1635f3f8fa35e11",
"kind": 34259,
"pubkey": "fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1",
"sig": "d96647a55d31bb8d259c9087efe54051b08949229bd190bb7819262cd3732920a950194c3b89362a857a7be2168f5fe9d2ab9b703510b54376fa0e2af698f48b",
"tags": [
[
"e",
"ecda6d37bb6ef23d70c00f0da333ea333911defababca4a30b3f098c6c86ef7e"
],
[
"rating",
"0.600"
]
]
}
```
There's no way I'm using different rating kinds for each object kind. That's the same mess we had with a different reply kind for each kind.
Ratings are like comments, highlights, citations, reactions, zaps. They're a thing unto themselves, not an attribute of some other thing.
have you heard of NIP-73???
Yes, but it covers things like websites and ISBN numbers.
You can't use ISBN for publications, except as optional metadata, as many publications have no ISBN. Even many books don't have one.
And I don't know how I feel about putting i tags into d tags. All this index nesting is weird to me.
Then use a DOI? Or some other identifier?
What are you even trying to achieve? I donβt get it.
I have different things and want to rate them, on a scale of 0-to-1, with the same kind:
The Dead Sea Scrolls (no ISBN, but a 30040 index event with a d-tag)
A recipe for tuna sandwiches, in a longform article 30024.
A product entry on Marketplace for a coffee pot from Siemens.
A relay.
A website.
A Model T Ford.
A hashtag #asknostr.
I was originally thinking that I would just only rate things that I can simply address with an e or a tag, I'd include that tag, and that's all.
But everyone else is using a d tag that contains all possible identifiers and addresses for everything in existence, including other tags, nested within the d tag. Like, a d-tag with i-tags and e-tags and a-tags in it. And I find that confusing.
to me this feels like a namespace problem, and perhaps the wiki style events can provide a namespace for things that don't have their own identifier
It's both a namespace problem and the question of whether it isn't better to use different tags to describe different things, outright, instead of nesting the different tags in a d-tag, just so that you can pretend that they're all using the same identifier.
also, if you have your own event kind that doesn't clash with existing kinds, I think it's fine to define the semantics for let's say the o-tag to be whatever you want it to be
And then I thought like you, that I'd use i tags (which already include hashtags and geotags and etc., btw) for stuff that didn't fit.
But why put the i tag inside of a d tag?
You want an updateable review. Ok. You need to put it inside the d tag.
Because the d tag uniquely identifies what is being reviewed, and you cannot have 2 different PREs with the same reviewed target (like the same book) but with different d tag
So, the d tag goes inside the other d tag?
Can you have i tags inside of a d tag inside of a d tag inside of another d tag?
Yeah, I'm not going to do the nested index tag thing. Made something I expected to be extremely simple much more complicated, and less filterable, just to save one tag. I'm just going to have a normal reference tag appropriate for whatever is being rated and a normal d tag.
That would be https://github.com/nostr-protocol/nips/blob/master/73.md
You can specify a book isbn using `["i", "isbn:9780765382030"]`