Still on the way to 0.7.0 :)

[martinkoutecky]

Hi all! Sorry for the long wait, and also for not responding to discussions here. Turns out I have not turned on notifications for discussions and missed these. I will keep track of it now.

I am still working on the new Managed Storage (MS) backend, and I am making sure that Direct Files (DF), which is more or less the old backend, is solid and the work on MS does not interfere with it. (DF is "more or less" the old backend in the sense that I replaced the old custom made indices, caches, queries etc. internally with SQLite, of the same shape as the one derived from the oplog in MS, so that I am not maintaining two unrelated ways of doing the same thing).

I think things are converging, but slowly. The reason this is such a mess is self-inflicted: I had a rule that the work is divided into small chunks, each has a specification written, and before it gets implemented, it gets a verification by an independent verifier. The verifier was supposed to come with "adversarial" scenarios - basically "will this work if the network disconnects at exactly such and such moment?" (or power goes out, or ...). However, the agents took "adversarial" too far, to "malicious" -- so the implementers invented all kinds of ways to protect against custom crafted bytes that could break things. So the engine ended up overengineered (for what Tine actually needs), slow, buggy, etc. The lesson is to be careful what I ask for, and also to trust the agents a bit more and do less verification during the implementation process, and maybe only run an audit look at the end. (Now - I started when SotA was Opus 4.8 and GPT-5.5; so things change and what worked then does not quite work now...)

I am now getting the Android version to a shape where it is not obviously broken - that is, I can enable managed storage, set up sync, and it works for my simple use. When I get there, I will release 0.6.94.

I am also implementing an interesting design for #337, more on that when the release lands - thanks to @EllisMorrow and @sulisu for their input.

Also enough people now contributed that I want to get the iOS app out, but that involves filling in forms etc. which competes with my keyboard time on other tasks. But it is getting closer too.

Feel free to say anything and I will try to respond to the other discussion threads too.

[Jacob-YLB]

Just a suggestion for the iOS version: maybe you could ship a TestFlight build first. This way you can avoid most of the form‑filling overhead for now, before preparing for the official App Store launch.

[martinkoutecky]

@Jacob-YLB see #421, I'll be glad if you can help test!

[Jacob-YLB]

@martinkoutecky Happy to help test the iOS TestFlight build!

[EllisMorrow]

@martinkoutecky
Thanks to Martin for continuing to develop Tine.

Because Tine relies heavily on AI for assistance with both development and design thinking, and AI itself is constantly improving and evolving, I think that when some features already work well enough, Tine could sometimes adopt a kind of staggered iteration approach.

What I mean is that, for certain existing features, if there is no urgent need to improve them immediately, it may sometimes make sense to wait until a newer and more capable generation of AI becomes available, or until AI has gone through several further iterations, before asking it to revisit, develop, or upgrade those features.

This kind of staggered development may have an advantage: AI will almost certainly become more capable over time, with stronger reasoning and coding abilities. For some parts of Tine, postponing further development could therefore actually be more cost-effective. Something that might take a month to develop today could perhaps take only a week in the future, while also producing a better result.

I personally believe that a clear-thinking developer working with AI assistance can have greater development capability than someone working without AI assistance. Human knowledge and experience are inevitably limited, while AI can draw from a very broad range of data and experience, and its capabilities continue to improve.

Whether development is done entirely by humans or by humans working together with AI, there will inevitably be some cost of trial and error. As long as we are trying to make something better, trial and error is ultimately unavoidable. It is part of the process of progress.

I would also like to share with Martin two small excerpts from the root prompt / personalized base prompt that I use when developing with AI:

• When multiple approaches can all solve the problem correctly, prefer the one that:

  • requires a smaller scope of changes;
  • is easier to verify;
  • is easier to roll back;
  • fits the existing project patterns better;
  • has lower long-term maintenance costs.

• After all hard constraints are satisfied, my default priority order is:

  1. Correctness;
  2. Maintainability;
  3. Simplicity;
  4. Performance improvements supported by real evidence;
  5. Development speed.

[EllisMorrow]

For my personal use, Tine v0.6.93 has now basically reached the point where it can serve as my primary tool. However, one of its most noticeable weaknesses at this stage is that there are still quite a lot of small bugs and rough edges in everyday use. I suspect that other people who, like me, already use Tine as one of their main tools may feel similarly.

Once Managed Storage reaches a certain level of maturity—perhaps sometime after 0.7.0?—I think it may be worth spending some focused time fixing a substantial portion of the bugs that affect basic everyday use, as well as addressing some smaller but highly practical feature requests, before moving further into the next major areas of development.

At the same time, I would also suggest that, when working on larger, more difficult, and time-consuming problems in the future, it may be useful to periodically set aside some time for smaller everyday issues and highly practical minor feature requests. This could help avoid a situation where work on one major feature causes most other parts of the product to remain relatively static for a long period of time.

I think this kind of balance could help Tine continue improving more evenly even while a major project is under development. The larger work can keep moving forward—perhaps a little more slowly—while these periodic intervals of everyday maintenance can steadily make the daily experience more polished and reliable. This would also mean that users would not have to wait a very long time before frequently encountered basic issues and small but useful features receive attention.

[martinkoutecky]

@EllisMorrow you are right, and I feel bad about the very long break because of the managed storage mess. I have decided that I will now just aim at getting to a good shape with Direct Files so that everything works at least as well as before, and working on managed storage slowly, and fixing other issues in the meantime.

There is a specific problem with the storage rewrite and why it blocked other work: storage is so critical that I don't want to / cannot make a "mundane looking" release in the middle of a rewrite. So I can't fix small things as I work on the big stuff. More precisely: sure, I could do the big rewrite in one tree and the "small" fixes in another tree. The trouble is that some small looking thing turn out to touch exactly the same stuff as the big rewrite, and then I have to possibly duplicate work and/or spend time/tokens on merges. So it is better to "just" finish the big rewrite first.

Many other important features are not really like this. I don't think that i18n work will be blocking in the same way, or features like supertags (if they don't work, you just don't use them); the bigger UI changes (codemirror) may be like this because I am not sure I will want to keep the old frontend as well (I really am not sure - I need to think about it; but it would be two things to maintain that do roughly the same thing).

So, most bigger features should not actually block "small stuff" work, but storage is fairly unique in this.

Also, the development is shaped to a large degree around my everyday life circumstances (how much time I have in short bursts on the phone vs focused time at the keyboard) and my remaining tokens, so sometimes project-wise it may not be the best time to do "small stuff" work but that's what other circumstances are favorable to. But the main blocker now is storage work, and I hope to really move ahead with that soon.

[EllisMorrow]

@martinkoutecky Thanks for the detailed explanation. What you said makes sense — in some larger pieces of work, trying to mix in small fixes can actually create more duplicated work and complexity. I think it's best to handle things in whatever pace and order makes the most sense to you.

[EllisMorrow]

Another longer-term direction I think could be very important for Tine is the plugin system.

After looking more closely at what Tine already has, I think the current foundation is actually very good: a capability-limited WebAssembly architecture, explicit permissions, independent distribution, a community catalogue, and a strong safety model. So the important question is no longer whether Tine should have plugins, but how much of Tine can eventually be extended through them.

Perhaps around 0.9.0, it could be worth aiming for a substantially more mature and capable plugin API. The principle I have in mind is: a wide extension surface with narrow, explicit permissions. Plugins should eventually have enough well-designed extension points to build substantial features, while still avoiding unrestricted access to things like the DOM, filesystem, processes, or network.

I think this is especially important because Tine currently still depends heavily on one core developer for most significant new capabilities, while externally written application code is deliberately not merged into the core. A powerful plugin system could be the natural middle ground: Martin can keep the core stable, coherent, and secure, while other people can extend Tine without interfering with it.

This becomes even more valuable in the AI era. More ordinary users can now build useful software with AI assistance, and many future needs will be highly personalized—sometimes useful only to one workflow, profession, small group, or even one person. Those features do not all need to become part of Tine's core if the plugin system gives users enough room to build them themselves.

Ideally, even if core development slowed down significantly—or Martin stopped developing Tine for several years—the software could still continue gaining meaningful capabilities through its plugin ecosystem.

If this is done well, I think it would give Tine much more long-term vitality and also greatly reduce one potential negative perception of the project: that its future development and extensibility depend too heavily on a single developer.

A stable core can depend on one maintainer; Tine's wider ecosystem does not have to.

[EllisMorrow]

• I think Tine's current plugin system is already a very good and security-conscious starting point.

  • Plugins can add Command Palette commands and slash commands.
  • They can insert, replace, or transform text around the currently focused block.
  • They can add a limited set of block decorations.
  • They can store their own settings.
  • So at the moment, the system seems especially suitable for small tools and local enhancements around the current block.
  • I think this security model is worth preserving rather than simply opening unrestricted access to the DOM, filesystem, database, or network.

• However, the current ceiling of the plugin system still seems relatively low.

  • The main limitation is not that there are too few plugins, but that the scale and kinds of features third-party developers can build are still quite limited.
  • It is currently difficult to build a large, self-contained feature with its own complex UI, cross-page data access, external services, and complete workflows.
  • In that sense, the system is still closer to "adding useful tools to Tine" than to "building another layer of applications on top of Tine."

• My suggestion would be to raise this ceiling substantially over time.

  • Plugins could eventually be allowed, under explicit and bounded permissions, to safely read pages, blocks, tags, properties, references, and query results.
  • They could operate on multiple blocks or pages within clearly defined scopes.
  • They could contribute real sidebars, panels, toolbars, complex views, and interactive interfaces.
  • They could connect to AI models, APIs, and external services through safe and explicitly authorized interfaces.
  • Plugins could also communicate with one another through stable APIs rather than existing as isolated islands.
  • The principle I have in mind is: make the space of what plugins can create very large, while keeping the underlying authority granted to each plugin narrow, explicit, and safe.

• Ideally, I would like the long-term ceiling to reach or even exceed the better plugin ecosystems of Obsidian, Logseq, and SiYuan.

  • A plugin could provide a complete whiteboard and visual knowledge environment similar in ambition to Excalidraw, rather than merely adding a button to a block.
  • It could provide mind maps, spatial knowledge maps, or entirely new ways of visualizing a graph.
  • It could provide a full AI copilot that can work with user-authorized knowledge, use multiple models and tools, modify notes, and execute workflows while remaining inside Tine's permission system.
  • It could provide a Jupyter-like data analysis environment that connects code, computations, and Tine knowledge.
  • It could provide a full ebook reading and annotation workflow, including EPUB or Calibre-style integrations.
  • It could provide a serious academic research environment integrating tools such as Zotero, DOI/Crossref services, citations, and literature management.
  • It could support Git, publishing, blogging, static-site workflows, OCR, image editing, speech-to-text, or other media and automation tools.
  • More importantly, a doctor, lawyer, researcher, trader, teacher, or other user could use AI to build a highly specialized plugin for their own workflow without requiring Martin to add that niche functionality to Tine's core.

• For me, a useful long-term standard could be very simple:

  • If a feature does not fundamentally need to belong to Tine's core, there should ideally be a reasonable path to implement it as a plugin.
  • The plugin system should gradually become a genuine second development layer for Tine rather than just a collection of small extension points.
  • Martin could focus mainly on the core architecture, data safety, performance, and features that truly belong in the core.
  • The community could then handle much more experimentation, specialization, niche functionality, and highly personalized workflows.

• I also think the built-in plugin marketplace itself could eventually become one of Tine's advantages.

  • Tine already has a good foundation with its community catalogue, automated checks, AI-assisted review, and local installation.

  • Over time, the in-app marketplace could make plugins much easier to discover and evaluate:

    • organize them by use case, profession, workflow, and capability;
    • clearly show what permissions each plugin requires;
    • show security checks, AI review results, maintenance status, and version compatibility;
    • allow users to search by the problem they want to solve, not only by plugin name;
    • perhaps eventually use AI to help users discover plugins that match a described workflow or need.

  • Independent distribution through GitHub or elsewhere could still remain possible, while the official marketplace provides a more convenient and trusted layer.

• If this direction is done well, I think Tine's plugin ecosystem could eventually go beyond Obsidian, Logseq, and SiYuan rather than simply copying them.

  • Not by giving plugins broader and more dangerous unrestricted permissions,

  • but by providing many more rich, stable, and well-designed safe extension points.

  • The ideal outcome, in my view, would be:

    • Tine's core can be maintained by one developer;
    • but what Tine can ultimately become should not depend on only one developer.

  • This could give Tine much more long-term vitality and also greatly reduce one potential negative perception of the project: that Tine may be very capable, but its future development and extensibility depend too heavily on Martin alone.

[martinkoutecky]

@EllisMorrow regarding plugins - the plan never was that the ceiling stays low. But I wanted to respond to interest rather than guess at it, so the plan was that if anyone wants to port a plugin from an existing ecosystem, they point their AI at the plugin page which has instructions for agents, the agent tries to implement it within the current system, and if this is impossible or clumsy, the agent responds with the minimal plugin system extension required to make this work, and comes back to me with this.

That way the plugin system could grow as needed, and for each growth we would know exactly why it was necessary etc. In other words, I was starting with the ceiling intentionally low, but expecting it to grow.

I still think this is a good idea, so if you have some plugins in mind you can start a discussion here and we can aim to select some top 5 plugins that would be good and that push the ceiling but not too much, and we can work on that.

[EllisMorrow]

@martinkoutecky
Thanks, that makes sense to me. I think gradually expanding the plugin system in response to real needs is a very good approach. I also had AI look through the current plugin porting rules and saw that missing API capabilities can already be identified and brought back to you as concrete requirements. I think that's a very healthy way for the plugin system to evolve.

[EllisMorrow]

A lot of bugs have been fixed over the past week, along with several nice improvements, and the progress is really noticeable.

Among the releases since v0.6.9, v0.6.98 feels noticeably more reliable in Direct Files mode. For me, it is gradually getting close to the level of reliability I felt with v0.6.5. Many of the issues that appeared after the underlying refactor in v0.6.9 have now been resolved to a large extent, and the overall experience is getting closer and closer to the reliability that v0.6.5 had.

It’s great to see Tine moving in a positive direction again.

And, jokingly, it feels like Tine took a little detour for a month — but now the car is heading toward new goals again. 😄

[martinkoutecky]

@EllisMorrow indeed. I am not happy about the detour and it mostly comes down to one mistake I made and caught only very late (letting Sol assume Managed Storage needs to be resilient against malicious actors acting on the shared files), but I still don't regret making the call. Some things you cannot learn other than making mistakes, and I think it will help me manage Tine development better in the future.

Also - internally 0.6.98 DF is a very different thing than 0.6.5. I'm glad it felt fine, but internally it was not as maintainable as the current state where sqlite has been used to replace custom indices, caches and query engines. Even if it wasn't for all the Managed Storage business this has been, hopefully, a good change.

[hestratos]

Hi @martinkoutecky.
I am very interesting in your current workflow. I noticed observing some commits that you use different models (GPT, Claude, etc). Are you using different accounts or something like openroute? I am asking it because I think if I subscribe to all of them it will cost me a lot of money.
Also, changing between agents is due to some reason? Lack of tokens (waiting for regeneration) or to improve the code quality/outcome?
Are you using a command line agent to control all of the models or the default one (codex, Claude code, etc? And any hint on how to use them?
And, are you running them on your PC or they (GPT,Claude) can be connected to GitHub and do the work on their servers? Just requesting some info on infrastructure and how to setup it
Thanks for everything (Tine, your dedication and your support)