Sync does not have to mean uploading. How peer-to-peer sync moves notes straight between your own devices, how conflicts get resolved, and where it falls short.
· Privacy & Ownership · 7 min read
Ask someone how their notes get from their laptop to their phone and you'll usually get one word: cloud. It has become the assumed mechanism, to the point where "works offline" and "syncs between devices" sound like opposites. If the notes are on a server, they can be everywhere; if they're on your machine, they're stuck there. Pick one.
That framing is a habit, not a law. Two devices that can both reach the internet can also reach each other, and when they do, notes can move directly from one to the other without a copy ever landing on a company's disk. This is peer-to-peer sync, and it has been quietly practical for years. It's worth understanding for the same reason it's worth knowing that sync is not a backup: the mental model determines which failures surprise you.
In the familiar arrangement, no device ever talks to another device. Each one talks to a server, which holds the authoritative copy. Your laptop uploads changes; your phone downloads them later. The server is a mailbox that never forgets and is always awake.
That single design decision buys three things that are genuinely hard to get otherwise. Devices never need to be online simultaneously, because the mailbox waits. Any new device can be caught up from one place. And a company can operate, monitor, and repair the thing.
It costs three, too, and they're structural rather than incidental. There is a full copy of your notes somewhere you don't control. There is a service that can change price, terms, or existence. And you need an account, which means your identity is now attached to your writing by construction.
The alternative is direct connection. Your laptop and your phone establish a link between themselves and exchange changes over it. No intermediate copy is stored, because there is no intermediary — just two devices that both already have the notes, reconciling their differences.
The obvious objection is that home networks and mobile carriers put both devices behind routers that block unsolicited incoming connections. This is real, and it's solved by a technique called NAT traversal, which works roughly like an introduction at a party. A small public server — a signaling server — helps the two devices learn how to find each other: each one reports the addresses it can be reached at, the signaling server relays those addresses to the other, and then both devices attempt a direct connection simultaneously, which routers accept because it now looks like outbound traffic on both ends. Once the link is up, the introducer is out of the conversation entirely. In browsers this whole mechanism is standardized as WebRTC, the same transport behind video calls, and the direct channel is encrypted by default.
The distinction that matters: the signaling server sees connection metadata — that two devices want to talk, and roughly where they are — but never note content. Your writing crosses one hop, from your device to your other device.
The costs are just as concrete. Both devices must be online at the same time, because there is no mailbox to hold changes for a phone that's in a drawer. Some networks defeat direct connections — restrictive corporate firewalls and certain mobile carriers — leaving pairing to fail with no obvious cause. And there is no server-side copy, which is the entire point and also means the architecture offers you nothing when both devices are lost at once.
Any sync system faces the same hard question. You edited a note on your laptop this morning. You edited the same note on your phone at lunch, offline. Tonight they meet. Which one is right?
The naive answer — last write wins, compare timestamps, newest survives — is the wrong one, and clock skew is only the shallow reason. The deep reason is that a timestamp cannot distinguish later from newer. If your phone never saw the laptop's edit, its version isn't an update to that edit; it's a sibling. Overwriting one with the other silently discards work that no human ever chose to discard.
The standard fix is a vector clock: instead of one timestamp, each note carries a small counter per device — "laptop has made 12 edits, phone has made 3." Comparing two of these answers a better question than "which is later?"
Most syncs are the first case, resolved silently and correctly. The second case is rare, and it's the one where a tool's character shows. Good behavior is to keep both versions and tell you. Bad behavior is to pick one quietly, which is indistinguishable from working perfectly right up until you notice a paragraph missing weeks later.
Peer-to-peer's requirement that both devices be awake together is a real ergonomic tax. There's a hybrid that removes it without reinstating a company's server as the home of your notes: put a single sync file in cloud storage you already control — your own Drive, your own object store — and have each device merge against it.
The mailbox is back, but you own it. Devices no longer need to overlap in time. The merge logic is the same vector-clock reconciliation used on a direct link; only the transport changed. And the sync file doubles as a recovery path when a device dies.
Two honest caveats. The storage provider now holds a copy of your notes, so this is a weaker privacy position than pure peer-to-peer — better than an app-operated server holding it, since the account and the notes are at least not the same vendor's, but not the same as nothing. And if the sync file itself gets corrupted by a bad merge, every device merges the corruption. That's why versioned snapshots of the sync file matter more than they sound like they do.
Indenta implements both channels, which makes it a convenient thing to look at concretely: devices can pair directly over an encrypted WebRTC link — one shows a connection ID, the other enters it, and note content flows only over that direct connection — or sync through a single file in your own Google Drive's hidden app-data area, invisible to the rest of your Drive. Both paths merge with the same vector clocks, and each Drive sync first snapshots the previous file, keeping about five, so a bad merge is recoverable rather than terminal. The User Guide has the setup for both.
Rules of thumb, in the order they usually matter:
You will never think about NAT traversal while writing a note, and you shouldn't have to. What's worth carrying away is narrower: "my notes are on my devices" and "my notes are on all my devices" were never in conflict. The cloud is one implementation of sync — the one that happens to also require a company, an account, and a copy of your writing on a stranger's disk. It's a reasonable trade, and plenty of people should take it.
But when a tool tells you it syncs without uploading anything, that isn't marketing sleight-of-hand. It's a different arrangement of the same problem, with a different set of things that can go wrong — and now you know which ones.
Try it in practice: Indenta is a free, offline-first outliner — nested notes, backlinks, tags, and peer-to-peer sync, with no account required. Start writing in your browser, or read the User Guide first.