Idea: new type of account to synchronize data with some kind of cloud storage instead of Evernote

[d1vanov]

It seems that Evernote service in general is in a slow but steady decline. People on the Internet are complaining about their increased prices for personal and premium tiers and rumor has it that free tier is going to be ~~crippled~~ limited to a single notebook and 50 notes, at least for new users. And existing free tier users won't be able to create new notes.

I use free tier myself and it perfectly fits my own (rare) usage of the service. If it becomes that much crippled, I guess I'd have to migrate somewhere. And it would immensely hurt me to have to abandon my own creation - Quentier.

So I thought of the following: the primary tasks of Evernote service from API perspective from Quentier's POV are as follows:

1. Respond to client's queries of sync chunks i.e. provide pieces of data within the certain range of update sequence numbers (see this doc for overview of Evernote's synchronization protocol)
2. Respond to client's requests for full data for particular notes, including content and attachments (these are omitted from sync chunks)
3. Respond to client's requests to create some new data item within the service - new note, notebook, tag, saved search etc. The service should assign guid and update sequence number.
4. Respond to client's requests to update some existing data item within the service. The service should assign new update sequence number.

One other thing which Evernote service does is recognition of text in image attachments but for the moment I'd omit that part. I don't use this functionality myself and for my workflow it's not of critical importance.

So I thought that all of the above listed tasks are not really that hard to implement using some cloud storage like

• Google Drive
• One Drive
• Dropbox
• Yandex Disk
• SpiderOak
• OwnCloud
• Git repository
• literally anything else, you name it

Rough idea how this service could be implemented on top of any kind of cloud storage: the primary task of the storage layer is the ability to store items (i.e. CRUD operations) and to provide a list of all stored data items sorted by update sequence number. So one simple idea of how to organize storage: each notebook makes a folder with note folders inside it. Tags perhaps could be stored as files in a separate folder, same for saved searches. And there's one top level manifest text file each line of which consists of three values: update sequence number + guid of the item + type of the item (note, notebook, tag, saved search, resource/attachment). Type of the item could be encoded with a number just to make the line shorter. The lines in this file would be sorted by the first column - the update sequence number. This way each line would consist of several dozens of bytes tops. Even for massive storages of tens of thousands of items this file would not be larger than a couple of megabytes so it would be fast to download and parse. Using the contents of this file the service would easily find out what content to include into particular sync chunks queries and easily assign new update sequence numbers to new and updated data items. Retrieving the contents of notes would be a matter of just downloading a bunch of files from the cloud storage.

The best part is that if the server is implemented correctly, the client part should work pretty much the same way as it currently does while communicating with Evernote service, there wouldn't be anything that needs to be rewritten on the client side i.e. in current Quentier's code.

It would of course be quite a major undertaking which would take me months if not years to finish but it still looks promising to me. Having accomplished that neither myself nor users of Quentier would be bound to the single service which at the moment doesn't seem like it's in a good enough shape.

[charlescanato]

This looks absolutely awesome, Dmitry! To be true, when I've tried Quentier since a week ago, I thought something like this when I saw you had the local account type. And thought why storage couldn't be in parallel to what Obsidian does - as you wrote (well, much more detailed lol)

With storage logic and API access separation, it seems just natural to achieve. Of course, easy to write, much harder to code. 😊

Seems you got a nice solution draft!

I just hope I keep this momentum of wanting to contribute. Certainly as a test user in the beginning, hope to be able to contribute some small code in a few months.