Kintara is a self-hosted document library and reader that runs in Docker and watches a folder you already have. Drop PDFs, Markdown, or text files ...
For further actions, you may consider blocking this person and/or reporting abuse
I've been working my own thumbnail project trying to be excellent for self hosted nas situations. This week I added pdf support, so I'm always interested in seeing how others tackle this. I ended up with a similar
pdftoppmpath with Poppler to keep my own Rust project Apache 2.Your work on the end-to-end usage is inspiring me to continue my own. 🆒
That’s awesome, and funny that we ended up on such a similar path with Poppler too. pdftoppm has worked really well for Kintara, and keeping the licensing straightforward was a big part of that decision for me too.
Self-hosted/NAS projects have such a weirdly specific set of problems once you get past the basic functionality, so I always enjoy seeing how other people approach them. Definitely keep going with yours, especially if you’re already adding PDF support. I’d love to see where you take it! 🙂
I haven't been sharing the link much yet. In some ways it feels like it will never be "ready", but realistically it probably is more than ready for some. I'm hoping to post more soon.
thumbrella.dev/
Nice! This is awesome. I can definitely see the overlap now, especially around PDF handling, native dependencies, and the self-hosted side of things.
I really like the tiered architecture too. Supporting that many formats without turning the whole server into one giant dependency pile seems like a smart way to handle it.
Kintara only needs thumbnail generation as one piece of the app, so it’s interesting seeing someone tackle that same problem as the actual product. Thanks for sharing it, I’m definitely going to check out the repo some more.
The NAS-first pivot is the right call. Desktop shells are nice until you want the same reading state on a tablet and a laptop. I like that the AI part sits on top of the library instead of owning it.
It's so cool! 😸⭐
Thanks so much!!
The part about verifying AI-generated passages against both extracted text and the rendered PDF is what caught my attention.
I like the architectural choice of treating the model as a source of suggestions rather than the source of truth. The same principle seems to make the metadata features much safer too: AI proposes, the user decides, and the application remains responsible for what actually gets persisted.
It makes me wonder how far this pattern could go. Could the same “suggest → independently verify → apply” pipeline become a general interface for AI features in document systems, rather than having each AI feature implement its own trust model?
That separation feels much more scalable than trying to make the model itself perfectly reliable.
That is pretty much exactly how I have been thinking about it. I like keeping the AI as a source of suggestions and letting the application remain the authority on what is actually valid and what gets persisted.
The passage verification is probably the clearest example. The model can suggest a quote and page, but Kintara does not trust that just because it came back in structured output. It verifies it against the extracted page text, and then the reader verifies it again against what pdf.js actually rendered before it can become a highlight.
I think that suggest → verify → apply pattern could definitely work as a more general framework for AI features. It keeps the model useful without making the rest of the application dependent on the model being perfectly reliable, which I have been trying to preserve throughout Kintara.
really neat project ill go drop a star ^_-
really neat github profile your nectar mcp his interesting and solid i did not try it but the way it build his solide nice job
Thank you! Really appreciate it!
There is a nice operator angle here: the best implementation is often the one that makes a bad state obvious early. A clear signal, an owner, and a reversible response path beat a more sophisticated design that fails silently.