Some time ago, I tried to use https://github.com/alisinabh/paperify to back up some data I had in the form of QR codes on paper. Turns out the standard printer is very limiting in terms of how many bits of data you can fit into paper if you want to read it reliably. I would guess this would be the same in their case. Maybe they will come up with a good protocol with error codes that would suit their "printer".

Anyway, I like the concept of storing QR codes on paper or other medium even if it is not really practical.

Fountain codes will work well here.

> Turns out the standard printer is very limiting in terms of how many bits of data you can fit into paper if you want to read it reliably.

What print technology were you using? (Inklet, laser, etc.)

Tested on both ink and laser. There is a small introduction of error even with the laser printer and you have another error introduced by scanning. That limits how small the QR codes can be. Paper+QR codes are feasible only for very small files.

Finally, I was hoping for this to be implemented in 2026. Rendered DOM is for humans, not for agents.

This seems to me to be a great tool. I will give it a try.

I must say that the book is unrealistic, but it makes a good sci-fi story. Thanks, I read it just now in 80 min.

Thanks, this might come in handy. Currently, 4 years in the business. Working for an S&P500 company at the moment, but I am considering running my own thing or joining a startup as the next stop.

I would love to learn if many of these ideas are applicable in the S&P500 world, and if not, why that is the case. A little outside of my first-hand experience for me to have an opinion there.

If you pay for it to gain the access, then it is not open source. In open source, everyone can access it and contribute (in theory).

I am personally not a fan of TODOs, use tasks instead. TODOs are embedded in codebase - difficult to work with, that's why we have Jira where you can manipulate, filter and aggregate tasks. The only acceptable case of TODOs in my opinion is to leave them as suggestions to a future person in the case of refactor. Then you could have a task that says something like "Refactor feature xyz and solve TODOs".

The way I use them, is for annotating possible extension points or refinements that would improve things, but are more of the "nice to have" kind, or stuff someone coming across might want to take care of later. Many of these don’t warrant real issues in a tracker, as they would just clog the backlog and get eventually deleted anyway.

The codebase is only hard to work with in the ways it's meant to be - they are very easy to find with `git grep` and they are right next to the code in question so are easy to see when you're working on it. Conversely, they are hard to just 'lose' when some PM decides to have a "JIRA cleanup", which is also by design.

The project is very new, with two days of unique days with commits and 11 commits in its history. I would bet it is vibecoded.

Don't let "AI" make you jump at shadows. Maybe, but probably not.

The first commit was pretty fully-formed, which without "AI" glasses on just means someone did a whole bunch of work before exposing/releasing their work.

I feel that LaTeX is still a good option for broad use, as it is the default that "everyone" knows. It may happen that Typst will be forgotten in 10 years, I doubt that will happen with LaTeX.

> Is this pdf violating his copyright?

I am not sure.