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.
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.
Discussion
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.