Rendered at 16:26:05 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
DenisM 24 minutes ago [-]
Sometimes I ask the agent why it gave a certain answer, when I feel it overly fixated on something. It would be cool if the ui hilighted the poisonous part of the conversation somehow.
Esras 7 minutes ago [-]
But agents don't _know_ why they gave an answer. They can only give "reasoning" that links to something in their context, and even then, you would have to parse out their response with some heuristics to try to match against something upstream of that turn.
I could see it being done, and if you're fond of the "models all the way down" mode of thinking, you could use a smaller model to identify it, but it could just as well be a "load-bearing seam" (ha) for something else in the conversation.
embedding-shape 6 hours ago [-]
This seems like a really interesting idea and something I've basically been doing myself manually so far, with a DESIGN.md document with "one concept/decision per line, built in a tree" basically, where all decisions that needs to be remembered gets noted down for future reference.
Not a fan of ThoughtDAG being a complete separate application rather than built into the tools I use every day, like my text editor or other planning tool. But neat that you've seemingly integrated a bunch of LLM providers, including letting us use local models, sufficiently sweet :)
Some security "nitpicks": I'm fairly sure you have a critical security issue in the "execSync(`pdftoppm -png -r ${dpi} ...`)" call you do, which I don't think would have been a issue if the local web server you start listened to 127.0.0.1 or some other local IP, but instead it seems the server binds to 0.0.0.0, meaning all network interfaces. Put together, anyone who runs this application effectively gives anyone else a free shell to your computer :)
Tiny nitpicks about the AppImage specifically, seems it's missing publisher details/signing (not a huge deal, just something you might want to look into) and also it's using "--no-sandbox", don't think you need that, let it be sandboxed instead, and the remote vulnerability above might also become less of an issue :)
I'll hold off a bit to play around with it, because of the issue above, but I'm curious to see if it does provide something more than what I manage with my ASCII Markdown tree of decisions. Maybe there is potential for ThoughtDAG in the future to be better integrated with other tools, and end up mostly being the management/viewer of things, so I can continue using vim and codex as today, but they can read/write via ThoughtDAG perhaps, or some other approach.
Regardless, thanks for sharing it and good luck! :)
fractorial 2 hours ago [-]
Irrespective of opinions about a project or its authors, disclosing a potential security issue in a public forum is markedly not responsible disclosure.
chatchan 52 minutes ago [-]
[dead]
1 hours ago [-]
4 hours ago [-]
4 hours ago [-]
chatchan 4 hours ago [-]
[flagged]
urvader 9 hours ago [-]
What about cache? When you change the context the prefill stage will be much slower?
esperent 7 hours ago [-]
That's always going to be a trade off with anything like this so I guess it's better to think of it as an alternative to compaction.
Another use case that comes to mind is that sometimes I'll include some detail early in a conversation and I mean it as incidentals information but the AI fixates on it. If I could selectively edit that out rather than start a whole new conversation it would be worth the cache miss.
chatchan 2 hours ago [-]
[dead]
olejorgenb 5 hours ago [-]
I think many providers store the cache such that you can reuse any prefix, so it might not be as bad as you naively expect.
chatchan 6 hours ago [-]
I have not noticed a measurable slowdown in practice so far, including canvases with around a hundred nodes. A request only includes the wired ancestors of the current node, not the entire canvas, so node count alone is not a good measure of prefill cost.
That said, your concern is valid for very long contexts. Editing an early ancestor may reduce prefix-cache reuse, while pruning a branch also makes the resulting prompt shorter. ThoughtDAG does not manage its own KV cache today, so this is something I need to benchmark properly rather than claim is solved.
Have you encountered this mainly with local models or hosted APIs?
kruxigt 8 hours ago [-]
[dead]
mikeebener 2 hours ago [-]
I looked at the repo and demo canvas. Nice work. Especially liked the 3 semantic zoom tiers and the weave/condense features. If you're enabling for less-technical users consider leading with weave and condense vs. edge deletion. Edge deletion is where the model is powerful but my Mom would get stuck there for instance. The idea that removing a wire changes what the model actually sees might not be obvious.
Consider when someone clicks a node, show a sidebar listing (node references)with remove buttons to reframe as 'what does this answer know about me" vs. "edit of the graph".
Love the graph for power users but listing can be the explanation layer.
chatchan 41 minutes ago [-]
Thank you for carefully reviewing the repo and demo; this suggestion is very insightful. Currently, the node sidebar already has a context list grouped by material, reference, and dialogue, but it's collapsed by default and doesn't directly exclude content. Your suggestion to "make the list an explanatory layer" perfectly points out the missing element.
I also agree that Weave and Condense are easier for new users to understand than simply removing connections. The diagram can continue to serve as the underlying structure, while the sidebar answers the question more intuitively: "What content will be used in this answer?"
esperent 7 hours ago [-]
The basic idea here looks interesting and is easy to understand but what I'm not understanding is why it's a standalone app. Is this supposed to replace e.g. Claude desktop? Or can it plug in to other systems like Claude Code, Codex, Pi?
I don't think I'd want to use it as a standalone app but I would certainly be interested in it as a plugin.
chatchan 1 hours ago [-]
Thank you for your feedback!
Just want to know. What would be the smallest useful integration for you: allowing the host tool to read the currently selected context, or bidirectional access so it can also create, branch, and prune nodes?
chatchan 4 hours ago [-]
[flagged]
myshapeprotocol 3 hours ago [-]
An editable context graph for LLM conversations is a brilliant primitive for managing complex workflow states. Great Show HN project.
chatchan 1 hours ago [-]
Thank you!
4b11b4 2 hours ago [-]
is this a loom
chatchan 7 minutes ago [-]
If you're referring to the loom analogy, then it's quite similar: you choose which threads to weave into the next context; unwanted threads can be unraveled :)
mashapps 6 hours ago [-]
Can this integrate with replit?
chatchan 4 hours ago [-]
[dead]
Zongming 7 hours ago [-]
This looks like git, doesn't it?
chatchan 6 hours ago [-]
I can see the Git analogy in branching, merging, and preserving provenance. But in use, I think it feels closer to a mind map or Miro than to version control.
Thought does not need an explicit commit, and branches do not have to resolve into a clean merge. They can remain divergent or unfinished.
The part I care about most is that the graph is operational rather than decorative: its edges determine which branches become context for the next inference.
dominotw 3 hours ago [-]
nice. i was going to develop something like this for my own learning pattern
I read the discussion you linked. The Transformer and MLP examples you gave illustrate the learning process I hope ThoughtDAG can handle: entering a branch along a question without disrupting the main thread; understanding it before deciding which content to bring back, rather than letting the entire exploration automatically pollute the subsequent context.
If you'd like to try it, I'd love to know if it matches your original vision of the learning method, and where it might still interrupt the process. If convenient, please share a screenshot of the anonymized canvas, an anonymous export, or a short screen recording. Seeing a real learning process would be very helpful for improving ThoughtDAG.
angoragoats 3 hours ago [-]
See also this post (“Every Fucking Website, Slop edition”):
Analogy: Textual version of Material Design from Google.
Standardization in important information rich environment is good. Standardization for art is not good. We should not mix these two distinct scenarios. Or maybe I am old.
angoragoats 2 hours ago [-]
> Analogy: Textual version of Material Design from Google.
What? The post I linked to is talking about the layout and appearance of the page, in addition to a few textual elements.
> Standardization in important information rich environment is good.
Why is this good in general? And specifically, how is standardizing on e.g. a meaningless status indicator (that doesn't really indicate the status of anything) "good"?
Besides, this is not standardization, it's statistical models (LLMs) converging on a design for arbitrary and likely inscrutable reasons, without understanding the meaning or purpose behind design.
darrmit 3 hours ago [-]
Had the exact same thought. It’s like reading a foreign language – and I’m going to be honest – not load bearing at all.
chatchan 10 minutes ago [-]
Thank you for pointing out this issue. The homepage did indeed use too many common landing page elements before actually showcasing the product. I redesigned the homepage, removing status labels, promotional slogans, and unnecessary entry points, making the interactive context graph the main focus of the page.
chatchan 12 hours ago [-]
Hi HN, I built ThoughtDAG around one rule: wires are the context.
Each question and answer is a node. When you ask from a node, only its wired upstream nodes are included in the model request. Delete an edge, regenerate, and that branch leaves the model's actual context, not just the visualization.
The interface is intentionally human-controlled. I'm testing whether explicit context control is useful for long-running research, or whether most people would rather delegate memory selection to retrieval.
It is MIT licensed, local-first, supports Ollama and OpenAI-compatible endpoints, and includes PDF clipping with page provenance.
I'd especially appreciate criticism of the interaction model and onboarding.
agumonkey 7 hours ago [-]
have you seen other people or project on the same idea ? manipulation history and exploration space of LLM seems to be quite important
olejorgenb 5 hours ago [-]
Zed's early text threads allowed you to edit the full history as a document.
chatchan 6 hours ago [-]
Yes, I have seen several adjacent approaches. Microsoft Huabu explores spatial interaction around research materials, while LLM Canvas and tldraw’s branching-chat experiments explore visual conversation trees.
Many workflow canvases also use nodes and edges, but they usually represent execution pipelines. The specific interaction I am testing is more narrowly about context: an edge changes what the model receives, while removing it keeps the earlier work visible but excludes it from the next inference.
I would be interested in other projects I may have missed.
embedding-shape 6 hours ago [-]
It would be wonderful if you included a section like "ThoughtDAG vs X" in the README, where you then compare ThoughtDAG against these other approaches/tools, and explain with some clear concise words how it's different than those. For extra bonus-points, also explicitly list where ThoughtDAG falls short (today?) and compare to them in that manner too :)
chatchan 8 minutes ago [-]
Thank you for your suggestion. I've added a "How ThoughtDAG differs" section to the README. Rather than listing specific products one by one, I ultimately chose to compare them based on interaction methods because the functional boundaries of many products are still evolving.
If you have time to take another look, I'd also like to know if the differences are clear and concise enough now.
I could see it being done, and if you're fond of the "models all the way down" mode of thinking, you could use a smaller model to identify it, but it could just as well be a "load-bearing seam" (ha) for something else in the conversation.
Not a fan of ThoughtDAG being a complete separate application rather than built into the tools I use every day, like my text editor or other planning tool. But neat that you've seemingly integrated a bunch of LLM providers, including letting us use local models, sufficiently sweet :)
Some security "nitpicks": I'm fairly sure you have a critical security issue in the "execSync(`pdftoppm -png -r ${dpi} ...`)" call you do, which I don't think would have been a issue if the local web server you start listened to 127.0.0.1 or some other local IP, but instead it seems the server binds to 0.0.0.0, meaning all network interfaces. Put together, anyone who runs this application effectively gives anyone else a free shell to your computer :)
Tiny nitpicks about the AppImage specifically, seems it's missing publisher details/signing (not a huge deal, just something you might want to look into) and also it's using "--no-sandbox", don't think you need that, let it be sandboxed instead, and the remote vulnerability above might also become less of an issue :)
I'll hold off a bit to play around with it, because of the issue above, but I'm curious to see if it does provide something more than what I manage with my ASCII Markdown tree of decisions. Maybe there is potential for ThoughtDAG in the future to be better integrated with other tools, and end up mostly being the management/viewer of things, so I can continue using vim and codex as today, but they can read/write via ThoughtDAG perhaps, or some other approach.
Regardless, thanks for sharing it and good luck! :)
Another use case that comes to mind is that sometimes I'll include some detail early in a conversation and I mean it as incidentals information but the AI fixates on it. If I could selectively edit that out rather than start a whole new conversation it would be worth the cache miss.
Consider when someone clicks a node, show a sidebar listing (node references)with remove buttons to reframe as 'what does this answer know about me" vs. "edit of the graph".
Love the graph for power users but listing can be the explanation layer.
I also agree that Weave and Condense are easier for new users to understand than simply removing connections. The diagram can continue to serve as the underlying structure, while the sidebar answers the question more intuitively: "What content will be used in this answer?"
I don't think I'd want to use it as a standalone app but I would certainly be interested in it as a plugin.
Just want to know. What would be the smallest useful integration for you: allowing the host tool to read the currently selected context, or bidirectional access so it can also create, branch, and prune nodes?
https://news.ycombinator.com/item?id=49263169
If you'd like to try it, I'd love to know if it matches your original vision of the learning method, and where it might still interrupt the process. If convenient, please share a screenshot of the anonymized canvas, an anonymous export, or a short screen recording. Seeing a real learning process would be very helpful for improving ThoughtDAG.
https://news.ycombinator.com/item?id=49302737
Standardization in important information rich environment is good. Standardization for art is not good. We should not mix these two distinct scenarios. Or maybe I am old.
What? The post I linked to is talking about the layout and appearance of the page, in addition to a few textual elements.
> Standardization in important information rich environment is good.
Why is this good in general? And specifically, how is standardizing on e.g. a meaningless status indicator (that doesn't really indicate the status of anything) "good"?
Besides, this is not standardization, it's statistical models (LLMs) converging on a design for arbitrary and likely inscrutable reasons, without understanding the meaning or purpose behind design.
Each question and answer is a node. When you ask from a node, only its wired upstream nodes are included in the model request. Delete an edge, regenerate, and that branch leaves the model's actual context, not just the visualization.
The interface is intentionally human-controlled. I'm testing whether explicit context control is useful for long-running research, or whether most people would rather delegate memory selection to retrieval.
It is MIT licensed, local-first, supports Ollama and OpenAI-compatible endpoints, and includes PDF clipping with page provenance.
GitHub: https://github.com/chenxiachan/thoughtdag
I'd especially appreciate criticism of the interaction model and onboarding.
If you have time to take another look, I'd also like to know if the differences are clear and concise enough now.