Maybe this is obvious to other readers, but I love this portion of it. I think it's one of the critical details to making things like this work. It's easy to built a tool that you "just remember to use" but the issue then the tool is implicitly asking the user to modify their workflow, which isn't always trivial. So well done.
Another simple example: one of my favorite features in Slack is /remind. It can do recurring reminders, reminders way out into the future, and is as simple as typing `/remind me "do the thing" in 6 months`. Critically, it's in Slack which I'm using all the time anyway. It's not tucked away into a calendar I won't look at, or in a place I have to remember to get to. It's right there, and it's really easy to set another one up. I've thought about building a separate tool to replicate this, but I know it will never have the same utility without being in an existing workflow.
Obsidian is a knowledge base, what you are describing is a note taking solution. Might work for most people who just want to scribble things down, but once you start having information you want to inter-connect, it'll break down.
- Tree-shake your notes each time you iterate them. You'll leverage your excitement and it won't be a chore.
- Maintain part of your notes public, it will be a catalyst to polish them. A git repository is perfect for that. Serendipitously, I started a related thread a couple hours ago: https://news.ycombinator.com/item?id=28895647
The nice thing about both gjots2 and Zim, is that their source files read almost as easily as text. This is especially true for gjots2.
I like the hierarchical arrangement of gjots2. I still have Ctrl-F if I want to search, but sometimes in browsing a category, I find things I would not have found with search -- sometimes how I refer to things changes with time -- and I've got many years of gjots entries.
I do not, as gjots author Bob Hepple does, keep separate topics in separate gjots files -- one big tree in the left panel holds all topic headings.
Dokuwiki stores its pages in plain text, with a syntax designed to be readable in a text editor, outside the wiki.
Personally I like that notes are raw and stay raw. I even force me to not use capital letters to remind me of this.
But of course very often they are used as a draft for something more elaborate.
I tried using a database for personal notes many years ago and the problem I discovered was that I can't do a quick Ctrl+F to find previous scraps of knowledge.
Instead, I use plain "notes.txt" and use the editor's text search functions (including regex functionality) to locate things.
These 2 ways of finding text have very different ergonomics:
- SQL: select * from notes where description like '%ubuntu config%';
- text editor: Ctrl+F "ubuntu config" <press Enter>
Yes, one can write a program to "dump" the SQL database to a text file for subsequent search by a text editor. The problem is that it creates a read-only file that you can't edit-in-place. And one can also write a custom wrapper program in whatever language as a GUI for the database but now we're way past your simply "reply to email" paradigm and expending a lot of effort in "yak shaving" instead of just taking notes.
Not saying your system is bad for you but I'm guessing that most people would find the friction of a SQL database too high for freeform notes.
Something that I find not only true, but inherent in relational databases: they require some kind of schema, and schemas for freeform text and ideas are notoriously difficult.
I created my own software, which doesn't have a fancy gui or anything, but organizes my notes sufficiently for me, using plain markdown files and dumping the contents into an ElasticSearch index configured for text analysis. I can easily do a very good full text search on the body of the notes, plus I've indexed the keywords for each note in their own mapping.
In addition to having good linking together of related ideas, wiki-like, it's good to have the ability to fruitfully search without the restrictions of exact term matches. Even relatively simple things like stemming and common synonym matching* can improve the usability of a large collection of notes measurably.
*No, I don't think we've really solved the searching by synonym problem. More work is needed.
However I kind of like the fact that it's hard to edit, and I (almost) never do it. It's a log -- the log of my brain.
With a db it is trivial to order posts either in the order of the days or in the write order, etc. With only a text file that would be very difficult.
Obsidian’s business model is really smart: creating a knowledge management system that applies to the vast majority of use cases, add room for a little modularity, and monetize it.
However for those edge use cases, which on HN might be closer to a majority, it’s important to first hash out exactly what sort of features you need.
Do you need to link files as well as notes in a knowledge graph?
Do you need to use advanced search filters?
How much data are you dealing with?
Just some food for thought.
Here’s their pricing page for more info: https://obsidian.md/pricing
This seems unnecessarily complex - have you considered replacing this with rsync + cron job?
It's also in effect a poor man's backup, because the db is renamed with today's date so each copy doesn't overwrite any other.
[0] Edit: not in fact true. The email part uses Mailgun's API (from when you could use routes with a basic account).
I used to use a SaaS that did exactly the but unfortunately they shut down after a few years. I still have my notes in Gmail since they were just emails but I miss getting the reminders.
P.S. I like your description of this as your log of your brain.
Fortunately my routes were already set up and still work on the Flex plan; I just can't edit them any more; but they were pretty generic so that's not too much of a problem for me; but it would be a problem for a new implementation.
Also, the code isn't pretty and since I built it for myself, it doesn't have any security feature whatsoever (no login, no sessions, no encryption, nothing).
I don't think I want to deal with all the people who would tell me how bad my code is if I published it... But for me it works.
- - -
That said, sending emails is the easy part; it's dealing with incoming email that requires a better Mailgun plan (not just for routes but for parsing the content of the email).
If you only need a system to send you an email every day you can 1/ open a Flex account with Mailgun (no recurring fee, pay-as-you-go email) and 2/ setup a cronjob with a short script in any language that can do a POST request; here's my example in Python.
request_url = "https://api.eu.mailgun.net/v3/yourdomain.com/messages"
request = requests.post(request_url, auth=("api", mailgunKey), data = {
"from": "sender <[email protected]>",
"to": emails,
"recipient-variables": json.dumps(recipients),
"subject": "%recipient.task% [%recipient.day% %recipient.date%]",
"text": body
})
The Mailgun API is well documented and fairly simple to use: https://documentation.mailgun.com/en/latest/api-sending.html...(There are certainly many other providers that do the same thing.)
- - -
PS: I'm surprised of the interest though; last time I talked about it on HN it didn't generate that many replies; someone did indeed mention a similar SaaS that folded for lack of growth. I think it's one of those things where all potential users are already here on HN...
It's actually been 3 years, not 2! Lockdown messed with our perception of time...
It is surprisingly effective at storing not just what I did with my day, but random thoughts and ideas, solutions to bugs, etc. All I have to do is type something every day.
In 2 years I have typed around 150k words. For reading he whole thing is just one plain html page, searchable in the browser.
I'm currently experimenting with documenting my reading, while the book is being read (instead of a summary at the end). We typically forget what we expect while we read, and only remember the final impression. Taking notes at the end of each reading session, not just about what I just read, but also about what I think will happen next, and revisiting that later, is surprisingly interesting.