kenforthewin

It's a shame because I think there a lot of valid, thoughtful critiques one could level at the Rat/EA community; but this was not that.

A study by MIT found that students who use AI to write show far less brain activity than those who used classic Google searching (with AI off) or those who used neither. Other studies find that students who use AI retain far less of the information that ends up in their writing, possibly as a result of “cognitive offloading” and “cognitive surrender.”

I'm unconvinced that AI will make us all dumber. In the public perception, at least among students, AI is viewed as a cheating tool. What kinds of students gravitate towards cheating tools to complete their coursework?

On the other hand, the opportunity for AI to act as a personal tutor, meeting you at your own skill and knowledge level, is limitless.

The site is performing poorly for me. For example, the login page took 9 seconds to load, same with the home page.

I have no idea what happens next if we create and horizontally scale superintelligence; one thing I do know for sure is it won't be "business as usual".

I'm working on Atomic Cloud, the hosted version of my open source knowledge graph project. https://atomicapp.ai/cloud/

That's a much less generous interpretation of his writing. "Yes we will birth superintelligence, but everything will just sort of work out for us humans". This seems like a silly take to me.

I felt the same way in 2024-2025. Then Sonnet 4 was released, and things started feeling different. Opus 4.5 was another step change for me. Everything feels like it's accelerating, and timelines are getting crunched. I guess in some ways I envy OP, who would "bet everything" against ASI - the truth is I don't know, and I don't think anyone knows, where this ends.

I was able to repro one issue that could have been contributing to your broken experience - there's a slight delay between, for example, clicking text in a heading and having the "#" markdown decoration appear. This is to prevent the mouse location from shifting mid-click and causing text to be selected unintentionally (obsidian does this too). But there was a bug that was causing a cascading set of failures if edits happened during that delay window, which is likely what folks who are clicking around at random points in the editor and adding text are doing. I fixed it in 0.4.2, which should be live now.

Thanks for trying it out! would you mind giving some steps that allow me to repro the issue? It's early days so i'm sure there are some rough edges, hopefully I can fix them quickly.

Thanks for the heads up - I pushed up a fix to the hightlighting issue.

I originally went with Milkdown (Prosemirror-based) for Atomic, the knowledge base project that I built Atomic Editor for. ProseMirror doesn't provide virtualization out of the box. For shorter notes and even moderately long content it's fine - but atomic supports syncing content from a diverse set of sources and I noticed that long documents were causing delays on initial page load and some lag during edits. I didn't find anything like it with native virtualization that felt right to me so I built Atomic Editor.

The weepiness and persecution complex is overwhelming.

Could you expand on the "substantial ops burden"? Let's say you're using a managed Postgres instance as the underlying data store, how substantial is the ops burden in that case? I understand that temporal is actually a set of 4 or so microservices on top of a data store, but if you're already running a distributed system backed by k8s or something like that, it doesn't seem like it adds significant incremental ops on top of that. But I could be wrong.

Looks like this comment is touching a nerve. This community is progressing from "AI can't write code", to "Well, AI can write code but it's not really about the code". I wonder where the goalposts will be moved next?

Tauri is great! this is my first Rust-based project and it took some real getting used to. But i love that Tauri does not ship with an entire chromium browser, and i love its focus on security.

nice username :)

fair point, the app makes requests to load fonts. we'll fix that next release.

Local first means running Atomic with local models is not an afterthought. It’s a first class citizen that works just as seamlessly as running with a cloud provider - assuming you’ve done the work to provision the local models and their connections yourself.

This is .. honestly a great synopsis of Atomic and its design tradeoffs. Thanks! Giving commonplace a look.

One can imagine an obsidian plugin of any arbitrary level of complexity, given it's written in a Turing-complete language.

I'm not sure I understand the question. Regardless of what provider you choose - be it cloud based or local - you have to provide setup information such as host, authentication, etc. So it "defaults" to nothing; you have to select something.

Thanks for the feedback. Yeah, I admit copywriting is not my forte. i'm a solo dev, I'm focusing most of the time and energy on the product itself. There are always 100 things I could be polishing for Atomic - social media presence, website, docs, etc. even with AI there just aren't enough hours in the day - you have to triage somehow.

It has supported local LLMs from the beginning, it was not something that was just tacked on. I don't know what else to tell you. Your assumptions are just wrong.

Atomic supports any generic openAI compatible LLM provider, including ollama, LM studio, etc.

Atomic supports any generic openAI compatible LLM provider, including ollama, LM studio, etc.

Did you think local-first meant how a dropdown is sorted?

OpenAI-compatible is indeed one of the provider options for Atomic. Ollama and openRouter are separate options to allow for easier selection of models from these specific providers.

I'm not sure what the dunk is supposed to be here .. Atomic supports the exact same feature set with local models as it does for OpenRouter. Is your gripe just that Openrouter is the first option in the dropdown?

working on it https://github.com/kenforthewin/atomic/tree/main/mobile/andr...

Biggest difference is Atomic leverages an LLM to auto-tag and a text embedding pipeline to drive semantic search - so the knowledge base is self-organizing. The bet here is that having an agent grep the filesystem is fine for a carefully curated, relatively small set of markdown files. It starts to degrade if you approach your knowledge base as a place to put everything: personal notes, articles you find interesting, entire textbooks if you want to. Having a vector database in this context is pretty much required past a certain scale; a filesystem-based approach is just an incredibly inefficient way to do retrieval in this context, and your agent is bound to miss important data points.

Nice work, couple bits of feedback

* The editor doesn't seem to support code fence literals (as in I can't type ``` to get a code block)

* At very large markdown file sizes the performance is not great.

I'm building an obsidian-style markdown editor (for my own AI knowledge base product!) over at https://github.com/kenforthewin/atomic-editor

Hey HN - built this markdown editor because I couldn't find anything open source that was quite as slick as Obsidian's editing experience. I'm using it in Atomic, my ai-powered knowledge base tool. https://github.com/kenforthewin/atomic

repost?