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
Nostr Event Lookup
Look up Nostr events using word sequences
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
Very cool. Love this.
Please boost for visibility! 🫡
oh man I love that 🔥🔥 cool to see other usage of BIP-39
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.
Came here to say this! Like a where39 for the nostrverse.
What do you think
@sandwich
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.
Very clever!
Yeah. I was enthralled by what3words, but it was proprietary. I found where39. I believe it was created by
@Ben Arc , the original site was down, so I fired up my own instance.
Access any nostr note from anywhere with just 6 words
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
Nostr Event Lookup
Look up Nostr events using word sequences
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
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
Nostr Event Lookup
Look up Nostr events using word sequences
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 →
THIS IS INSANE
William Gibson would be proud
Yep, another one of
@Ben Arc's brain farts. 😂
@utxo the webmaster 🧑💻 Does Haven support partial ID queries?
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
Nostr Event Lookup
Look up Nostr events using word sequences
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?
A good one, though!
Hmmm I don't believe so, depends on khatru
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.
Yes it's the first thing I wrote for nostr, closed source mess
Every time I see a QR code I think about how it could be 6 words instead
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
Nostr Event Lookup
Look up Nostr events using word sequences
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
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
Nostr Event Lookup
Look up Nostr events using word sequences
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 →
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)
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.
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!
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
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
Nostr Event Lookup
Look up Nostr events using word sequences
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 →