Awesome that you’ve used wails! Is it basically svelte for the front end? Also looks like you’ve written your own block editor - how did you decide on that approach vs using an existing one?
1. React for the frontend. 2. CRDT was essential for device-to-device encryption, and I wanted a fully customizable block editor. So, creating it myself was the only option.
I'm too lazy to build it myself, pre-built binaries will be nice as I would like to give it a spin (I also created a block editor from scratch, in Qt C++ and QML[1] so it's always nice to see new block editors on the block (pun intended)).
> Right now, all these plain text strings are stored in a SQLite database locally on your computer. But we have plans to remove the reliance on a custom database and to store all notes as simple .txt files inside a folder.
I'm curious why would you want to move away from SQLite?
Thanks! I'm not 100% sure about this, still hearing feedback from people on both ends. Some reasons for the switch would be:
1. File versioning
2. Easier self-hosted syncing
3. Better data portability (although we already support exporting to .txt)
I would love to hear counterpoints. Currently, SQLite works pretty well, and our custom database is pretty simple (plus, our database code is also open source[1]).
An encrypted DB will be a differentiator compared to every other offline editor (Joplin et al). It would also appeal to privacy-conscious enterprise users whose laptops may get automatically backed up.
You can support a timed export to text files for those other use-cases.
Indexing/search/relations/performance would be some counterpoints that SQlite already solved.
I have experience with flat file CMS systems (similar usecase) and at some point of complexity you end up rewriting your own database. Once every file has UUID an you have text file indexes of these than you realize you might have gone too far.
But not all projects need that and the argument for version control is big.
Thanks for the input! I'll definitely take this into consideration and research more before deciding. Currently staying with SQlite and pretty happy with it.
Looks great; any plans to add encryption at rest? Use case being sync between personal devices using iCloud or google drive or OneDrive etc. encryption would prevent cloud storage providers from trivially accessing your data
I'm planning to add built-in sync and sharing features (so paying the cost of servers etc). I also thought about it a lot and tried to make it as affordable as possible ($2 a month paid yearly). I'm reluctant myself to pay for subscriptions, but I hope to create enough value for people to jump on the offer. Another thing is that I'm planning to create more cross-platform apps like Plume (with sync etc) and to tie them all under one subscription.
That's so awesome to hear! Notes is very much still alive, with me and other wonderful maintainers still on it. Soon I'll push some performance improvements and some other features (like exporting to .txt) that I developed in Plume into Notes.
I'm putting more of my focus in Plume these days. But Notes will benefit from some improvements in Plume.
EDIT: You can give Plume a try it's using the same database as Notes so you won't have to change a thing (just backup your data please since Plume is in Beta!). And you won't have any fewer features, even tho it has a Pro plan (this only adds features that Notes doesn't have already).
Nice, but I'm a bit wary of data format storage. Can this work just using Markdown-like files on every platform? There's a hint that iCloud storage is used separately.
Yeah. Because it's based on just files, you can work across multiple platforms using shared folders like iCloud storage. However, for merging during simultaneous edits, each note is composed of multiple JSON files and folders.
Not support it currently. However, a single markdown file can be treated as one block. Therefore, all the clues are ready in nb-crdt and nb-editor. One tricky part is the frequent replacement and conflicts of xxx.md files for file-based synchronization. There may be significant differences between file systems. Anyway, I think it could achieve eventual consistency by automatically generating folders like xxx.mds in the same path to manage it.
Yeah, but you lost me then. Either Markdown is the source of truth (and you do the CRDT when one is edited and reconstitute it after) or I won't store my notes in your app :)
I've heard that CRDT needs to be the source of truth for certain features to work (handling users going online/offline?). I was never quite sure why it would not work to just create a new CRDT document from another source of truth (markdown, database, ...) when starting an editing session. Maybe someone else can explain.
i came across somewhere on twitter that if two people are editing the document on notion, only the first one gets saved or something. I didn't get into the details of it but in that case this is already ahead in some ways.
"You can edit the same block as someone else at the same time. Unlike other document software, content is not locked if someone else is making changes to it. The most recent change will be reflected on the page."
"The most recent change will be reflected on the page" implies overwriting, so different opinions may arise depending on the perspective. Anyway, Notion is addressing the shortcomings of overwriting with features like history.
File search is possible with the "/" key, but what you're referring to is searching within notes, right? For cross-device capability, currently, it's possible using shared folders.
If there's a significant number of stars, considering adding these features might be worthwhile!
