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.
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.
but what happens when the first 8 bytes of a note collide with another?
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)
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.
