To support my way of continuous digital note-taking and knowledge gathering, reducing friction to take notes is a must. Therefore, having the app ready on every device I use is essential and it poses a new requirement, the content must always be in sync across all those devices.
Problem: “I need my Logseq graph in sync across all my devices”
- Work Macbook
- Personal Windows Laptop
- Android phone
Some backgrounds about my workflows:
- I’m professionally a Software Engineer and it’s also my area of interest, so my personal and work notes intersect a lot
- I use my work Macbook most of the time and write in Logseq daily to capture work-related notes
- On the weekends or holidays, I play and do my side projects on my personal Windows laptop
- I use my Android phone to make notes on the go. Sometimes I review and make some edits on the phone before I go to sleep
- I’m not good at multitasking or using multiple screens simultaneously. Only one device is usually used at the same time.
Since the Logseq graph is essentially a collection of plain markdown files, my first thought was to just put them all in a Google Drive folder that can be synced seamlessly. However, this approach is far from desired. Google Drive client is proprietary and I am not sure how it handles sync conflict. I have also tried third-party sync apps like Folder Sync but still not satisfied.
Notes: I do aware about Logseq’s built-in sync feature, but my current usage is not enough yet to justify the subscription fee.
Then I decided to use Syncthing, a self-hosted distributed sync server. Seems it ticked the boxes for me:
- It’s distributed, which means there’s no central server needed. All my devices can sync with each other peer-to-peer.
- It supports file versioning
- It creates a backup file on sync conflicts
Looks good? I immediately installed the clients on all my devices. I put the graph folder to be synced to all the devices. Luckily, Syncthing has wrappers for all the OSes I’m using.
The problem is, that my devices are not always available and connected to the internet (for discovery) at the same time. This and other issues like Android client service being paused/killed by a battery-saving feature have made the sync very unreliable. It caused a lot of sync conflicts due to the same file being edited in two places. I want to write and edit quickly everywhere, therefore waiting for the sync to finish every time I want to write something is not desirable.
What’s the possible solution? I added a new always-on “device” which is a cheap DigitalOcean droplet I have already used for my other pet projects. I installed Syncthing using Docker in the droplet and opened some ports so now I have 4 devices, and one of them is always reachable by others. (Sorry non-tech folks, I might cover the detailed Syncthing setup later in another post)
Cool, now I don’t have to worry about lagged device sync. The server Syncthing acts like a central instance. I just need to ensure the DO instance is always up, which I already monitored anyway.
Several days into this setup feels very well. Until I realized sometimes the sync feels very lagged. The bottleneck is not in the sync itself but in the device discovery. By default, Syncthing uses a central relay server to discover other devices and it adds a delay before the sync process itself can start.
How to address this? Here’s what I have done:
- Ensure the server Syncthing only listens on
tcp://0.0.0.0:22000(also open the firewall for this)
- Set up all other Syncthing instances (in laptops and phones) to connect to the server device using a static address. Note that Daisy is my server’s device name.
Now the sync can start very fast and reliably. There have been very few occurrences of sync conflict lately because the files are synced quickly even before I started editing on another device.
- Setup Syncthing in all devices and sync the Logseq folder to all of them
- Introduce an always-on server in the cloud
- Use a static address to connect to the server
- Run conflict resolver script on the server to automatically resolve sync conflict with Git’s 3-way merge
- Run Logseq headless API on the server as an entry point for integration/automation with other services
That’s it. I will update this post with further findings
if I find any 😉