GSoC 2026: LAN Sync: research notes and architecture options

Features
1

Hi everyone,

I’m preparing for GSoC 2026 and focusing on the LAN Sync idea. I’ve been digging into Joplin’s sync architecture and previous discussions, and wanted to share some notes and possible directions to get feedback before going deeper.

What I’ve done so far

  • Read the previous LAN sync discussion
  • Studied the sync specs (synchronisation, locks)
  • Looked through the code around Synchronizer, SyncTarget, FileApi, locks, info.json
  • Traced how E2EE fits into the sync flow
  • Tried similar LAN/P2P behaviour in LocalSend, Anytype, and Syncthing
  • Sketched a few approaches that reuse Joplin’s current sync model

Possible architecture approaches

One option is a host-based LAN sync target: one device exposes a small sync service on the local network and others sync to it like Joplin Server/WebDAV. This aligns well with the existing SyncTarget/FileApi design and keeps most sync logic unchanged, but it introduces a “host” device that needs to be reachable.

Another direction is true peer-to-peer sync, where devices connect directly and exchange changes without a central host. This matches the device-to-device idea well, but would likely require larger changes since the current synchroniser assumes a single shared target state (locks, info.json, etc.).

A third possibility is a replicated sync target: each device keeps a local copy of the sync data and a LAN layer keeps those copies in sync (similar to Syncthing). Joplin would still see a normal filesystem-like target, but replication adds complexity around consistency and conflicts.

So the main question is: should LAN Sync fit as a new SyncTarget (like WebDAV/Joplin Server), or as a separate sync mode (peer-to-peer with different UX)?

1 Like
2

In the discussion thread, I think he (mini) wants both P2P and Cloud sync target to work at the same time: Sync LAN - #3 by mini

So I think it's a separate sync mode?

3

I want to make sure I understood you correctly.

With this assumption, you’re suggesting that LAN Sync would run in parallel with the existing cloud sync. If so, it probably shouldn’t behave like a normal SyncTarget (since Joplin currently assumes a single target). Instead, it would act more like an additional sync channel that exchanges changes directly between devices on the same network, while the cloud target remains configured as usual.

So in this case, it sounds closer to a separate sync mode (or layer on top of sync), rather than just another target type.

From a UX perspective, that raises a couple of questions:

  • The user would configure LAN alongside their cloud sync target?
  • When devices are on the same LAN, should sync prefer LAN, cloud, or both?
  • If LAN becomes unavailable, should it automatically fall back to cloud?
4

I was just looking for LAN.

Thanks!!

1 Like