A blog post explaining the journey of building the Colanode sync engine. Colanode is an open-source and local-first collaboration platform.

I’m working on Colanode, which is built to close the gap between the convenience of cloud tools and the ownership of local software. It brings chat, docs, databases, and files into one open-source, self-hostable workspace where data lives on your devices first and syncs in the background. Unlike typical SaaS tools, Colanode is local-first: everything works instantly and offline, infrastructure stays minimal, and you keep full control of your data.

Website: https://colanode.com Repo: https://github.com/colanode/colanode

Nice post! I'm building an offline-first collaboration app and went on the route of building a custom sync engine, mainly because the app is open-source and I didn't want to introduce any dependency. I've implemented a simple cursor based sync with Postgres on server and SQLite in client side.

Initially I built only a desktop client, because I didn't like IndexedDB. After the app got into HN, someone recommended to check for OPFS (Origin Private File System).

Now we have a full offline-first app in web using SQLite on top of OPFS. We didn't test it with large scale yet, but so far looks very promising. The good thing is that we use Kysely as an abstraction for performing queries in SQLite which helps us share most of the code across both platforms (electron + web) with some minor abstractions.

You can check the implementation in Github: https://github.com/colanode/colanode

Depending on your data model, LiveStore is a completely open-source, SQLite based approach for local first sync-y apps: https://livestore.dev/

It's oriented around event sourcing and syncs the events, which get materialized into local table views on clients. It's got pretty slick devtools too.

I did look into it back then, but was not very convenient for my use case. Apart from the data model, I wanted to use Yjs for conflict resolution and wanted more direct control over the sync.

p.s Just wanted to say thank you for all the contribution you do here on HN. Colanode (the app I'm building) is an alternative to Notion and I learned a lot about how you (Notion) build things through reading your comments.

Thanks for pointing it out. Will check our build and release process to fix it.

Thank you! I haven’t used Notesnook personally, but from their description it focuses mainly on note-taking. Colanode, by contrast, also includes collaboration features such as chat, file sharing, and databases. One other difference is that Notesnook offers end-to-end encryption, whereas Colanode does not (at least for now).

We have been thinking for some automation/workflows to be executed on specific events. Do you have any example/use case that you might be interested in?

My 2c: A particular thing about notion that bugs me is that hn page content get imported as simple. tables and in notion there is no automated way to delete all empty cells of all tables on page, that make it unreadable, or just to convert tables automatically into text

That's an interesting idea. Didn't plan it, but we could implement some kind of custom theme functionality.

Hi, thanks for bringing this up! We don’t have export or migration features in place yet, but we are planning to add them. Which export formats would be most useful to you? And when you mention migration, are you thinking about moving data from similar tools into Colanode or vice-versa? If so, which specific tools would you like to be able to migrate to/from?

Different person but my prios for export:

1. Versioned export/backup which will be guaranteed to work with current Colanode version

2. ..., well-documented

3. ..., with migrations so it's always future-compatible

4. ..., human-readable

I think integrations with any specific other tools should be ezpz if the fundaments are solid!

For import/insert, I guess some cli API with similar properties would be a nice fit.

(Coincidentally I think the above is also what would facilitate LLMs to do a decent job for anyone trying that)

The first export type implemented should be as minimal and human readable as possible (text files for most content, maybe w/ minimal markup). If that's not possible for all data, then standard formats like html or pdf.

After that, go after your biggest competitor. If people know they have a path back to a familiar shore they're less scared to swim in new waters.

You have to offer export consistent with your import tools or you demonstrate lock in by design.

This gets around version drift with binary export formats.

Static export, as PDF or other non-native markup format is not what is required. This is hard copy, not backup.

Hi, thanks for the question! I haven’t used Huly extensively to provide a detailed comparison, but from a quick look (and a test I did some time ago) it seems to take a more opinionated approach: features such as issues, projects, and overall layout are pre-defined. Colanode, by contrast, works like Notion, giving you flexible building blocks so you can model your own workflows and knowledge structures. Huly may be quicker to get started with, while Colanode offers greater adaptability over time (this comes down to personal preference). Another key distinction is tech architecture: Colanode is built around a local-first design, providing full offline support with background syncing. I haven’t found equivalent offline capabilities documented for Huly, even though they may have them.

Nice!

An issue I’ve had with Huly self-hosted is upgrading, which is very hard because it is not documented (as far as I know).

How are upgrades handled on your project?

Hi, thanks for the question! Yes, we do plan to implement mobile apps, but we don't have a concrete timeline yet. It depends on the limitations and challenges we might face when we implement the same local-first approach as we did in desktop (full offline support, background syncing etc).