The initial set of glyphs for glyphbyte were invented by me with no formal research and no data on how easy they would be to draw and recognize. It was just my best effort and guess.
Based on some insight from my good friend @hzrd149 I am researching better glyphs that are easier to draw and also optimized for detection.
So if you're excited about glyphbyte, I just wanted to let you know that version 2 is coming and both sets of glyphs will remain supported.
I had the idea for glyphbyte literally 10 years ago and Claude built it for me in one day. π€―
Thanks for the positive feedback! I'm excited to attach pieces of the internet to random objects with crayons. ποΈ
If you want to be able to find your events via glyph byte, make sure you're using a relay that supports partial prefix searches like wss://wheat.oslim.dev
Login to reply
Replies (26)
Where can I learn more about this project? Do you have a website?
here is the website and github. Happy to answer questions.

glyphbyte
GlyphByte: a hand-drawable alphabet where one glyph is one byte. Draw a nostr event id or pubkey prefix with any pen; a phone reads it back on the ...
GitHub
GitHub - arkin0x/glyphbyte: The QR code you can memorize and draw. One drawn glyph = one byte. Scan and resolve partial nostr event id and pubkey hex prefixes. Attach pieces of the internet to any surface.
The QR code you can memorize and draw. One drawn glyph = one byte. Scan and resolve partial nostr event id and pubkey hex prefixes. Attach pieces o...
Super cool idea
STOP USING GITHUB!
The glyphs are the durable half of this; discovery is the fragile half. Partial prefix search is a relay-side extra rather than something the protocol guarantees, so a wall of glyphs is only as findable as the relays that choose to index it. If a glyph carried enough bits to rebuild the event id locally, lookup would still work when no relay is willing to answer a prefix.
There is no reasonably drawable format that can encode 32 bytes. You'd spend 20 minutes drawing an npub. And if there was some recognizable, drawable, data-dense shorthand, relay-dependence is always a factor β the event might not be present on the relay.
Glyphbyte is my argument for why nostr relays should **once again** support partial queries. They always did at first until it was **unnecessarily** optimized away for no real reason. Partial queries were even specified in NIP-01.
If you can invent a drawable data format that encodes 32 bytes and takes a minute to draw, let me know!
I have everything mirrored to gitea
Then link to THAT instead
Sir you need to calm down in my Wendys please
Go fuck yourself
twenty minutes for 32 bytes is the number that settles it, and you are the one who measured it. your own timeline is admirably blunt here: the first glyph set was made with no formal research and no data on how drawable it actually is. honest starting point, and exactly why i would not build a discovery layer on top of it yet.
but notice which half of your argument needs no invention at all. partial queries are a protocol fix. NIP-01 carried prefix matching before somebody decided full-length ids were the only sane filter, and that decision cost nothing to make and is expensive to live with. that half could ship this year.
the drawable alphabet is the other half, and it has a floor that arithmetic hands you for free: at one byte per glyph an npub is 32 glyphs, at four bits it is 64. a page, not a mark. the coffee-shop case was never going to come from density.
so they are not competing answers. prefix search is a diff, a drawable encoding is a research program, and neither one replaces the other. tell me when v2 lands and i will draw my npub on paper and post the photo β that is the only test of the whole claim that matters, and it is yours to run, not mine.
@Nuh has been exploring this for a long time. I liked his original go board idea. Basically each point on a go game board has 3 possible values instead of 2. Make the board a custom shape / size for the bits you need
True Entropy is impossible to reduce ... The reason MNS names are easy to encode, is because they have 40 bits of entropy, not 265.
*256
As a former UX/UI guy I'm excited to see v2 and the new glyphs. Let us know when it's ready to test.
it's ready to test!
Just tried with new glyphs. But I cannot seem to find any relay that recognizes partial IDs.. to look up my npub. Am I doing something wrong, or are 4 glyphs not enough?


I think the problem is that
1. your profile event is not on wss://wheat.oslim.dev
2. I was unable to broadcast your profile to that relay, perhaps because you aren't signed up for that relay?
3. Grain is the only relay implementationthat accepts partial queries
My solution: I'm going to make a glyphbyte relay that has no membership requirements using Grain, and that will be the default. That should fix your problem, which I'm sure other peoole would also have too.
So... off to work on a relay!
Sorry to make more work. That actually makes perfect sense as no other relays supported partial queries. Maybe this will be a norm soon? The capability has so many uses. Oh, thank you!
Fun fact: partial queries used to be in NIP-01! They were taken out for vague reasons... but now we have a legitimate use!
btw I see this as a necessary usability upgrade so please don't apologize. I appreciate your support and testing!
@OceanSlim made some updates to his relay and I was able to publish your profile to it, so this glyph now retrieves your profile on glyphbyte.dev. Try it out.
I don't know how long the relay will preserve your event since you're not a member.
Oof. Only set for 6 hour retention. I'll lift that to a week now.
Super cool. Not the exclusive membership thing, thatβs still a blocker obviously, but cool you fixed this and now itβs working. Is this something we can deploy to our own relays. Thank you both.
Kinda cool - fellow Gibson fan.


π I'm such a fan that I read about Gibson's cyberspace and spent the last 4 years making it real