3 ms·

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 QM

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)). [1] https://www.get-plume.com https://www.get-plume.com

mritchie712 2y ago
Plume looks awesome! > 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?
- rubymamis 2y ago
  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]). [1] https://github.com/nuttyartist/notes/blob/master/src/dbmanager.cpp https://github.com/nuttyartist/notes/blob/master/src/dbmanag....
  - omnimus 2y ago
    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.
    - rubymamis 2y ago
      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.
  - jjnoakes 2y ago
    I think plain text files also integrate nicely with other tools. Desktop search, external editors, etc.
    - rubymamis 2y ago
      Yes, that's also a good point.
  - ukuina 2y ago
    I would suggest going all-in on SQLite and even encrypting it on disk: https://sqlite.org/com/see.html https://sqlite.org/com/see.html 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.
    - rubymamis 2y ago
      Noted, thanks!
drevil-v2 2y ago
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
- rubymamis 2y ago
  Indeed! It's part of the plan once we get to work on built-in sync.
rvense 2y ago
Hey! You're not developing Notes anymore, then? I use it every day and I'm very grateful for it. Plume looks great, good luck with it.
- rubymamis 2y ago
  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).
pizzafeelsright 2y ago
Now that looks awesome. Why no perpetual?
- rubymamis 2y ago
  Thanks! 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.

mritchie712 2y ago

Plume looks awesome! > 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?

rubymamis 2y ago
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]). [1] https://github.com/nuttyartist/notes/blob/master/src/dbmanager.cpp https://github.com/nuttyartist/notes/blob/master/src/dbmanag....
- omnimus 2y ago
  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.
  - rubymamis 2y ago
    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.
- jjnoakes 2y ago
  I think plain text files also integrate nicely with other tools. Desktop search, external editors, etc.
  - rubymamis 2y ago
    Yes, that's also a good point.
- ukuina 2y ago
  I would suggest going all-in on SQLite and even encrypting it on disk: https://sqlite.org/com/see.html https://sqlite.org/com/see.html 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.
  - rubymamis 2y ago
    Noted, thanks!

drevil-v2 2y ago

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

rubymamis 2y ago
Indeed! It's part of the plan once we get to work on built-in sync.

rvense 2y ago

Hey! You're not developing Notes anymore, then? I use it every day and I'm very grateful for it. Plume looks great, good luck with it.

rubymamis 2y ago
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).

pizzafeelsright 2y ago

Now that looks awesome. Why no perpetual?

rubymamis 2y ago
Thanks! 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.