For everything nostr, yes, outside of nostr still would still need an O tag.
Discussion
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