I want to show you why nostr relays and clients should support partial event ID queries with a cool new thing.

send or come yes our like

Paste these 6 words into https://approx.vercel.app and you will retrieve this note:

nostr:nevent1qvzqqqqqqypzp68dx7vvdlltl7sg2qdv8838ze3tl5tq76y0jnz966fdsana6dz6qqstmgpglwshgma8wqj55p4pfu58vpyqd7zu3mc6wdannxlwsydnv9q8um3zv

I've mapped the 256 shortest and most common words in the English language to a unique byte. You can use a short string of innocuous looking words to link to any nostr event, ie, any data you want.

Partial event queries have classically been part of the nostr protocol, but relay implementations have been enforcing limits on how short an event id query may be, with most relays requiring the full 64 hex characters.

I am hoping that relay devs (and client devs) will reconsider this artificial limit when considering how useful partial queries can be.

Uses:

- Representing nostr events with ~6 words can enable you to link to a nostr event in adversarial environments where known nostr URLs are shadowbanned and long hex strings would raise suspicion. (I got banned from Github for putting my pubkey in my bio once, for example)

- sharing ~6 words is shorter than sharing a full id/nevent/note1

- You can remember ~6 words to memorize a nostr event id

- As most events will never collide after 6 or 7 bytes, partial queries are a powerful shorthand for data portability. Imagine being able to represent everything on the internet with only 7 bytes. You could literally memorize how to retrieve any data on the internet!

I think this is too much of an opportunity to waste. Nostr has this unique advantage of making a universe of data accessible with minimal effort. Let's not suffocate it with arbitrary limits!

Relay implementors, please let me know your feedback on this if you care to comment.

Caveats:

- Will 6 words ever represent more than 1 nostr event? Yes, it can happen. So then you use 7 or 8 words to be more specific. Git and Github use 7 bytes to refer to commits because it's so exceedingly rare that they ever repeat. In the case that there is a collision, picking between the 2 events retrieved is likely not a problem.

- It's not as convenient to refer to an event with words as it is to link to an event, but links can be grepped and banned on centralized platforms.

- This word list probably sucks, I made it in less than an hour, but there aren't any lists of 256 words that I could find that were specifically engineered to appear reasonably innocuous and likely evade algorithmic detection. BIP-39 uses 2048 words for 11 bits each which is too uneven for conveying an arbitrary number of bytes. Also, the BIP-39 words are not very subtle.

Anyways, I kindly ask relay implementors to consider supporting partial event id queries so that this sort of powerful feature can remain a core part of the nostr protocol.

Brought to you by nostr:nprofile1qqsd0kqsnmjrv47wvpt2mfr9xqrthdjp7v09p6zjgd5pcfey2puprmqh6zq5c

Reply to this note

Please Login to reply.

Discussion

Very cool. Love this.

Please boost for visibility! 🫑

oh man I love that πŸ”₯πŸ”₯ cool to see other usage of BIP-39

Came here to say this! Like a where39 for the nostrverse.

Yeah. I was enthralled by what3words, but it was proprietary. I found where39. I believe it was created by nostr:npub1c878wu04lfqcl5avfy3p5x83ndpvedaxv0dg7pxthakq3jqdyzcs2n8avm , the original site was down, so I fired up my own instance.

This is cool, you're right. I don't think id prefixes would cause problems with performance from what I understand about how indexes work.

This is fantastic. The ability to reference an nostr entities in a human readable and communicable way enables many new use cases in the physical world.

One of the complaints about nostr I often get from the uninitiated are that the links are too long and it makes thepeople they share it with suspicious.

We should refine the word list and maybe try to standardize it as a shorthand way to reference events.

This is me requesting input πŸ˜…

Very clever!

Btw what relay software does relay.nostr.band use? Is it your own custom?

Yes it's the first thing I wrote for nostr, closed source mess

THIS IS INSANE

William Gibson would be proud

Very cool idea. How does this work with nevent ids? Wouldn’t you need the full thing to know which relays to query in the first place?

This works by just querying a bunch of relays (guessing). The six words represent the first part of the hex event id. Nevent entities aren't used in the nostr protocol REQ querying.

I like this a lot !!! I’m all about the UX … and this makes it possible to real world share content rather than machine code.

would be even better if it was mapped to the hash of the event ID. 6 bip39 words would be a permalink (6*11=66 bits 8 bytes = 64 bits)

i'm already using the 8 first bytes of a sha256 hash of an event id as the index for searching for an ID in a database. truncated sha256 hash will cover you for 19 decimal places of field which is quintillion, i doubt we are even beyond a few million events of nostr event history at this point.

the hash of the event ID? but the event ID is a hash...

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)

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

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

good point!

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.

Nope you can't. Early nostr used to explicitly support partial queries on ids only, but that has almost been eliminated in all relay implementations which is sad because I think partial queries can be super useful:

nostr:nevent1qqs07lgz6jmle598hsuj42ux83um6z6r6cv3c2y778q5qlu28de264s57wkx6