Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am more and more reluctant to use any note taking app. Ideally, notes I take on the book I am reading today should still be available to me in 20 years. No app can offer that kind of guarantee. I switched to using plaintext files, and do not look back. The only thing one needs is to have a clear workflow to make sure notes remain accessible and useful. I like the Zettelkasten method for this (see eg https://zettelkasten.de, no affiliation).

Not to criticize this app in particular, I actually quite like the concepts listed (which remind me of the Zettelkasten idea). Just the whole idea of keeping my thoughts in an app. Even if it does allow to export the data, it is probably in a format that is difficult to use outside of the app, and thus close to useless.



> notes I take on the book I am reading today should still be available to me in 20 years. No app can offer that kind of guarantee

Emacs + Org Mode

You can be sure Emacs will still be around in 20 years and Org Mode stores notes in text format.


If only I could figure out a way of scribbling with the iPadPro pen and get it into org mode.


I wouldn’t bother. I’ve always found it easier and better (for reinforcement) to transcribe my notes/drawings into org-mode.


throw in org-roam and you've got a real solid zettelkasten

https://github.com/jethrokuan/org-roam


I want to copy paste screenshots and images. Ideally it should store the screenshot in a folder and automatically link to it. Do you use anything like that?


> No app can offer that kind of guarantee.

Actually the one I'm developing offers that [1], as it stores notes as plain Markdown files on disk, it doesn't get any more future-proof and no vendor lock-in than that.

[1] https://notable.md


i just tried it and i cannot figure out how i use media with the app. even just a simple embedded image i cannot get to work (i never see the image). drag&drop an image from firefox into a note doesn't work either (nothing happens after i drop it).


That part of the app is a bit rough still, that kind of drag & drop interaction isn't supported yet.

If you're under macOS you can copy/paste images to attach them.

Otherwise you can add attachments by clicking the attachments icon (the little clip) and then clicking "Add attachments...", and then link to them via the special `@attachment` token mentioned in the tutorial [1]. Or you could have an attachment wherever you want in the file system and link to it like you normally would inside Markdown.

[1] https://tutorial.notable.md/


indeed, i am on a mac.

i dislike the attachment solution since that is a vendor lockin and you were mentioning lack of that. if i use attachments and special virtual paths like "@attachment" i restricted from editing my notes with anything but your tool. ios is then obviously gone too. This defeats the purpose of being dropbox-syncable (or at least reduces its usefulness).


Well you don't have to use that if you don't want to.

The "@attachment" (and "@note") thing is actually pretty useless today, but it will solve a real problem tomorrow, namely: how do you make links always work even if the resource they are pointing to gets renamed? Which is worth solving IMHO.


Why would you need an attachment for this? Couldn't you 'refactor' the notes instead? Not sure that vendor lockin is worth it. The problem is worth solving but IMO you are going about it the wrong way.


You might be right, but it's not as simple at it sounds.

By using something like `@attachment/UUID` you don't have to refactor anything if the attachment gets renamed or modified. The somewhat unsolved issue there though is reliably keeping track of which UUID maps to which file.

If you're using regular links and rename an attachment, worst case scenario, you have to parse all notes, find all links pointing to the renamed attachment and update those, which can get expensive. Also regular path-based links can be a problem when you move the _note_ somewhere else too.

Plus how do you know something got renamed instead of the old attachment got deleted and a new one got created? This is partially a problem for the UUID-based approach too however.

Lastly what kind of link should you use to link to a note stored in another data directory? Relying on the absolute paths is too brittle, and it won't work at all when the app will also be able to run in the browser.


I think this is very common.

Genuine question: what, if anything, could a note-taking app do to assuage this fear?

e.g., is there something extreme that would help like giving you example notes to run through the export process during onboarding, or maybe even an automated export to an email every number of days so that if the app shuts down, even if you do nothing, you'll still have your data.

I'm asking because I recently launched an app in precisely this space (https://www.notefuel.com - it's a note-taking app dedicated specifically to learning, kind of like Readwise.io meets Evernote), and I totally understand this worry, have it myself, and would invest in mitigating it.


Nothing. To satisfy the programmer type users who claim their file type independence: 1. Just give the users a nice pdf export with lots of options. 2. iOS files integration , so that we can save directly into a repo program ( Ie working copy)


Can you give me an example of a repo program in this context - would that be something like Dropbox? So you'd have our app installed, it outputs to Files periodically, which in turn is syncing with Dropbox or some other service with file history functionality?


Yeah. I really like the beauty of the iOS Files api - it acts as a very convenient bridge.

So, supposing Dropbox has a sync with the files api, then that sync would be the responsibility (and implemented by) the Dropbox app. All you need to is ensure that you write into Files api properly (Ie don’t leave any locks around on files, etc - I’m not an iOS developer so I have no idea what’s actually required for very good/correct Files api interoperation, but it should be in Apple docs).

With a git repo program like Working Copy, you’d just write into its Files space (same as above for Dropbox), then Working Copy handles the syncing. Since Working Copy has no such auto sync as something like Dropbox would have, since WC is a git repo app and not a cloud files service, the user would manually open it themselves and make a commit and push it at their own choosing. Any writes to WC in the meantime will just overwrite. That’s all understood by the user , if he’s using a git repo as his files backup. I prefer manually syncing my files as commits to a repo, so this all works beautifully for me .

I don’t like placing the security of my synchronization in the hands of cloud files providers such as Dropbox or Google Drive. I use multiple iPads and laptops at once, so google drive and Dropbox bugs in sync may bite me. For notes this is best for me, since note update frequency of one to five times an hour doesn’t need any auto sync. But most users, even programmers, that I know don’t seem to enjoy this level of exactness.


> Ideally, notes I take on the book I am reading today should still be available to me in 20 years.

Personal opinion : I think this is not the right way to look at knowledge. What you think as "knowledge" today will only be data for algorithms in 10 years. Some knowledge today won't be useful in 5, 10 o 20 years from now.

The best way to validate knowledge is to share it and review it with peers as quickly as possible. Ideally, you would make your notes public and they would be easily findable by anyone, so anyone can continue your work at anytime.

Note taking for long term retrieval doesn't make sense in a world of internet and machine learning. In the future, you will just enter a question in a text box and algorithms will search inside billions of documents, deduce facts and write an essay to answer your question.

To me, note taking only makes sense for very short term "todo", or when to listening to someone speak. "Note taking" when reading a book is called "annotating", and they are training data for ML algorithms (not for your brain)


> Note taking for long term retrieval doesn't make sense in a world of internet and machine learning. In the future, you will just enter a question in a text box and algorithms will search inside billions of documents, deduce facts and write an essay to answer your question.

That is a narrow view of the reasons people take notes on books. One might want to save one's personal impressions of a piece of fiction, ideas about superficially unrelated concepts that suggest themselves, etc.


I agree. Note taking can be about identifying facts, interesting ideas or arguments but it can also be about arguing with the author, making links or recording your own understanding. The activity of taking notes, for me, is really about codifying your understanding of a section of text.


I'm torn between a pleasant UX and a portability/low bus-factor of the system I'm using. I don't take any long-term notes in LT though, just some quick ones from text books. I eventually plan to transcribe those somewhere else — still looking for the perfect app to use for the Zettelkasten method.


Check out if https://zettlr.com (FOSS, Markdown) could be useful to you - I know it specifically has some support for Zettelkasten, though I never was able to understand what this thing means.


OneNote has been around since 2003. I have been using it since 2004. Not 20 years but close.


yeah, I had the same issue and used a few markdown editors and landed on JOPLIN. Joplin has some good integration with online backups and semi-decent encryption setup.

notable was quite impressive until *(Notable was originally released as open-source but newer versions of it are no longer open-source.) and for apps I use often I try to keep them FOSS.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: