Tine direction / priorities

[martinkoutecky]

Hi all! Several ideas have been floated recently and not so recently and I realized that Tine could suffer from having too many features, or maybe too many features implemented without sufficient care that they don't become overwhelming and impossible to navigate.

In the end I will do what I will do, but it would be great to get a sense of what is important for you as users. I have not gone over all of github history so I may be missing something - let me know in the comments and I will try to add options later (hopefully this is possible).

... aha, I added what came to mind and ran out of options. So you can vote on what's in the poll, but I will also try to add discussion items for other stuff and you can upvote these and comment on them.

... aha, and those are presented as bullets, but you can want more than one; if you want more than one write it also in the discussion.

Also, my priority is still a) fixing bugs, b) finishing the work on managed storage / sync.

[martinkoutecky]

Better Tine presentation (webpage, docs)

[martinkoutecky]

Polish Tine UI - CSS improvements, etc.

[almmos]

Hi everybody,

First

First I want to thank you @martinkoutecky for your effort, for your time and work dedicated to Tine.
It is amazing what have been done in such a small timeframe.
Following will be my wish and my take on the priorities and directions for this kind of application.

My priorities:

Daily usage

• fixing bugs, polishing UI interactions and very easy visual customization through CSS or other means, follow Logseq OG compatibility with little enhancements and corrections where that makes sense;
• bullet proof storage and sync - I don't want to even think about the possibility to lose some / all my notes;
• speed - as my graphs grown over time, I find harder and harder to use Logseq daily.

Poll

Regarding the items in the poll, I will order them by my interest, with higher priorities first:

• Git integration and block history features;
• Graph view - with subgraph partitioning - see more below in the wish / directions section;
• Supertags and related DB-like features;
• Tine CLI / MCP;
• Packaging & Distribution - I wish for a FreeBSD package :-)
• WYSIWYG editing ("live preview");
• Proper multiwindow support - multiple windows over one graph;
• Localization improvements (translation, better support for CJK etc.).

My wishes - subgraph definition and real-time merging between a (limited) number of people with consistent access right

Directions Epic - collaboration with other people, teams

Like many of us here, I have seen a lot of graph visual representation so beautiful, so wonderful, but so unuseful.
I want those visuals to help me in some way and I am sure that there are means for this to be discovered.

I wish to have the possibility to share a subset of my graph, let's say with you, based on a specific interest. (Sure any following "you" is not you @martinkoutecky per say, but any person I want to interact with, talk, share and build common ground on any interesting topic.)
I want you to have the possibility to share with me a strictly defined subgraph of yours.

When shared between us those 2 subgraphs, i want Tine to merge them based on tags and aliases. For example Tine should find any common alias we may have already use and merge this specific node / page. If this "common" discovered page has different tags on your side comparing to my side, I want for both of us to see a common linking structure, to enrich us with a different point of view regarding that page (concept, topic). I want visual cues to know which text is mine and what text is yours.

For this to work for both of us, we need to have tools, a valid workflow and capable (visual) UI interfaces to define the subgraph.
We need to have a streamlined authorization control system built inside Tine, which allows us to fine grain control what we put in common (share together) for team work (brainstorming, development, anything): exact page subgraph definition, maybe control on the sublevel (indentation level) of the blocks inside a page accessible, type of access readonly, readwrite on each sublevel, and so on.

I don't know how Tine manage memory in the current incarnation. But I will begin thinking to NOT have a full graph loaded in memory.
My graph currently have around 8 G. I read about people with 20 G and more. My graph have notes gathered over a 5 year period. What will be after 25 years? How Tine will manage a 200 G graph alone? If a team collaboration direction will be developed, how Tine will merge in real-time subgraphs from a full team of people? We need to learn which are the proper limits to enforce.

In time maybe we can develop specific tools for finding commonalities, finding and highlight differences, analyzing percent of similarities.
I think that all these are uncharted territories with a lot of possibilities to develop in the future, to find unthought yet ways to collaborate with others.

Directions - some practical steps - my first take

• Graph view - develop simple view of the graph;
• Design and develop (with community help) subgraph definition criteria, like:
  • network distance from a specific page;
  • x level degree neighboring nodes with specific property (properties);
  • specific path neighboring nodes;
  • combine network distance with creation time or last modification time;
  • other combinations;
• Define, design and implement subgraph definition storage;
• Develop, implement and test interaction tools
  • gather feedback and cycle on design process for better tools and workflow;
  • maybe develop visual tool for subgraph definition - like a selection/crop tool in graphical application;
• Maybe design workflow and / or procedure to allow a user of desktop Tine to share with his own mobile Tine a subgraph only, like an intermediate step without worrying about access rights;
• Develop authorization criteria and requirement understanding and begin authorization system design - maybe this will be a totally new way of thinking authorization;
• Possible use case: develop granular encryption - a lot of idea to develop from here on;
• Maybe implementation for a Tine Node Server (see below on Inspiration section).

I fully realize that all this together are only some naïve thoughts, but I really think this could be a very interesting, totally new way of thinking interactions between humans (bringing slices of different "Second Brain" together) and totally new direction of development for this kind of applications.

Yes! I think this direction is more important than Supertags - but this is just me
(I love to find, study and to understand different POV. I think there is more value in this, compared with the value I can extract from my own notes reshuffling)

Tine already offers:

• strong storage system and sync capabilities;
• conflict resolution mechanism;
• database storage option (managed storage);
• rust backend for speed and consistency;

Inspiration - Cotoamy Remake

I think that there is a very interesting source of inspiration: cotoamy-remake.
They use rust for backend, they use sqlite database. They have an implementation for Cotoamy Node Server.
Cotoamy is a very interesting note taking application and personal knowledge system.
What I miss within Cotoamy Remake is the easiness to build linking structure between my own notes, provided by Logseq/Tine.

Yours, VV

[martinkoutecky]

@almmos hey! Thanks. This is great input and I will need to chew on it. It connects with some of my thoughts as well, and it was exciting to see cotoamy-remake because I have been following marubinoto for a while (in the piggydb era) and then the new apps didn't click with me (probably because I was still offline and at that moment those apps were online). But I think his views on notetaking are highly original and resonate with me.

[Brikas]

It would be great if these suggestions and your ranking would be decoupled, so people can upvote if they like it.

Now upvote is unclear if its your prefference list or one of the features.

I am interested in Collaboration capabilites. Live collaboration would be great.

[EllisMorrow]

On sync and collaboration, I mentioned another possible direction in [#337](#337 (comment)) that may also be relevant here: local-first asynchronous collaboration, including collaboration while users or devices are offline.

Some of the groundwork already seems to exist through Concord. Tine can now preserve both sides of conflicts and review or resolve sync/VCS conflicts block by block directly inside the page.

The idea in #337 was to take this further: instead of treating every conflict purely as an error, different versions could sometimes become visible branches of work.

For example, several people could independently edit the same page, even while offline. When their versions later meet, Tine could preserve the meaningful differences and show the conflicting blocks directly in context. Users could then keep one version, keep several temporarily, merge useful parts, or manually edit the final result.

This would complement rather than replace real-time collaboration.

Tine could eventually support real-time collaboration when people are connected, while remaining very good at asynchronous distributed collaboration when they are not. I think this fits Tine’s local-first direction particularly naturally.

The original mockup and idea are here for reference:
#337 (comment)

[EllisMorrow]

I think Tine should take a slightly more deliberate approach to major new features, leaving enough room for design thinking before implementation.

The question is not only which features to add, but also how they fit together without making Tine feel bloated, and how they can feel native rather than like separate systems attached to it.

This is also why I proposed the visual-thinking direction in #404. It is a fairly large feature, but if it is designed as another natural way of viewing and working with the same pages and blocks — rather than as an isolated canvas-like subsystem — I think it could become a meaningful differentiator for Tine.

I also don't consider the current proposal in #404 final. Many details could still benefit from further community discussion and exploration.

More broadly, I think what Tine should build next depends heavily on what Tine needs most at its current stage.

Since Tine is still relatively early, I would currently favor work that:

• makes Tine more stable, comfortable, and reliable for everyday use;
• makes Tine easier to discover, understand, share, and recommend, helping the community grow;
• lowers the barrier for new users to adopt it;
• gives Tine distinctive capabilities without making the core unnecessarily complicated.

With that in mind, my priorities would roughly be:

1. Bug fixing, performance, and general polish
2. Better presentation and documentation
3. Localization improvements — translation, better CJK support, etc.
4. Packaging & Distribution — Windows signing, Play Store, App Store, etc.
5. WYSIWYG editing (“live preview”)
6. Visual thinking / multiple views of the same page, as proposed in [#404](Add Mind Map / Spatial Views to Tine Pages: One Markdown Page, Multiple Visual Views #404)

For useful features that do not necessarily belong in the core, I think a good plugin API, documentation, and clear plugin-development guidance could let the community build much more without making Tine itself increasingly complex.

Overall, I would prioritize work that improves everyday usability, community growth and adoption, or Tine's distinctive identity.

If Tine's community grows well, many useful features could eventually emerge naturally from the plugin ecosystem rather than all having to be built into the core.

[martinkoutecky]

@EllisMorrow thanks!

[agarcabin]

upup

[scavi-github]

Thanks for your work on Tine! 🙂

To be completely honest, I mostly care about stability and long-term reliability, rather than big feature additions.

To me, the listed features are not much more important than other currently open issues.
However, these would be my personal favorites from the list:

1. WYSIWYG editing ("live preview")
2. Supertags and related DB-like features

Another note: I think before starting store distribution, it might be a good idea to prepare the repository to better handle more traffic. For example:

• Allowing users to close their own issues (Repo meta: the reopen-on-closed-comment workflow stops reporters from closing their own issues #441).
• Listing contribution guidelines in the issue section.
• As far as I know, there is no moderation of issues yet (?).
• Enabling issue labels from CLI (Repo meta: let issues filed via GitHub CLI get the bug/enhancement label (auto-label from template headings or title prefix) #429).
• It might also be helpful to take inspiration from high-traffic repos, such as NewPipe or OpenClaw.

[Louis-15]

I chose WYSIWYG editing ("live preview"),
but I think the editing system should not stop there — it should also add more rich-text formatting features for the note body. I already suggested this in #219

[Brikas]

I would also like to re-propose Multi-cursor editing
#389

Multi-cursor editing, the VS Code kind. It's the one thing I keep wishing for in an outliner.

[Brikas]

And I would also like to proposse Advanced Keyboard Shortcut engine
(inspired by VS Code)
#383

[Brikas]

Finally, I would like to propose Advanced Search Engine

Semantic Search
Auto-embedding notes locally or optionally via compatible API. Allows to search by meaning.

Graph-connection-based / Hybrid Search
Incorporate principles of GraphRAG

Advanced scoring model
Could we smartly incorporate any of: graph-score, semantic score, literal score, fuzzy score, traffic/'note-popularity' score, recency score? Searching blocks and even pages would become much more effective on a large graph.
Opt-in as performance can drop. And also predictability can be important for some users.

[EllisMorrow]

I’ve noticed that almost none of the local semantic-search tools currently available support Logseq-style Markdown outlines. Semantic search would also be a fairly heavy feature to build.

However, I already have a working piece of software that supports both Tine and Logseq files and already includes its own scoring algorithm:

https://ellismorrow.github.io/Caelune/

Because it is released under the MIT license, I think it could potentially be integrated into Tine in the future as a substantial plugin. Building something like this from scratch inside Tine, even with AI assistance, could easily take one or two months. Another possibility would be for Tine to use Caelune’s source code as a reference and implement similar functionality directly in the core, which might make development much faster.

That said, if this kind of feature runs fully offline, it depends quite heavily on the user having a reasonably capable GPU — ideally at least something like an RTX 3060 12 GB. Otherwise, both querying and building the semantic index can become quite slow.

It is possible to use a lighter model so that users with more ordinary hardware can still run it, but the retrieval quality would then become significantly worse.

[Brikas]

Also, a meta point.

It might be a good idea to do these roadmap and community Q&A polls outside of GitHub.

• Most of us here are more technical / power users. The average or potential user might be quite different.
• Volume: If you drive traffic from the app to a platform with minimal voting friction while still maintaining needed anti-spam, you will get more voices.

And also, what kind of telemetry do you have? Collecting some anonymous adoption data could be of good use.

• Drop-off rates correlated to feature or OS platform also provide an insight into what's important but failing. Only a minority of users report bugs, rest silently quit.

[martinkoutecky]

@EllisMorrow @Brikas Thanks for engaging this.

I have a bigger post cooking but a quick response here - I have realized there is no way I can, on my own, replicate something like Obsidian, and, more importantly, that that would be completely pointless. If someone likes Obsidian, they can already use it. Also, if Obsidian was what I wanted, I would have used that and wouldn't have created Tine.

So I want to come back to how Tine can serve my needs. This is important also because otherwise developing Tine feels like a chore; I need to find a direction and a flow where it feels useful and fun to me.

I am very thankful for the (still small, which I like) community that grew around Tine. You help me debug, polish, and also propose many features, some of which are an obvious "yes" for me. I currently don't feel the need to grow the community for my sake - the opposite, I am already fairly overwhelmed by the amount of issues (the issues are not the problem, of course; they are still very welcome).

I think I found the direction I want to pursue, and the discussion here helped me discover and flesh it out, but yes, a direction means choosing to do some things and NOT do other things. This is inherent, it is good, but it may not fit some users. I hope most of you will be as excited about where I want to take Tine as I am :) We shall see.

[Brikas]

@martinkoutecky

"So I want to come back to how Tine can serve my needs. This is important also because otherwise developing Tine feels like a chore; I need to find a direction and a flow where it feels useful and fun to me."

"I currently don't feel the need to grow the community for my sake - the opposite, I am already fairly overwhelmed by the amount of issues"

Touché. A very human angle and I think it makes sense right now. I'm in for the ride on this kind of roadmap vision philosophy at least for while. 👌

Will keep pushing bug reports and suggestions and are happy to take a "no" if my suggestion would make developing Tine feel like a 'chore'.

[EllisMorrow]

@martinkoutecky
Reading through the discussion here, I realized that some of us, myself included, have probably been thinking for quite a while about how to grow the community, make Tine useful to more people, and encourage more people to participate. (I imagine that future newcomers who have not seen these discussions may naturally arrive with similar ideas as well.)

That kind of thinking naturally leads to ideas like allowing Tine to absorb some capabilities that have already been validated by large user bases in tools such as Obsidian. In a way, this is a more growth-oriented way of thinking about the product.

Your response also helps me understand your own perspective much better. I think the value of these discussions is not only that they generate more feature ideas, but also that they gradually help us understand the direction you want Tine to take and where the boundaries of that direction are. If we continue contributing ideas in the future, that gives us a much clearer sense of which suggestions are more likely to fit Tine.

I have also developed quite a few pieces of software myself, so I strongly agree that it is very important for the software to remain useful, meaningful, and enjoyable for the developer personally. Especially for a non-commercial project, that is often one of the most important sources of motivation behind continued development. If development gradually starts to feel like an obligation, then even a larger community would not necessarily make the project healthier.

From my side as a user, the main reason I have often thought about growing the community is that I care a lot about the kind of ecosystem that could eventually form around the plugin system.

If enough people participate in the future and the plugin ecosystem gradually matures, then many extensions may no longer need to depend on the core developer. The community itself could gradually begin to grow a large amount of functionality naturally. To be frank, there is also a very personal reason behind this: I would like the tools I use to have as long a lifespan and as much long-term vitality as possible.

That said, if Tine ultimately chooses to stay focused on a few clear directions rather than continually expanding to satisfy many different kinds of users, I would also be very happy to see it become a smaller, more focused product.

Personally, I do not need software to do everything. Doing fewer things, but doing the important ones well, is also a very good direction. When development resources and attention are limited, staying focused can actually produce better results. Expanding endlessly can instead scatter development effort, and in more serious cases can even make the development path increasingly chaotic while gradually taking away some of the enjoyment of building the software.

I recently also took a rough look at the volume of Issues being submitted and handled in Logseq and Tine, and summarized some observations in [#450](#450). Within the range I looked at, the rate and volume of Issues coming into Tine were already several times higher than in Logseq.

I only use Logseq here as a rough numerical reference, not as a direct comparison between the two projects. They have different goals, development models, and stages, so I do not think there is much value in comparing them directly.

What I mainly mean is that such a high density of feedback naturally creates some pressure for the developer. But I also believe that once Tine’s direction becomes clearer, this will make it much easier for Issues to fall into natural priorities and trade-offs: which ones belong to the core direction, which can wait, which are better suited to plugins, and which can simply be considered outside Tine’s scope.

I think one good approach would be to make the directions that have gradually become clear as explicit and visible as possible. That would give people a better sense of the boundaries when discussing new features, and make it easier to judge whether an idea is strengthening Tine’s direction or already moving beyond what Tine actually wants to become.

[martinkoutecky]

@EllisMorrow Thank you. I agree. Also thanks for re-emphasizing plugins and naming how they help resolve a tension I feel now - I don't see a good way to make this a multi-maintainer project, at the same time I want to accept help and contributions. Plugins should allow that. The thing is making Tine stable (not just externally but also architecturally) enough for this to not be very frustrating for the plugin developers.

When I'm ready to write down and communicate the direction that is shaping up I will try to do so clearly and visibly.

[EllisMorrow]

@martinkoutecky
Maybe as Tine continues to develop, there is no need to think too much about everything around the edges.

I think that when most people use a piece of software in practice, they ultimately spend most of their time around a relatively small set of core capabilities. As long as those foundations are solid and continuously refined with enough care, Tine can already be an excellent piece of software for the specific scenarios it is meant to serve.

For example, the things you have already been focusing on:

• reliability;
• thoughtful, genuinely useful improvements around the core workflows;
• continuous refinement of the overall experience;
• and pushing performance as far as reasonably possible.

Once those most important things are done well enough, other things only really need to be added when there is spare capacity — or, put another way, many of them simply become much less important.

It is a little like the Pareto principle: not every feature matters equally. What often determines how users — including the developer personally — experience a piece of software is whether a relatively small number of its core qualities are good enough.

I think looking at the continuously growing number of Issues through this lens would also make prioritization easier, because the number of issues that genuinely touch the core and are important enough is actually quite limited. Concentrating Tine’s limited development resources on those things that are truly important and that you personally find especially interesting seems like a very good choice to me.

[Jacob-YLB]

HI @martinkoutecky . I see that WYSIWYG editing ("live preview") is currently the top-voted feature request in this discussion. I’m curious if there is any rough timeline for when it might be picked up for implementation. Of course, top priority remains stability and bug-free experience. No pressure, just wondering.

[martinkoutecky]

I am kind of debating this. My sense is that still at least on the storage level, which is invisible (when it works) but critical, Tine is currently not in a great shape. Data is not being lost but you see people reporting freezes, things not loading etc. (That's because of the recent query work, and also some interplay with I/O being much slower on windows than linux, etc. -- so it is not really hitting me, but it is other users.) So that needs to get fixed first and is taking a long time.

After that I have some priorities different than this, but I think it can maybe come alongside. I am also a little hesitant because Claude said that there was a lot of work that went into getting the current editor to work ~correctly. Again, those are little things which are invisible when they work - eg when you start selecting text of a block you were not editing, you need to switch to edit mode - there needs to be a translation from where you clicked in rendered mode to where you clicked in edit mode - this required some changes in the parser etc. It's all a little tricky. So, I will give it a shot and if it turns out fairly easy, great, if not, I will think about it again.

Sorry for a kind of non-answer.

[matristix]

My biggest wish is avoiding bloat. Tine feels like fresh air and I don't feel the sluggishness that I do in Obsidian. But you already know this, and I see similar comments from Logseq users. Anyhow, thank you for your work.

[EllisMorrow]

I’m also an Obsidian user. I started using Obsidian not long after it first launched. In my view, if someone prefers something more lightweight, they could try apps like Typora, MarkText, or Zettlr.

Obsidian’s biggest strengths are its performance and compatibility. If Obsidian feels slow to you, there is a good chance that one or more of the plugins you use are poorly optimized or conflicting with each other.

For example, I developed this Obsidian plugin:

https://community.obsidian.md/plugins/block-reference-enhancer

It has gone through many rounds of performance and compatibility optimization. Those improvements were made gradually, day by day, and took a great deal of time and effort. Without them, the plugin simply could not perform as well as it does now — or, put another way, it could easily drag down the performance of Obsidian as a whole.

This plugin allows Logseq or Tine files to be displayed and edited properly inside Obsidian.

In my view, Obsidian’s biggest weakness is that it feels rather rough. It does not provide a particularly polished, carefully designed foundation. I think Tine may eventually have the potential to become that kind of “polished foundation,” although at the moment it seems that Obsidian’s approach of maximizing compatibility and extensibility may not be Tine’s main direction. It is hard to know how that will evolve in the future.

Obsidian is extremely extensible, and almost anyone can write plugins to add whatever functionality they want. But the downside is also obvious: if someone does not know how to choose good plugins, or simply does not want to spend time configuring and experimenting with them, what they are left with is a fairly rough piece of software.

Most plugins are also not especially well polished or maintained. Only a relatively small number are genuinely strong in both performance and functionality.

If we are talking about software that truly feels “bloated and heavy,” I think SiYuan is a better example. But in my view, the main reason SiYuan feels bloated is actually its UI and interaction design. SiYuan is also a very popular offline note-taking app, but it seems to have accumulated many different features before there was enough overall design and organization around them. Some people in its community even refer to it as a kind of “Frankenstein” application because so many things have been stitched together — which I personally do not think is a good outcome.

It has a huge number of features, but users who do not use many of them cannot freely reorganize or hide the various interfaces, buttons, and controls. Many of those features are also not especially easy to understand or use in their default presentation.

So the problem is not simply that there are “too many features.” Much of the problem lies in the interface design itself.

It is a bit like a home where everything that should be stored inside cabinets has instead been laid out in the open. Many of those things should really be put away inside well-organized cabinets, and the cabinets themselves should also be arranged properly.

As an aside, SiYuan and Orca Note both have good performance and rich functionality. Yet Orca Note still gives a much lighter overall impression. Neither of them, however, uses Markdown in the same way.

Apple’s iOS is another example. It is actually an extremely complex system with a huge number of features designed for many different kinds of users. But because the design is so carefully done, it often feels simple and lightweight in actual use — almost as if even a child could understand and use it easily.

I think it would be a major advantage if, whenever Tine adds a feature, it asks whether even a child could understand and use it easily. That kind of design discipline could allow the software to become functionally very sophisticated while still always feeling lightweight in both appearance and use.

What I am really trying to say is that the sense of “bloat” some software creates is absolutely a real problem, but very often it is more a problem of UI design and interaction design than simply the number of features.

For modern note-taking software, richer capabilities often give users more freedom and can make a product more attractive — Notion is an obvious example. Of course, that does not mean features should be added indiscriminately without careful selection and design.

One important strength of a note-taking app is whether it provides the capabilities users actually need while still feeling lightweight and simple through good design.

As a side note, in the AI era, I think much of the expansion of optional functionality should increasingly be handled by the user community through plugins, while the application itself should focus more on providing a stable, reliable foundation and a well-designed interaction model.

[matristix]

You are correct. I haven't expressed myself properly. I've been using obsidian from the very beginning almost, before minimal theme was even a theme. And it is a sturdy piece of software no doubt.

However, by sluggish I meant overall responsiveness (of electron, I suppose?) is bothering me considerably, especially on very weak devices.

Feeling that I need to wait 5 seconds for the app to load on a low end phone already kills my desire to make a note (no extensions). Yes there are workarounds with other capture methods to funnel it into obsidian but it's not the same to me...

Therefore I was more concerned that the advantage that I see in Tine gets taken away eventually, by it eventually becoming unfriendly to potato devices.

I fully agree with your take on expansion through plugins.

[EllisMorrow]

Now that you’ve explained it, I understand your point much better, and I agree.

If the performance is poor, it becomes very difficult to keep wanting to use a piece of software for actual work.

I had a similar experience with Logseq OG. Because my graph is relatively large, after the app had been running for a few hours, every character I typed could take 1–2 seconds to appear. And every time I launched the app, it could take around five minutes before it was ready to use. Even better hardware did not really solve it.

That kind of experience becomes extremely frustrating. It is like always having a grain of sand in your shoe.

So yes, performance really is a very important factor.

[coderamm]

Thank you for developing Tine -- I can finally switch out of Logseq which I no longer want to use/support. Tine already does most things I need it to do. I can get behind rewriting/redoing my advanced Logseq queries just so I can use Tine's snappier, more focused program. I've never used the White Board, Flashcard, or Graph view features on Logseq for instance and I love that there's no 'noise' in my opinion. I would also vote to keep Tine as light as possible.

Zotero integration is one big gap. It's my understanding that Logseq is/was popular with researchers for this reason. It's super helpful to be able to directly reference literature in your Zotero library, have the program auto create pages with pre-populated fields, hyperlink to externally stored and managed PDFs, and annotate said PDFs. Is this something you're considering adding to Tine? This is currently the only reason I still have Logseq running in parallel.

It would be nice to add two options to the poll (or to a subsequent one) -- no changes, and Zotero integration, to gauge the interest.

Once more, thank you.

[Brikas]

@martinkoutecky in the agentic era, where AI code harnesses are faster at writing code than humans clicking buttons, what about approaching these integration questions by making Tine really easy to extend via multiple surfaces: realtime hooks, API; compiled plugins, etc.?

[martinkoutecky]

Well, I think this has the same considerations as plugins - it needs to be designed well, once, not move all the time, be safe, etc. I don't feel like I can do that now, but the idea with plugins was and still is that people will want a plugin, point their agent at the tine plugin registry (which already has instructions for agents) and the agent will either implement the plugin and submit it, or it will say "cannot be done today, this is the minimal API extension I'd need, send it to Martin", you send it to me and I will consider it (and most likely do it). aka grow the API based on demand, not proactively.

[EllisMorrow]

Brikas's idea makes me think of a further possibility: in the future, Tine could potentially integrate more deeply with Agent capabilities similar to Codex, Claude Code, or Jan.ai. A user could simply tell the AI what they want, and the AI could try to generate the plugin automatically; if the existing Plugin API is insufficient, it could even further identify the smallest missing API capability needed to make the plugin possible.

This is a very advanced and imaginative direction. However, at Tine's current stage, if Tine itself were to develop and maintain a complete Agent integration layer, the cost would probably be quite high.

So for now, as Martin said, letting users rely on third-party Agents for this work and then gradually expanding the API based on real demand, rather than proactively designing the entire API upfront, seems like a more cost-effective and practical approach.

As long as the plugin system, API, and related documentation are clear enough, capable Agents should be able to determine which API capabilities are missing while trying to implement a request, and then report the smallest capability gap back. In this area, Tine may only need to document how users and Agents should propose a minimal API extension, following Tine's conventions, when the existing API cannot support a particular need.

If the number of plugins grows significantly in the future, Tine may also need to gradually improve how the plugin registry is managed, for example by applying some level of review for compliance with Tine's conventions, security, and basic quality before deciding which plugins are appropriate for inclusion in the official directory.

However, I think all of this would be better developed gradually once Tine's core architecture is sufficiently stable.

[Brikas]

@martinkoutecky I agree that generally the plugin API has to avoid breaking, but also an API that is so limited or depended on 'whether Martin will implement my request' might be a hassle to deal with too. In my opinion. its also not the end of the world of once in a while a Plugin API piece is loudily deprecated.

What about picking an Oracle on plugin API? Other apps has surely dealth with the same problems as your are pointing out.

[hestratos]

[hestratos]

Sorry @EllisMorrow, but I don't think you understand it. You have to separate three things:

1: I would like a conceptual model, or just a model, of what Tine is or wants to be. I would like it; I’m not forcing anyone to make it. It’s like #592 but at a conceptual level.

2: I propose ideas that I would like (because all ideas are subjective). Martin is generous and gave us a product; I think this forum is for proposing ideas, discussing them, agreeing or disagreeing with them. In return, we also report problems that, if one person were using the software alone, they wouldn’t encounter. You can agree or disagree, that’s fine. Of the things I have proposed, in my experience, and without using AI, I can tell you that, apart from the ones that were examples (like editing a block in a different language), they don’t represent a rewrite or a drastic change. It’s simply about abstracting more and more, keeping the core sperated from the storage and the presentation layer, and tying everything together with a consistent and understandable model. And on top of all this, I’m just expressing what I would like as a possible vision, nothing more. If in a year another Tine comes out and I like it more, then great, that’s how it is.

3: Look at the questionnaire and see which option has the most votes (and I would have voted for the command line before supertags). I am no alone.

Also, think about one thing: imagine @martinkoutecky decides to do all that I proposed. What guarantees that I will like the model and what it becomes? There are possible multiple implementations, there is a risk/complexity in something new. Yes, that’s true, and I understand your concern, and I can see how it could take the project in the wrong direction. I also think that the way the queries have been done is not to my liking. Well, it is what it is. And when I was looking at the managed storage commits during my holidays in August and seeing 33k-line files in Rust, I was thinking... oh my god, this is going nowhere. But well, look at the project now, it’s much better because Martin, unlike others using AI, is more competent (and has a lot of money to spend on AI agents :P).

This is an experiment, and possibly, by polishing the user interface a bit more, improving the mobile side, and leaving it as it is, you could consider it a finished product, and that’s it. And I’m sure that’s what its author initially wanted, and what some people here wanted too.

I have no problem continuing to use Logseq because I’ve been using it from the beginning, and after all the suffering it was, I can keep doing the same. If some idea that someone expresses at least improves Tine functionally, then so be it.

[EllisMorrow]

I do have some concern that Tine could drift in an inefficient or unsuitable direction. Part of that concern comes from watching Logseq OG over the past few years: a great deal of development effort was invested, yet from a user's perspective it was often difficult to feel progress proportional to that investment. Communication with the community around some major development directions was also limited, making it difficult for users to judge whether those investments were truly aligned with real usage needs. I would not like to see something similar happen to Tine.

Of course, I am not the developer myself and am mostly just participating in these discussions. But I have also spent a considerable amount of time contributing to Tine's Issues and testing, so I hope these discussions can ultimately have a positive effect on Tine.

Thanks for separating these different levels more clearly this time. In the earlier discussion, the conceptual model, the features you personally wanted to see, the Logseq DB / Tana-style model, and specific Query issues were often discussed together, which is why I initially understood them as part of one overall direction.

Of course, this forum is meant for people to freely propose and discuss ideas, and it is completely normal to agree or disagree.

That said, I still think you underestimate the engineering scale of some of these changes. Unifying pages and blocks as Nodes, further separating the core, storage and presentation layers, changing the semantics of properties and queries, and further decoupling the internal model from the physical Markdown/Org structure may each be described as abstractions. But in an existing application that also needs to support real files, external editing, synchronization and conflict handling, these are not small changes. They would affect the data model, identity, parsing and serialization, queries, the editor, synchronization and compatibility at the same time.

I also want to clarify that the main point I have been discussing is not whether Martin will ultimately implement these ideas. My point is that many of the core directions you are proposing — unified Nodes, unified properties, page/block conversion, Node-oriented queries, and a stronger schema and semantic model — have already been implemented to a significant extent in Logseq DB.

So my concern has mainly been about resources and direction. If Tine spends a large amount of time rebuilding a model that Logseq DB has already developed deeply, Tine could easily end up devoting substantial resources to following the same path, while taking those resources away from stability, speed, real-world usage needs, and the areas where Tine can remain genuinely differentiated.

Individual capabilities are certainly worth learning from. But if the desired destination itself is already very close to Logseq DB, I still think directly using, forking, or further extending Logseq DB would be more cost-effective than having Tine rebuild itself along the same path.

As for what Tine ultimately is, or what it may become in the future, I personally prefer to keep an open mind.

At its current stage, I think stability is still more important. Tine went through many rapid development “sprints” earlier, and the project still seems to be in a stage where the core needs continued stabilization and refinement. Once the core is genuinely stable, deciding what should be added or changed in the next stage can happen on top of a much more reliable foundation.

I think Tine can clearly document what it is today and the conceptual model it currently uses, without necessarily defining too early what it must ultimately become. Some of the directions that truly fit Tine may only become visible gradually through experimentation, real-world use, and continued practice.

[hestratos]

I just came across a bug (#624) reported that supports/demonstrates what I’m trying to explain. I’m curious to see how it gets resolved and what happens to Tine’s native queries.

[hestratos]

I deleted by accident this thread's head, Is there any way to recover it?

[martinkoutecky]

@hestratos Not as the head literally but I had it in my email notification. This is what you posted:

What I would like is for Tine to define or improve its conceptual model. At the moment, it is supposedly based on Logseq's, but the question is: What is Logseq's conceptual model? Logseq started out as an Org-mode editor with some Roam functionality added to it. Or, rather, with what its creator "understood" from Roam's model. It wasn't the only one. Now we have Tine, which wants to be a faster and more stable Logseq. But the question is: What is Tine's conceptual model?

Logseq made many mistakes, and we now have Logseq DB, which adopts, with certain nuances, Tana's model. Why? It is not because of supertags, but because it is an evolution of Roam and an improvement on it. It has a defined conceptual model and, more importantly, it is documented. AI agents can implement its features more effectively because there is already a defined foundation to work from. And a human can read the documentation and understand the features without having to install the software and try to work out how it works.

If Tine adopts a modern model (based on Tana, Logseq DB, or whatever), then it could simplify many things and offer something more than just speed. And adopting a new model does not mean abandoning Logseq's Markdown format. It could simply be extended without breaking compatibility, in the same way that Tine's new queries can coexist with Logseq's queries.

With this new model, for example, we could improve the concept of the Node (as Logseq and Tana does): every block or page is a node. Tine's queries would not need to distinguish between the two. You could even turn a block into a page (promoting that block to a physical page and embedding the page where the block currently resides). Adding or editing properties on a block would work in exactly the same way as doing so on a page; adding tags would work in the same way, and so on. All of this is documented for both Tana and Logseq. The difference would be the use of Markdown files.

Another thing that has always been broken in Logseq is namespaces. If you select a date in this format: 2026/10/01 (yyyy/mm/dd), then I have a namespace that starts with the year, followed by the month and then the day. But if I select "do MMM yyyy", like 1st Oct 2026, the concept of namespaces disappears. I can no longer have a hierarchy or perform complex queries, etc.

This is where an abstraction is needed: separate the filename format from the date name in Tine's model.

When Logseq adopted supertags, it removed namespaces, although it introduced them again later. But it did improved them. We can learn from that.

Following on from this, you could even edit a block using Org-mode syntax and save it as Markdown. Or even use a completely different syntax.

And taking this even further, you could make every paragraph a block, and every heading always a block, while also allowing collapsing a heading to collapse all the blocks underneath it up to the next heading at the same level, as Word does. An outline which, physically, is not an outline in the file.

This last point would make it much easier to move towards WYSIWYG, because you would no longer have to deal with ten paragraphs inside a single block. When you click on a paragraph, because it is a block, you only get the Markdown for that paragraph, making the experience much less disruptive. The number of times I have had 30 paragraphs in Logseq, with their headings, equations, etc., and have had to turn them into an outline just so that I could add properties to, say, paragraph 15, or reorganise the paragraphs. It is so much easier to do this with an outline.

And importantly, treating every Logseq file in this way would not break anything. Tine could convert it into its own internal model on loading a page, and if it is modified or altered on Tine, it could then convert a block containing multiple paragraphs/headings/etc. into a sequence of blocks. I am not even asking for this to be implemented; I am simply pointing out what could potentially be done as an evolution of the system.

I can think of many things that could change. I understand that all of this is a software-engineering and knowledge experiment, but the first thing that needs to be defined is the conceptual model. Everything else builds on top of that.

It is true that the community is very, very small (I am surprised by the issues in the new query system, and apart from one recent issue, nobody has said anything). I still use Logseq because it is the best semantic triple editor, and I make extensive use of its query engine (despite it being written in the worst Datalog language in existence). I hope Tine improves the former first, and that in the future we can talk about the latter.

[martinkoutecky]

@hestratos @EllisMorrow — on queries specifically (replies 39–46, and #624): Martin asked me to write down every way a Tine query can give a different answer from Logseq's, with the reason for each. It is now a Guide page, Reference → Tine query model, in the next Tine Beta build. The short version is below. This is Beta behaviour, and it is meant to start a discussion, not end one.

The rule. A query in Tine finds everything the same query finds in Logseq, and may find more — never less. Someone moving a graph from Logseq should never lose a result. Looking at results never changes your files.

Exactly like Logseq (Beta)

• Text in a query is exact: case and accents count, and property lines are included. Ctrl+K and search still ignore case and accents.
• [[x]], #x and (page-ref x) also match the child blocks under a reference.
• Page-header properties count as properties. This is Beta: block queries miss page-header properties, e.g. (property type [[Person]]) returns 0 #624, fixed on Beta.
• Commas split only tags, alias and the keys in :property/separated-by-commas.
• Results sort newest first by default. (sample N) picks before sorting.
• query-table::, a trailing table, query-properties:: and query-sort-by:: are read.

Where Tine finds more

• Property values and names ignore case.
• Numbers and dates compare as numbers and dates, so 01 equals 1.
• A single word finds every block containing it, not the top 30 search hits.
• sort-by knows priority, page, scheduled and deadline.

The one place Tine finds less

• (task) with no marker means open tasks, and (priority) with no level means A/B/C. Logseq returns every block in both cases.

What Tine does not run

• There is no datalog engine. An advanced query runs only if Tine understands every clause. Otherwise the whole query is refused, and the notice names the clauses it did not understand. Half an answer would look complete and be wrong.
• :view and :result-transform never run.
• A query returning more than 20,000 rows or 32 MiB is refused instead of freezing the app.

Kept on your device instead of in the file

• Clicking a column heading to sort, and collapsing a query. Logseq writes both into the file.

Other

• Queries are always live; there is no 50 ms cut-off.
• :current-page in a split view means the pane you used last.
• A query finds blocks or pages. Pages and blocks in the query sheet shows both from the same conditions.
• Tine-only features save as {{tine-query …}}, with an Undo.

Tine 0.6 (stable) has several known bugs here that Beta fixes. Examples: ascending default sort, case- and accent-blind text, every property value split on commas, and advanced queries running only the clauses they understand. The page lists them all.

On #551 (parent/ancestor/descendant): Martin has approved it and it is being worked on for Beta.

If any line above is a divergence you think is wrong, say which one and what you'd expect. That is exactly the feedback the page exists to collect.

— Claude (working on Martin's behalf)

[martinkoutecky]

@hestratos @Dieterbe, a correction about bare (task), the form with no markers. "Do what Logseq does" and "match all tasks" are two different behaviours, and I blurred them above.

• Logseq: a bare (task) adds no condition at all. build-task in query_dsl.cljs returns nothing when there are no markers, so the clause is dropped. On its own, {{query (task)}} matches nothing, and (and (task) [[project]]) behaves exactly like [[project]], non-task blocks included.
• Tine today: a bare (task) means TODO, DOING, NOW and LATER.

The two options:

• A, all tasks (hestratos's proposal). A bare (task) matches every block with any task marker, DONE and CANCELED included. This differs from Logseq. A query copied from Logseq gives a different result only if it contains a bare (task), which Logseq silently ignores.
• B, strict parity. A bare (task) adds no condition, exactly as in Logseq.

Either way, the "carry tasks" button will stop relying on a bare (task) and will name its markers explicitly.

Martin leans to A. @Dieterbe, you have argued that Logseq parity should be the default. Would you make an exception here, and why or why not? Martin is curious where you draw that line, and an exception is a perfectly fine answer. @hestratos, A is what you asked for; say if seeing B spelled out changes your mind.

— Claude (working on Martin's behalf)

[Dieterbe]

Martin leans to A. @Dieterbe, you have argued that Logseq parity should be the default. Would you make an exception here, and why or why not?

I think the more important thing to establish the overall project philosophy and be consistent with that. Martin needs to decide whether Tine wants to position itself as:

1. a drop in-replacement for logseq, meaning users can expect to switch to Tine and everything works as before (except that with Tine they may be able to do more or do it faster, more reliably, etc); any exception to this should be well justified (e.g. doing something the logseq way would be very difficult or complicated) and documented in the user facing guides/documentation: This would be incredibly useful to many people struggling with logseq and looking for an alternative. It also suggests more diligence when designing/building Tine, but works well if we agree that logseq's default behavior(s) are reasonable. In addition to docs, we could also add visual cues with help text on query widgets if the behavior is different. This would help users avoid nasty surprises
2. a better/different version of logseq: we are more liberal with differences, and allow them for other reasons, such as not agreeing with Logseq's behavior(s).

In practice, it may be somewhere in the middle, and where we land is something partially decided up-front, and partially realized/revised as features are developed and trade-off become more clear.

I think compatibility considerations between different tine versions is vastly less important than between tine and logseq. Breaking compatibility between different tine versions is probably expected, but breaking compatibility from logseq requires more thought, since most people are still yet to make the transition from logseq to tine.

For this particular case, I note that it's not just about bare task queries like {{query (task)}}, it's also bare queries like {{query}}; in the latter case, logseq returns nothing, tine returns all pages.
I actually agree that, in the absense of filters, just returning everything (deviating from logseq, and previous tine version) is sensible in principle, but:

• for the {{query}} case, this suggests returning all pages and blocks. We may therefore need safeguards to block execution of bare queries on large graphs.
• it seems we're developing our own query system anyway (tine-query vs query), I suggest that we keep logseq's queries (both simple and advanced) as compatible with logseq as possible (and use a visual cue when we can't), and let tine-query be our "unstable playground" where we can have strong opinions about deviating behaviors, and adjust behavior over time after letting users use it for a while and give their feedback

TLDR: I think the decision around whether or not to allow this query exception should come after figuring out tine's positioning and during the (holistic) design of the query system

[hestratos]

After doing some tests, I want to reason about it.

Take this page as an example (the only page in your graph):

- TODO Task1
- DONE Task2 #A
- [#A] Pri1
- {{query ((or (priority) (task)))}}
- {{query}}

In Logseq, both queries show nothing. The first one shows something like "Not matching results", so it is evaluated as returning no results. The second one shows nothing either (something like "expecting your input"), so it seems to be expecting some operators before it can do any evaluation.

But do any Logseq users actually use queries like these? I don't think so, because one is incomplete and the other is essentially nonsense. The first query should probably be a syntax error, but Logseq decided to treat it as a query that simply returns no results.

So this is the question Martin is asking: Should some nonsense queries in Logseq have meaning inside Tine?

Initially, I said yes. For example, {{query ((or (priority) (task)))}} should return all pages/blocks that have a defined task in any state or a priority in any priority (A, B, or C).

But after thinking about it more thoroughly: what happens if a Tine user goes to Logseq and opens this page that shows no results? Both queries that have meaning in Tine and return something are effectively useless in Logseq. So I changed my mind on this.

Also, the latest 0.7.0-Beta-2 added something like "any state" for tasks. So in Tine, when I build {{query ((or (priority) (task)))}} using its own UI, I can select "Any status" in the task marker. It then translates to: (task NOW LATER DOING DONE CANCELED CANCELLED IN-PROGRESS TODO WAIT WAITING)

The UI shows "Any Status", which is very nice, and semantically this is now backwards-compatible with Logseq. If we add the same "Any priority" concept to Priority, we can have the same meaning there as well. And Tine will translate to: {{query ((or (priority A B C) (task NOW LATER DOING DONE CANCELED CANCELLED IN-PROGRESS TODO WAIT WAITING)))}}, which is backguards compatible to Logseq (and very verbose BTW).

I would apply the same approach to {{query}}: do not execute it in Tine, and instead show something like "No conditions defined" or similar. This would give us the same visual behavior and feedback as Logseq. If we need to retrieve all blocks and pages, we can use Tine's own query system.

So, in conclusion, I changed my mind after going back from Tine to Logseq to check the semantics there. I hope this is clear.
So what do you think?

[martinkoutecky]

@hestratos @Dieterbe Martin has decided this on bare query forms: Tine now follows Logseq.

• A bare (task), (todo) or (priority) adds no condition, and an empty {{query}} shows nothing, exactly as in Logseq. The same page gives the same answer in both apps.
• A form that silently does nothing is a trap, so Tine shows a short note on such a query. Its one-click buttons rewrite the query to explicit markers: open tasks, any task, or A/B/C.
• The query builder always writes explicit markers.

The general rule follows Dieterbe's framing: Logseq query syntax keeps Logseq's meaning. Where Tine can't match Logseq, the Guide documents the difference and the query itself shows it.

This replaces the "every unfinished task" meaning in the current Beta notes, and it lands in a coming Beta. Thanks to you both for pushing on this.

— Claude (working on Martin's behalf)

[Dieterbe]

I hope having the behavioral differences between queries expressed via {{query}} vis-a-vis {{tine-query}} does not lead to too much implementation complexity, but i'm very excited about tine's UI notices where applicable, and also about tine-query being a fresh slate that we can make our own, with an arguably more intuitive query syntax and behaviors

[martinkoutecky]

@hestratos @Dieterbe The bare-query decision from reply 70 is now in Tine Beta 0.8.0-beta.1. This replaces what I said in the "Tine query model" summary above (the line that bare (task) is the one place Tine finds less) and the "TODO, DOING, NOW, LATER" meaning I described earlier.

• A bare (task) or (priority) in a {{query}} adds no condition, as in Logseq. A query that has no condition left, like an empty {{query}}, shows nothing.
• Such a query now carries a short note that explains this and offers Open tasks (every unfinished marker, including WAITING, WAIT, STARTED and IN-PROGRESS), Any task, or A, B or C. Each button rewrites the query with explicit markers.
• Queries with explicit markers are unchanged.

Requirement (raised by @hestratos, @Dieterbe)	Status
Bare (task) / (priority) and an empty {{query}} behave as in Logseq	Done in Beta 0.8.0-beta.1
A visible note instead of a silent empty result, with one-click rewrite	Done in Beta 0.8.0-beta.1
A collapsed query saved as collapsed:: true, with a result-count badge	Not done yet
Saving a column sort to the file	Not done yet
The 20,000-row ceiling; :current-page in a panel as in Logseq	Unchanged; not addressed in this Beta

Confidence: moderate. The note and the rewrite buttons were exercised end to end in the real app on Linux, and the query evaluation has automated tests; I did not check it on Windows, macOS or Android.

Please retest with a page that has a bare (task) or (priority). If a query gives a different answer from Logseq, comment here with the query and the page text.

— Claude (working on Martin's behalf)

[Dieterbe]

seems to work as expected.
You even went beyond the expected design:

• if you combine a constraining clause with a non-constraining clause, it executes fine, though still triggers the warning for the non-constraining clause, which is actually useful I think.
  e.g. here the query correctly returns the 1 matching block.

{{query (and(priority A) (task)}}

• if you query with 2 non-constraining clauses, it offers suggestions for both of them. very nice! e.g.

{{query (and (priority) (task))}}

• my only suggestion is, when all the clauses are non-constraining, it still shows the "No results why empty?" thingie, which should probably be removed in these scenarios

[martinkoutecky]

@hestratos @Dieterbe Following the bare-query decision, Tine Beta 0.8.0-beta.2 applies the same rule (Logseq query syntax keeps Logseq's meaning) to one more divergence: scheduled and deadline date windows.

Logseq's own {{query}} ignores a scheduled or deadline window (between), so such a query gave a different, broader answer in Logseq than in Tine. In beta.2:

• an existing {{query}} with a scheduled/deadline window no longer runs silently. It shows a note and a Convert button that rewrites it to a {{tine-query …}} with the same date window; Undo restores the old text;
• when you edit such a window in the query sheet, Tine saves it as {{tine-query …}} and does not write Logseq syntax that would drop the condition.

Requirement (raised by)	Status
Logseq query syntax keeps Logseq's meaning; differences flagged on the query itself	Done for date windows in Beta 0.8.0-beta.2 (bare (task)/(priority) was Beta 0.8.0-beta.1)
Hide the "why empty?" hint when every clause is non-constraining (@Dieterbe, reply 73)	Not in this release
A collapsed query saved as collapsed:: true, with a result-count badge	Not done yet
Saving a column sort to the file	Not done yet

Confidence: moderate. Unit and core tests cover the conversion and the writer; a real-app run on Linux converted a query, showed results and reopened after restart. I did not check Windows, macOS or Android.

If a query gives a different answer from Logseq, comment here with the query and the page text.

— Claude (working on Martin's behalf)