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 and you will retrieve this note: View quoted note → 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 @npub16lvp...7j3k

Replies (39)

nevent1qvzqqqqqqypzp68dx7vvdlltl7sg2qdv8838ze3tl5tq76y0jnz966fdsana6dz6qyw8wumn8ghj7cmevfjhyumsv93k2tnwdaehgu339e3k7mf0qyd8wumn8ghj7enpdenxzun9wvhxummnw3erztnrdakj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tcqyrlh6qk5kl7dpfau8y42hp3u0x7sks7krywz38h3c9q8lz3mw2k4vkdhn77
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.
Access any nostr note from anywhere with just 6 words
arkinox's avatar arkinox
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 and you will retrieve this note: View quoted note → 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 @npub16lvp...7j3k
View quoted note →
what the hopping fucking sideways magical tomfoolery genius is this?!?
arkinox's avatar arkinox
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 and you will retrieve this note: View quoted note → 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 @npub16lvp...7j3k
View quoted note →
arkinox's avatar arkinox
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 and you will retrieve this note: View quoted note → 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 @npub16lvp...7j3k
View quoted note →
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.
Vveerrgg's avatar
Vveerrgg 7 months ago
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.
Every time I see a QR code I think about how it could be 6 words instead
arkinox's avatar arkinox
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 and you will retrieve this note: View quoted note → 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 @npub16lvp...7j3k
View quoted note →
There is a way around this I came up with
arkinox's avatar arkinox
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 and you will retrieve this note: View quoted note → 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 @npub16lvp...7j3k
View quoted note →
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.
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.
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:
arkinox's avatar arkinox
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 and you will retrieve this note: View quoted note → 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 @npub16lvp...7j3k
View quoted note →