Until now, every Ripplic pipeline started at a local folder: FSEvents watches it, and every change replicates one-way to the destinations you choose. The next update moves the starting point into the cloud — Google Drive can be a source.
Google Drive ──▶ Cloudflare R2
──▶ Amazon S3 / MinIO / B2 / GCS (any S3-compatible)
──▶ another Google DriveFiles flow from Drive directly to your destinations. There is no server in the middle — your Mac is the only conduit, and credentials never leave the macOS Keychain. That has been Ripplic's promise from day one, and cloud sources don't bend it.
The third pipeline reads from a Google Drive folder and replicates to an Amazon S3 bucket in us-east-1 — mid-transfer at 15.5 MB/s. Each pipeline stays independent; a slow destination never blocks the others.
Detecting changes without a server
A local folder can push events to the app. A cloud can't — Google's push notifications require a public HTTPS endpoint, which means running a server. Ripplic doesn't do servers, so it uses the other primitive Drive offers: the changes.list delta feed.
Google's servers keep a journal of everything that changes in your Drive. Ripplic holds a cursor into that journal and asks, every 30 seconds, "what happened since here?" The answer is the change list — and a new cursor, which persists on disk so the feed resumes exactly where it left off after a relaunch, with no rescan.
The property that makes this scale: a quiet poll costs the same regardless of how big your Drive is. One small HTTPS request, whether the folder holds a hundred files or a hundred thousand. When something does change, the cost is proportional to the number of changes — never to the size of the tree.
Events are hints, not facts
Ripplic's engine treats every change event as a hint: something worth verifying, never something to act on blindly. Each hinted path is checked against Drive's actual metadata and the pipeline's local index before any transfer starts. Dropped events, duplicated events, out-of-order events — all harmless. A periodic full comparison backstops everything, so correctness never depends on catching every event.
This also gives clean answers for the messy cases: a file renamed in Drive hints both the old path (handled by your delete policy — flag-only by default, nothing is ever deleted without your say-so) and the new one. A folder rename shifts every path underneath it, so the engine falls back to a full re-scan of the tree — graceful degradation, not an error.
What if your Mac was offline for a week?
Say Ripplic is closed — or your Mac is asleep — while hundreds of files change in Drive. Catching up doesn't mean replaying history. On launch, every pipeline runs a full comparison first: each file's checksum and size against the pipeline's local index. Only what actually differs transfers, and a file edited a hundred times while you were away uploads exactly once — the final version.
Then the delta feed resumes from its saved cursor, and Google replays everything since. Most of it was already handled by the comparison — and that's fine, because duplicate hints are harmless by design. If the pause was so long that Google expired the cursor entirely, the source simply takes a fresh one and asks for another full pass. Graceful degradation, not an error.
One detail makes this crash-proof: the cursor only persists after its batch is fully processed. If the catch-up itself gets interrupted, the next launch resumes from the last completed position. Nothing is ever skipped.
What about drift?
There's another way things go stale: someone bypasses Ripplic and touches the destination directly — deleting a few objects in the S3 console, say. Day-to-day reconciliation compares the source against the local index and deliberately doesn't audit the destination on every pass, so this kind of drift is normally invisible. For it, Ripplic has a separate audit path: "Verify Destination Now" in the pipeline menu, plus an automatic audit when a pipeline is re-enabled.
The audit is simple: for every file the index believes is synced, confirm the object still exists at the destination and its size still matches. Anything missing or mismatched gets its sync state cleared — and the next pass re-uploads exactly the damaged files, nothing else. Repair always flows from the source outward; the destination's state is never written back. One-way is the iron rule, and drift repair is no exception.
Today the audit verifies existence and size; next up, it will lean on the block-level hashes Ripplic already keeps to compare content directly, plus scheduled audits (daily or weekly, run while idle). The goal stays the same: you shouldn't have to trust that nobody touched the destination — one click should prove it.
Nothing downloads unless it actually changed
Drive reports an MD5 checksum and size with every file's metadata. Ripplic compares those against its index to decide what changed — no content ever downloads just to find out it was identical. When a file does need to move, it streams in bounded chunks, so a 20 GB video and a 2 KB note get the same, flat memory footprint.
Read-only by design
Connecting Drive as a destination asks for drive.file — Ripplic can only touch files it created itself. A source is the opposite problem: it must see your existing files, so it asks for drive.readonly. Read-only is the point: a Ripplic source is never written to. One-way means one-way, whether the source is a folder on your desk or a Drive in the cloud.
One honest limitation: Google Docs, Sheets and Slides have no file bytes to replicate — they exist only as cloud documents. Ripplic skips them rather than exporting approximations.
When it ships
Google Drive as a source is in testing now and arrives in an upcoming update, alongside the current sources (local folders and external drives) and destinations. Dropbox and OneDrive follow the same blueprint — the engine already speaks "delta feed" natively.