4 ms·

Show HN: ByteSync – Open-source hybrid file sync (LAN and remote, E2EE)

4 points by paulfresquet 11mo ago

Hi everyone, I've been developing ByteSync, an open-source file synchronization, backup and deduplication tool designed to bridge the gap between local and remote sync. In spirit, it's somewhat closer to FreeFileSync, but with an integrated networking layer and end-to-end encryption — which means you can synchronize files between computers on the same LAN or across the internet without VPNs or firewall setup. Everything works transparently through the same interface. The synchronization model is based on DataNodes (which represent repositories, such as servers or NAS devices) and DataSources (the folders or files inside them). A session can include multiple participants, each with one or several DataNodes, and ByteSync handles all comparisons and transfers automatically. To optimize performance, the engine uses a two-stage inventory process: an initial indexation followed by comparisons limited to items that actually changed. This keeps synchronization fast even with large datasets. There's also a flat mode, useful when structure doesn't matter and you just want to compare or align files by name. Currently, ByteSync is focused on interactive synchronization — it's not yet automated or daemon-based (CLI integration is planned). But it's already fully functional for discovering and managing differences between repositories, both local and remote. ByteSync runs on Windows, macOS, and Linux, and the entire codebase is available on GitHub: https://github.com/POW-Software/ByteSync https://github.com/POW-Software/ByteSync You can also download binaries and read the documentation here: https://www.bytesyncapp.com https://www.bytesyncapp.com I'd really appreciate feedback and contributors — whether on usability, architecture, or ideas for future features. The goal is to make a solid, privacy-respectful alternative for hybrid file synchronization that remains simple to use and open for everyone.

paulfresquet 11mo ago
A bit more about the design philosophy and how ByteSync may differ from other synchronization tools: ByteSync is meant to give users control and visibility over what’s happening. Instead of syncing in the background, it operates through explicit sessions — you decide when and how synchronization occurs, selecting which changes to apply and in which direction before any transfer happens. This makes it particularly useful for data management, backups, or multi-location setups where you need to understand what’s being moved before it happens. Each session defines one or several DataNodes (repositories) and DataSources (folders or files). For example, you might have a local workstation with a DataNode containing project folders, a NAS with backups and archives, and a remote server for off-site replication. All of them can be part of the same session, compared and synchronized through end-to-end encrypted exchanges. This model keeps things explicit while still supporting flexible topologies — local or remote, single or multi-participant. When synchronizing over the internet, transfers go through a temporary encrypted buffer in the cloud, used only as a relay for data exchange. All content is protected with end-to-end encryption (E2EE) — nothing is stored or accessible on the relay, and data exists there only for the duration of the transfer. This allows remote synchronization to work seamlessly without VPNs, firewall rules, or manual network setup. Under the hood, ByteSync relies on full desktop clients for Windows, Linux, and macOS, along with cloud components that handle orchestration and temporary relaying when needed. A command-line mode is also planned, and the design work for it is already underway. Performance-wise, ByteSync uses a two-stage inventory process: an initial indexation phase that collects file size and modification timestamps, followed by a comparison phase that computes block-level signatures only for files that show differences. This avoids redundant network round-trips and dramatically improves performance in remote scenarios where latency would otherwise make full scans impractical.
johng 11mo ago
Looks neat, a benchmark page comparing it to other tools would be great. Ie, how does it compare to the speed of rsync? Others?
- paulfresquet 11mo ago
  Thanks! About benchmarks: I don't have formal speed comparisons yet. ByteSync started by using a C# port/rewrite of the classical rsync algorithm, so the delta algorithm and hashing logic are very similar in spirit. The main difference is the surrounding architecture. Where rsync works as a point-to-point stream tool, ByteSync adds: - a two-stage inventory (size+timestamp scan + signature computation when needed) - E2EE on every remote transfer - orchestration and compression on the fly - hybrid routing (LAN direct or encrypted relay when remote) - session-based modeling with DataNodes/DataSources This means that in remote scenarios, ByteSync avoids many of the round-trips that kill performance when latency is high. It also computes signatures only when needed, not systematically. So I can’t claim ByteSync is “faster than rsync” — rsync is extremely optimized in its domain — but in hybrid or high-latency setups, ByteSync often behaves better because it avoids unnecessary passes and works with a more structured model of the data. Benchmarks are something I'd like to add. Perhaps once automation and CLI are ready, because it'll make comparisons much easier to run and publish.
johng 11mo ago
I think this is really neat and wish it would get more traction here. Short of upvoting it, which I've already done..... is there another way. I worry this may have just been posted at a bad time (late friday, early saturday) and missed some attention.
- paulfresquet 11mo ago
  Thanks, I appreciate it. You're probably right about the timing. No worries though, I'm mainly here to get feedback and answer questions. If anyone has thoughts on hybrid sync models, session-based workflows, or the DataNode/DataSource design, I'm very interested in hearing them.

4 points by paulfresquet 11mo ago

paulfresquet 11mo ago

A bit more about the design philosophy and how ByteSync may differ from other synchronization tools: ByteSync is meant to give users control and visibility over what’s happening. Instead of syncing in the background, it operates through explicit sessions — you decide when and how synchronization occurs, selecting which changes to apply and in which direction before any transfer happens. This makes it particularly useful for data management, backups, or multi-location setups where you need to understand what’s being moved before it happens. Each session defines one or several DataNodes (repositories) and DataSources (folders or files). For example, you might have a local workstation with a DataNode containing project folders, a NAS with backups and archives, and a remote server for off-site replication. All of them can be part of the same session, compared and synchronized through end-to-end encrypted exchanges. This model keeps things explicit while still supporting flexible topologies — local or remote, single or multi-participant. When synchronizing over the internet, transfers go through a temporary encrypted buffer in the cloud, used only as a relay for data exchange. All content is protected with end-to-end encryption (E2EE) — nothing is stored or accessible on the relay, and data exists there only for the duration of the transfer. This allows remote synchronization to work seamlessly without VPNs, firewall rules, or manual network setup. Under the hood, ByteSync relies on full desktop clients for Windows, Linux, and macOS, along with cloud components that handle orchestration and temporary relaying when needed. A command-line mode is also planned, and the design work for it is already underway. Performance-wise, ByteSync uses a two-stage inventory process: an initial indexation phase that collects file size and modification timestamps, followed by a comparison phase that computes block-level signatures only for files that show differences. This avoids redundant network round-trips and dramatically improves performance in remote scenarios where latency would otherwise make full scans impractical.

johng 11mo ago

Looks neat, a benchmark page comparing it to other tools would be great. Ie, how does it compare to the speed of rsync? Others?

paulfresquet 11mo ago
Thanks! About benchmarks: I don't have formal speed comparisons yet. ByteSync started by using a C# port/rewrite of the classical rsync algorithm, so the delta algorithm and hashing logic are very similar in spirit. The main difference is the surrounding architecture. Where rsync works as a point-to-point stream tool, ByteSync adds: - a two-stage inventory (size+timestamp scan + signature computation when needed) - E2EE on every remote transfer - orchestration and compression on the fly - hybrid routing (LAN direct or encrypted relay when remote) - session-based modeling with DataNodes/DataSources This means that in remote scenarios, ByteSync avoids many of the round-trips that kill performance when latency is high. It also computes signatures only when needed, not systematically. So I can’t claim ByteSync is “faster than rsync” — rsync is extremely optimized in its domain — but in hybrid or high-latency setups, ByteSync often behaves better because it avoids unnecessary passes and works with a more structured model of the data. Benchmarks are something I'd like to add. Perhaps once automation and CLI are ready, because it'll make comparisons much easier to run and publish.

johng 11mo ago

I think this is really neat and wish it would get more traction here. Short of upvoting it, which I've already done..... is there another way. I worry this may have just been posted at a bad time (late friday, early saturday) and missed some attention.

paulfresquet 11mo ago
Thanks, I appreciate it. You're probably right about the timing. No worries though, I'm mainly here to get feedback and answer questions. If anyone has thoughts on hybrid sync models, session-based workflows, or the DataNode/DataSource design, I'm very interested in hearing them.