We Just Open-Sourced the End of the QR Code Era
There's a moment in every technology's life when someone looks at it and says: "This is fine. But it's not what we actually need."
For QR codes, that moment has been building for twenty years.
We plaster them on event badges, product packaging, restaurant tables, building lobbies, and business cards. They work. They scan. And they look like a robot sneezed on your brand.
That's the trade-off we've all accepted: function over form. Data over design. Scannability over beauty.
Today, we're releasing something that refuses that trade-off.
Glyphs, not grids
Glyph is now open source. It's our Python implementation of Claycode visual codes, a technology that encodes data in geometric topology instead of pixel matrices.
Read that again: topology, not pixels.
A QR code is a grid. Every black-and-white square is load-bearing. Move one pixel, change one color, add one logo overlay, and you're gambling with scannability. The medium fights the message.
A glyph is a pattern. Data lives in the relationships between shapes: concentric rings of polygon cells arranged inside boundary forms like hexagons, shields, and diamonds. The shapes can change. The colors can change. The visual treatment can be anything your brand demands. And it still decodes.
That's not an incremental improvement. That's a different category.
What we actually built
The original Claycode concept comes from Marco Maida and collaborators, published at SIGGRAPH 2025. It's brilliant work, and we want to be clear about the lineage: none of what we built exists without that foundational research.
What we contributed is a new encoding architecture and a production-ready implementation.
The architecture is called radial-ring encoding. Instead of nesting polygons inside polygons (the original approach), we arrange data cells in concentric rings around a center point. Every cell position is deterministic, it depends only on how many bits you're encoding, not on what those bits contain.
This one decision changes everything about decoding.
The decoder doesn't need to find contours. It doesn't need to trace polygon boundaries. It knows where every cell is. It just samples the image intensity at each location and reads the bits.
That makes it fast. That makes it reliable. And critically, that makes it robust to the real world, phone cameras, JPEG compression, bad lighting, screens photographed at angles, dark backgrounds that confuse edge detection.
We added adaptive thresholding that switches strategies based on image quality. We built a multi-scale grid search that compensates for imprecise framing. We engineered direct sampling at native resolution instead of per-candidate cropping, which is 100 to 300 times faster.
Then we wrapped the whole thing in a FastAPI microservice with SVG and PNG rendering, Docker deployment, and an extensible type system for structured payloads.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
The type system is where it gets interesting
Here's where glyphs stop being "pretty QR codes" and start being something genuinely new.
Every glyph can carry a typed payload. The first byte identifies what kind of data follows, and the decoder automatically parses it into structured fields.
Today, that means:
- MEMBER glyphs that encode identity credentials, a public key hash prefix and a trust tier- COMMUNITY glyphs with group identifiers, join requirements, expiry timestamps, and presenter credentials- INVITE glyphs carrying one-time invitation nonces- RECOVERY glyphs for account recovery flows
The system is extensible. Reserve a new type byte, write an encoder function, add parsing logic to the decoder. Your application's domain concepts become first-class citizens in the visual code itself.
This is where the "next level" isn't just about aesthetics. It's about semantic density. A QR code is a bucket of bytes. A typed glyph is a structured message with built-in schema and CRC-32 error detection.
Why open source? Because infrastructure should be shared.
We could have kept this proprietary. We could have built a SaaS around it, charged per glyph, put up a paywall.
We chose not to.
Visual code technology is infrastructure. It's plumbing. It's the kind of thing that becomes more valuable the more people use it, extend it, and build on it. Proprietary plumbing creates lock-in. Open plumbing creates ecosystems.
We also believe that the best way to earn trust in the developer community is to show your work. All of it. The architecture decisions, the test suite, the edge cases in the decoder, the layout constants that have to stay in sync between encoder and decoder. It's all there. Read it, critique it, improve it.
The part where you do something
This technology is MIT-licensed and available today.
If you're building digital identity systems, this gives you scannable credentials that carry structured data and look like they belong on a premium product.
If you're designing brand experiences, this gives you visual codes that actually express your brand instead of fighting it.
If you're working on access control, credentialing, event management, or any system where a camera needs to read structured data from an image, this is built for you.
docker run -p 8090:8090 manceps/glyph:latest
That's it. You're running.
Encode a glyph. Decode it from a phone photo. Push the typed payload system into a direction we haven't thought of. Open a PR. Tell us what breaks.
The QR code did its job for two decades. It earned its place. But the next generation of visual codes should be as expressive as the brands and systems they serve.
We think this is the start of that.
GitHub: https://github.com/manceps/glyph
---
*glyph is built on the Claycode concept by Marco Maida et al. ACM TOG / SIGGRAPH 2025. The original JavaScript implementation is available at github.com/marcomaida/claycode.*





