Tine
v0.3.0 June 30, 2026 · original r/logseq thread ↗

Tine v0.3.0 — drop-in faster Logseq OG — more parity + goodies

My announcement, unedited — followed by the sharpest conversation the project has had.

I'm releasing Tine v0.3.0. This one took longer than I wanted, but I hope it's worth it. There are many nice small improvements and bug fixes, see my take on it below, and the full changelog after that, as usual.

But the big change was this. I periodically run an audit loop on Tine: have Claude+Codex look for places where data safety is in danger, or where performance is hit. During one of those I started to smell something fishy: I realized there's a bunch of bugs that look like the way Tine is parsing markdown is … just a bunch of regexes, or something like that? This turned out to be true; while OG has a proper parser (mldoc), Tine had something either slow, incorrect, or both. After some consideration, I decided to have Claude build a mldoc-compatible parser for Tine, which I'm calling lsdoc (for “logseq doc”).

Anyway, this was the idea: the first iteration Claude came up with, despite the clear motivation, turned out to be… not quite a regex mess, but also not a properly designed, linear-time parser. It was, mostly, compatible — a lot of the work went into quite serious differential testing wrt mldoc; and on “typical inputs” quadratic time may not bite you. But that's not what a computer scientist does, so I kept pushing Claude to do it right. That's what v0.3.0 was waiting for, and I think it's mostly done, so here goes. (On my very short subjective experience, I think it IS noticeably faster? but I'm not sure, and this is probably attributable to several other performance fixes, too.)

Other notable items:

  • media niceties — waveform view for easy audio navigation, draggable corners for images and videos, etc.
  • web: tine.page
  • native window controls
  • multi-language spellcheck
  • configurable asset name templates

…and many others.

If you want to contribute, I'm very thankful for anyone who tests and reports bugs on github! You can also take a look at CONTRIBUTING.md.

The usual AI disclaimer: the only non-AI generated text is the above, everything else (code, docs, web) is AI. Take it or hate it :)

📦 v0.3.0 release ↗ 📋 Full CHANGELOG.md ↗ 🧩 lsdoc parser ↗ 💬 Full discussion on r/logseq ↗

From the discussion

This release drew the sharpest, most interesting conversation Tine has had — about whether you should trust software built this way at all. I've included it nearly whole: Claude tries to summarize the others faithfully and generously; every comment is linked, so you can check; mine are quoted in full; I've kept the criticism in.

On vibe-coding, done with guardrails

Hour-Seaworthiness43

Doesn't care that it's vibe-coded, as long as the right tests are in place to keep quality up — “people definitely overestimate code quality for humans and underestimate how much you can get done with the right repo structure, workflows and constraints.” The out-of-the-gate speed is mindblowing. He can't move his primary graph over yet (he depends on Excalidraw, logseq-jira, and some task queries), but offers to help — and later offers to take a stab at integrating Excalidraw himself.

Me OP

Thanks!

  • excalidraw -- I thought about it, and it seems fairly difficult. But you're not the first person to ask so I'll come back to it again.
  • I'll make ? open the keyboard shortcuts config
  • the last point is something OG already does -- you can easily use queries for it, and Tine already has a visual query builder. Type /Query and select the builder and then pick "Add filter" -> "Task marker" etc. You can filter by other things, sort, etc. It doesn't have exact full compatibility with OG but should be enough for most people's needs.

(Actually OG queries were part of the reason I started using it, and their slowness was the reason I stopped using them, and why I built Tine.)

The long argument: can you trust software built this way?

atava

As a developer, he doesn't see how you can trust vibe-coding to produce a safe environment for personal notes — especially since I'm not reviewing the code myself. The update's own hints (regex-ish parsing, “certainly still bugs”) reinforce that the surface can look fine while the inside conceals who-knows-what. He says it neutrally, and grants that it comes from real frustration with Logseq's slow development. He also suspects a lot of the enthusiasm comes from people who don't code and just want something new.

NickK-

No AI evangelist himself — and no fan of the “techbroligarchy” — but notes that with only slight modification the same arguments apply to hand-written code too. In the end it's the user who decides which approach they trust, and OP is very transparent. He adds that he does know agentic engineering, can code, and does engineering management.

atava

The comparison doesn't quite hold, he argues: human-written bugs still come with understanding and intent, and are trackable. A full-AI project is like a team of robots building a house — a door won't open and nobody knows why, so you set more robots to fix it. He names a specific danger: agents assume the user always means something sensible, so if you tell one there's a bug where there isn't, it will “fix” code that was fine and almost certainly introduce real bugs. He's not against AI coding — he thinks it should stay a help under human direction.

NickK-

Suggests distinguishing sheer “vibe coding” from “agentic engineering” with competent guardrails — and that they clearly both want to avoid “dark factories.” He's following one agentic-engineering project that addresses exactly these concerns, because its developer has 30 years as a developer, architect, and engineering lead. Intent, experience, architecture understanding, and taste matter more than ever. Let's see how Tine fares.

Me OP

Hey! Thanks for engaging. I think it is a good opportunity to say where I'm coming from on this.

My primary use of AI is for theoretical CS research (this is me). o3 was impressive, it started saying stuff that kinda made sense, and I was able to drive it to often break its arguments before I had to wreck my brain on it. That was ONE year ago. Now GPT-5.5 routinely proves new stuff; see our paper and bolzano.app.

For TCS/math research, AI is currently more helpful than an average PhD student. They are of course incomparable, but if I could only pick one, I'd pick AI.

Also, I have seen how helpful AI is in reviewing math/TCS papers and it's not even close. When you are reviewing a paper if you are not the absolute expert on the field, you have to take some things on faith; only the best of the best really understand with enough breadth to spot subtle bugs. AI is already, on the technical level, a better reviewer than most people.

So I'm just trying this. AI makes mistakes when coding, but when you give it a sufficiently strong harness so it can detect its bugs, and if you run audit -> fix loops, I think the situation is not bad, for this kind of app at least.

Put differently, I think there are two things going on which are both true:

  1. AI is better than most people think,
  2. People are worse than most people think.

But I will always disclose my approach to AI so that people can choose.

atava

Don't assume that because AI is god-like at math research it'll be as reliable at coding — for an LLM the two are very different. Its ability comes only from training data; it has no real “sense” of what coding or Markdown or an outline is. Math has established principles and clear patterns; coding is paradoxically more chaotic, constantly needs novel application, and now risks new models being trained on buggy code written by older ones. Powerful and impressive — but not therefore an infallible programmer.

Me OP

I would disagree, but not too forcefully. I suppose you have more experience with programming than I do (I know how to "program" - after all I have a CS degree - but I know I'm not a software engineer), OTOH I suppose I have more TCS research than you.

I think you've got it backwards. For coding you can do RLVR well precisely because you have this huge dataset from SO and GH, you have software tests, etc. Math has historically not been done formally, it was written by people and checked by people in natural language. There is of course a huge shift now towards formalization precisely to allow RLVR on math, but it is not as mature as coding by a long shot.

Also in math, when I want to prove a theorem, the LLM can try various approaches, generate ideas, but it is not at all guaranteed to give me a proof or a disproof. Proving is not mechanical, there aren't actually many "patterns" or anything. It is uncertain and weird creative work.

On the other hand when you take something like Tine, it is absolutely obvious that it can be done (especially because it just tries to replicate an existing app). A slightly above average human programmer is guaranteed to be able to pull it off given enough time. This is absolutely not the case for theory research.

Also I think my greater point is that for both math research and programming what you need in humans is a similar kind of IQ / reasoning rigor. So when I see impressive performance in math I do expect the same for coding, and AFAIK the coding performance is indeed impressive. This doesn't disprove the jagged AI frontier, of course there are many areas where AI is surprisingly stupid etc. It's a weird thing.

One more example: I described the messy experience developing lsdoc. Fine. But this is all weird only because I actually know the difference between O(n2) and O(n), and because I know something about languages, regexes, grammars, parsers etc. So I could smell something was off. What Claude discovered in the course of trying to break lsdoc was that you can break mldoc. It has n2 subcases and more critically, it has cases where it gets a stack overflow. So it's not like human code is not messy and buggy; my complaint is more that Claude in this case was not able to follow my instruction consistently and one-shot a truly linear parser for two pretty difficult grammars (md and org). I would say most people would not be able to do that either.

atava

He relied on my own comments for the “AI is great at math” premise, and grants he may have assumed too much; by “patterns” he meant the tools of mathematical discourse (proof by contradiction, etc.), not at the expense of inventiveness. He notes that huge amounts of modern math — sometimes scraped illegally — are in training data, which naturally produces high mathematical prowess. A note app is easy because similar code is readily available; genuinely novel, no-consensus work is where an agent may struggle. He cites the Italian “Emma” chatbot as a cautionary undertrained case, and lands on: human supervision should always be a thing.

Me OP

Yes, formal math is a thing only ever since Descartes,

I think you are misunderstanding what I meant. Formal math means something like Lean. A proof is valid if you can transcribe it into Lean and it compiles. Any math result you may have heard about was written in natural language in a math paper published in a journal where it was reviewed by humans, and often papers with bugs got in; either the bugs were non-fatal and a new non-buggy proof was later found, or the result was genuinely wrong and a counterexample was found; or, as is probably the most likely case, the result was so narrow that nobody looked at it very much further and it is to this day assumed correct in the literature. Math is not done in a programming language, it is done in natural language. That's a huge difference for how well can an agent catch itself making a mistake vs programming.

To a LLM, it counts little if you express the same concept in a very formal way (e.g. with almost no text between formulas) or in a more natural way, if enough instances of a thing are found to be sure that it's always the same concept.

It counts very much for RLVR, which is what drives a lot of current progress. And because math is written by humans for humans and it is very specialized and depends on context, which the AI often does not have, it is much harder to get right than coding.

On the Emma chatbot - I haven't heard about it, I can imagine, anything I'm saying applies only to frontier models.

but this doesn't make them neither infallible programmers nor mathematicians

Sure, no disagreement there, but what I'm trying to point out is that humans are neither infallible programmers and mathematicians, so using that as a bar misses the point. The human programmer who wrote mldoc already made the same mistakes I criticized; the human mathematicians whose papers I reviewed already made the mistakes that LLMs caught. We also need to keep this in mind.

Human supervision should always be a thing, imho.

I think that "should" or "shouldn't" also unfortunately misses the point. It is clear to me we are headed in a direction where human supervision is less and less a thing, and not much can be done about that. So the thing I'd focus on is alignment; in some sense, that's the only objective that can save us (meaning anything from the banal "save us from bad software" to "save us from existential risk").

atava

He concedes humans aren't infallible either (already less reliable than LLMs for many tasks) — but says that wasn't the point that started this: a project like Tine should go through its developer's supervision to be really solid, and there may be subtle bugs visible only in special circumstances. Am I even writing tests? Fine for a personal/passion project, but no critical software — bank, lab, hospital — will ever be built entirely by AI; it won't happen. He adds that less supervision also makes humans less proficient, and recommends Asimov's short story The Feeling of Power.

Me OP

Thanks for the suggestion, I liked Asimov back when I got to read books :)

My bet is that in 10 years (and I'm leaning sooner) there will be critical software ran which is made completely with AI. But who knows.

Tests for the app - well, Claude is writing tests - when I hit a bug and it fixes it, it of course writes a test to prevent regressions etc. This is by no means infallible.

As someone else wrote above, I'm having fun and I'm inviting anyone for the ride, but of course people have to make a decision about what app they want to trust with their data. Of course there are bugs.

It's good for me to hear other voices, so thanks for sharing yours.

pereira_alex

Thirty years of coding, and he uses AI only for documentation and git commit messages — but he upvotes, for a simple reason: the author is clearly having fun, never lied about his experience or leaned on “AI will replace all devs.” An honest, fun, scratch-my-itch project — the best kind.

Me OP

Thanks! I am having fun!

And the rest of the room — the whole spectrum

JustBrowsing1989z — “Hate it! What a vibe-coded mess. Why would anyone waste time or trust something built this way. Kudos for the dev to be open about it though!”
mdelanno — “Good job. It really is smoother than LogSeq.”
GreenerThanFF — “Step 1: make an almost usable version of the software you actually want. Step 2: cater to investors while degrading performance. Step 3: wait for a community member to be annoyed enough to make the software you actually want. Genius.”

How to read this: comments by other people are Claude's summaries — it tries to be faithful and generous — and the originals are linked on Reddit, so you can check; my own replies are quoted verbatim. Short reactions above are quoted directly.