what? tags are not global, they are event-specific, even p-tags have different meaning under different event kinds.
Discussion
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"
]
]
}
```