Nostr Web Client

hash the event ID, take only the first 8 bytes

the chances of collision over the first 8 bytes directly is higher on the raw hash of the event (consider PoW notes) than if it's the first 8 bytes of the hash of the hash.

this is how i would implement it anyway. fwiw, nobody listens to me, and even when i'm proven right nobody wants to remember i said it.

arkinox 6mo ago

so you hash the event id to get a new hash, then you take the first 8 bytes and convert that to words... now how do you find the original event? The words can be converted back to bytes, but the bytes don't represent the original event id so you can't search for it.

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

but what happens when the first 8 bytes of a note collide with another?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

with a PoW that has 5 00s in front that is only 3 bytes, or 16777216 possible different first 8 bytes then

would be better to at least use the last 8 bytes than the first for this reason (PoW)

arkinox 6mo ago

PoW events would definitely need more words, yeah. But you can use as many as you want in order to achieve specificity

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

but you don't have this problem if you use the last 8 bytes instead

arkinox 6mo ago

good point!

arkinox 6mo ago

In the interface I built, it shows both events, so in the event of a collision you get more results; you can probably determine which event you were seeking by context. The likelyhood of more than 2 results is astronomically low. Also, 6 words is a goldilocks default but you can use as many words as you want to ensure you don't get collisions. If you find a collision with your event, you can add 1 more word to probably resolve it. It's very flexible.