[ COMMUNITY UPDATES ] AeroFTP: Major Milestones, Checkpoint, and Thank You #271
Replies: 10 comments
-
|
Follow-up: the forum vote As mentioned above, this is the dedicated section for the forum idea. Single question, clean vote, two-week window. The question (two parts):
How to vote
Credible platforms (pick one, or propose your own)
Why not Discord or live chat: different paradigm. Live chat creates an expectation of near-realtime presence that is hard to sustain for a small maintainer team. Forum threads can sit for 24-48h between replies, chat cannot. Async first, chat later if community size makes it sustainable. If we go forward: domain Timeline: ~2 weeks then I call it based on what the community signals (yes/no lean + platform preference combined). Thank you for the vote, whichever way it goes. |
Beta Was this translation helpful? Give feedback.
-
|
Isn't the .aeroftp file format a backup of all the profiles? Or is it also a script file? How does it work? Can it be both? It's a bit confusing. |
Beta Was this translation helpful? Give feedback.
-
|
Similar to #145, I'd like to ask: what uses for Rsync are there? I've read that this is meant to be a really fast one-way sync transfer protocol. Something like this. |
Beta Was this translation helpful? Give feedback.
-
You are right, and the confusion is on us, not on you. Today the
So the two formats are operationally distinct (GUI double-click goes to profile import, CLI There is also a third related format that does NOT share the extension and is unambiguous: The right fix is to give the batch script its own extension so the collision is gone. The leading candidate is You caught an obvious problem that slipped past me during development, exactly because the two features grew on parallel tracks (one inside the GUI export flow, one inside the CLI scripting subcommand). Same extension, different formats, and I never sat back and asked whether they should collide. Thanks for raising it. A quick example of what a The full list of commands (17 today: SET, ECHO, ON_ERROR, CONNECT, DISCONNECT, GET, PUT, RM, MV, LS, CAT, STAT, FIND, DF, MKDIR, TREE, SYNC), the variable expansion rules (single pass, injection-safe), and the |
Beta Was this translation helpful? Give feedback.
-
Good question, and not a duplicate of #145. Before listing the use cases, a bit of backstory on how the engine fits into the project, because the "why does it exist" answers the "what is it for" half by itself. Where the need came from AeroFTP shipped first with AeroSync, a sync engine that compared local and remote by size, mtime and checksum, then transferred the full file whenever the two sides differed. Solid and predictable, but expensive on bandwidth for large files where only a small part changed: you re-upload the entire file even if you only edited 1% of it. The natural next step was delta sync: only move the bytes that actually changed between the two versions. The classic implementation of that idea is the The Windows problem Windows does not ship with an AeroRsync (the answer to that gap) AeroRsync is a clean-room re-implementation of the rsync wire protocol 31 in pure Rust, so AeroFTP can speak the protocol natively to any standard So the chain is: AeroSync (full-file sync) → delta sync via classic rsync (faster, but Unix-only) → AeroRsync (delta sync that also works on Windows, no external dependency). Now to your original question, the actual use cases. When AeroRsync helps the most
When AeroRsync does NOT help
Current scope of the engine in AeroFTP AeroRsync today is a single-file delta accelerator that can be chained inside a multi-file batch. It is not a recursive tree sync like the classic
You can reach the engine from three places: the AeroFile Sync dialog (Compare / Plan / Sync tabs, the unified one introduced in v3.8.4), the AeroSync local-to-local panel under View, and the CLI ( If you want a concrete walkthrough, the live KPI run that backs these numbers is in the internal closure report referenced in v3.8.0 release notes, but the chart in the original post above (the side-by-side bar chart in the original post above) is the same data visualised side by side (full upload vs delta on the wire). Hope this clarifies the boundary between "where it is the right tool" and "where it is not". |
Beta Was this translation helpful? Give feedback.
-
|
I only disliked your 2nd comment because you asked for it, not out of disrespect of course. Without mentioning names, I had bad experience, both recently and years ago on the forums of specific apps outside of GitHub. Issues like getting ignored and also technical like not being able to make an account. Not being able to create an account happened multiple times, it's crazy that this is a recurring issue on those platforms. There is a specific forum that particularly pisses me off, because when I began programming for the first time roughly 6 years ago, I went there to ask basic questions. I did my due diligence, web-searching for answers before asking. Of course, AI wasn't really a thing at the time. And they disliked my questions! 👎 These were good questions for a beginner to ask. I don't understand how it's even allowed to dislike the questions of newcomers on these forums 😡 At any rate, I don't go there to these forums anymore, it's a waste of time and just negative. I use AI to get my answers and it's so much better, and getting better all the time. I actually tried to contribute to multiple other projects before even posting my first question here of #110. No one owes any work to anyone else in the world of open source, and I get it, but I just felt unappreciated there. And when I posted #110 and then several more posts here, I couldn't believe that I'm actually getting responses, appreciation and my feedback gets turned into progress. It felt amazing. Foreign. Unreal. And then being named as a contributor is peak. And the rest is history. So thank you for that. I understand that other projects have hundreds and even thousands of open issues on GitHub so they can't pay attention to as many users. I still don't understand how it is that AeroFTP has significantly fewer issues being posted than other projects. I don't think it's just a smaller community, I think you also code things correctly the first time so there are fewer issues. Also, some other devs I'm sure are also very responsive, but I just don't have as much feedback to give to their project, as their apps seem mostly complete at this point. At any rate, although I'm open to other platforms, I don't feel the need to move now. We're getting a lot of progress done here, and moving can split the community. Imagine getting an issue posted here or there, and then having to politely explain that this was already answered in the other forum and the user should've searched both platforms before posting. This will be more work as the community grows. It's also not needed, as I'm sure that big projects manage just fine by staying in only one platform. I still have the negative association with forums, and this can turn into that experience again in ways we don't anticipate. I think that having another platform just means more maintenance work for you, and more browser tabs open for contributors who want to see all the posts. Also, moving is something that's normally done to limit how many posts users make when there are too many because the project becomes so big. This isn't the case here, and will probably just be a hurdle. Some projects, but again I don't want to mention names, require posting an issue on their forum first before being allowed to post it later somewhere else like on GitHub, which you can't even do because their website sucks and you can't even create an account and you can't move the post from the forum to GitHub before others discuss it in the forum, but you get ignored in the forum. It's a comically terrible experience and I no longer wish to try to contribute to these projects like I tried in the past. By the way, if you do decide to make a forum, please try to avoid these issues like:
I think the strongest case for moving in the future should be if GitHub becomes problematic. Like in the case of the Ghostty dev that is leaving GitHub. Perhaps you'd like to write why this isn't an issue with you but was with him, if you've heard the recent news of him migrating away from GitHub. I actually did think before that maybe the structure of issues in this repo should be improved, and I did think about it possibly migrating out of GitHub like other projects, but I dislike that idea for the reasons I just listed, and here are my suggestions instead for improving things here: Wishlists: Roadmap(s): AeroVault: |
Beta Was this translation helpful? Give feedback.
-
|
Hey, over the past day I had 3 occurrences of having bad experience regarding the closing of issues:
So yeah, GitHub is imperfect. For now, I'd like to ask: can you please grant me whatever permission is needed to reopen issues, at least for the posts I created? Instead of reopening #216 for me, if you grant me permission to reopen issues, I'd like to try it to see if it works for the future as well. |
Beta Was this translation helpful? Give feedback.
-
Staying on GitHub. I'm fully aligned. I floated the idea only in case it helped organize topics better, but running a second platform is real maintenance work, splits the community, and risks recreating exactly the frustrations you described. I'd rather invest that time in the app itself. Better use of GitHub itself. One thing I'd like to lean into more is GitHub Discussions. An Issue can be converted to a Discussion in one click, so we can keep Issues for bugs and concrete feature requests, and move open-ended threads (protocol tips, "how would you do this", longer design conversations) over there. Same platform, no new accounts, no split, just a cleaner separation. I'll enable it and seed a couple of categories. Wishlists. Your reform makes sense. From the next one I'll scope wishlists to small, quick enhancements only: anything that needs real design discussion (like #224) gets its own dedicated Issue. That way nothing gets buried just because the wishlist is waiting on a big item. Roadmaps. Agreed. I'll rename #162 to focus it on the Wrappers / Overlays track (where your AeroVault v4 ECC co-design lives), and open a separate Roadmap - Mobile App thread for the phone work. Keeps each scope readable and lets us close one without dragging the other. AeroVault. Same logic. AeroVault-only issues should land in the dedicated On the forum-design checklist you wrote (no manual account approval, no "forum first" requirement, no dislike on newcomers): I've taken note of all of it. If I ever do revisit the idea years from now, those are exactly the failure modes I want to avoid. |
Beta Was this translation helpful? Give feedback.
-
|
I prefer By the way, is part of the idea of a script file dedicated for AeroFTP, to implement my suggestion #133 (comment) of exporting and importing AeroSync settings script files? Perhaps this should be an option, and it might possibly be easier for you to start of with that, before moving to .ps1 and .sh. |
Beta Was this translation helpful? Give feedback.
-
|
I am also skipping the deprecation period I had floated in my previous comment. AeroFTP has under a thousand users per release and a much smaller subset that actually runs On your second question, exporting and importing AeroSync settings as runnable scripts (your #133 suggestion): yes, the dedicated script format is the natural home for that, and you are right that an AeroSync-scoped export is a more concrete first use case than a general scripting playground. I went ahead and shipped both directions alongside the rename, rather than splitting them across releases:
Both changes are already in Thank you for catching the |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
We have been moving at an incredibly fast pace over the last few weeks, and have shipped several large features across the stack. I want to take a moment to recap what we have achieved and outline our next steps.
Recent Major Implementations
Delta Sync (AeroRsync): the native AeroRsync engine, a clean-room Rust implementation of the rsync wire protocol 31, is enabled by default since v3.8.0. It powers single-file delta uploads and downloads with streaming end to end (no in-memory cap, kill-9 safe via atomic temp file), batch session reuse across a multi-file run (one SSH session instead of N), and live KPI archived against rsync 3.4.1. It is integrated with the AeroSync engine, including the new local-to-local lane (LocalDeltaTransport, bypasses SSH entirely) and the unified AeroFile Sync dialog introduced in v3.8.4 (Compare, Plan, Sync tabs in one place).
What this looks like in practice. Imagine you have a 32 MB file on your home server (a video edit, a database dump, a CAD project). You tweak about 5% of it locally, then re-sync. With a classic file copy, AeroFTP would re-upload all 32 MB. With AeroRsync delta sync, it sends only the bytes that actually changed: 43 KB across the network instead of 32 MB, which is 99.87% saved. Measured on our live test rig against the real
rsync 3.4.1binary, byte-identical output. Now scale that to a folder of 100 small files where most are unchanged between two syncs: total payload 55 MB, bytes actually transmitted on pass 2 302 KB, which is 99.45% saved, and all 100 files share one SSH session instead of opening 100. On a residential uplink, a flaky hotel WiFi or a metered mobile connection, this is the difference between a coffee break and "leave it running overnight".In each pair, the tall bar is the bytes a classic file copy would send (32 MB and 55 MB of payload respectively). The tiny bar is what AeroRsync delta actually sends on the wire (43 KB and 302 KB). The difference is the whole point of delta sync.
Dual Panel: AeroFile expanded into a true two-panel surface. Every endpoint pair is supported (local/local, local/remote, remote/local, remote/remote, plus AeroVault overlays), with parallel transfers per pair, a FreeFileSync-style compare view (6-bucket classifier), sync presets (mirror, backup, update, bisync), conflict policy with versioned backup, and the integrated terminal cwd following the focused panel. The two-panel slices A, B and C all landed across v3.7.x and v3.8.0.
AeroVault Evolution: AeroVault has officially reached v3 (in production as a cautious Beta). The release brings real small-file packing (sub-256-KiB files concatenated into a pack indexed by the manifest, so content-defined chunking sees a wide stream and dedup stays chunk-aligned), AES-256-GCM-SIV content, a behind-the-scenes technical receipt that records the wrapper trail, compression ratio, dedup count and timing for every operation, and full CLI parity through
aeroftp-cli vault. We are now looking ahead to v4, which will add a Reed-Solomon error-correction wrapper, a milestone specifically requested and co-designed with @EhudKirsh in the COMMUNITY ROADMAP thread (issue [ROADMAP] Community Roadmap: big features for upcoming releases #162).Transfer engine convergence: in v3.8.4 we landed a shared execution path (a ready-frontier scheduler over a Directed Acyclic Graph, with prudent AIMD backpressure and an AppHandle-free observability sink) and progressively converged multiple production paths onto it: concurrent-range downloads for SFTP and FTP, B2 large-file uploads, cross-profile transfers, the AeroSync download stage, and the CLI
pgetandsynccommands.What this means for you, with real numbers measured on the live parity test rig. The GUI parity harness (
tests/gtc/) runs byte-identical races between the converged engine and the previous single-stream baseline, on real protocol endpoints. The conservative speedup bands locked at v3.8.4 are: SFTP single-file transfer 2.0× to 5.0×, S3 single-file 1.8× to 5.0×, FTP single-file 1.8× to 5.0×, SFTP batch sync 1.8× to 4.0×, cross-profile SFTP to S3 2.5× to 5.0×. A specific FTP intra-file run on a real vsftpd endpoint completed a 64 MiB transfer in 0.09s with four parallel streams (down from 0.17s on a single stream) with byte-identical output. These numbers are not projections, they are the gate every release has to clear before tagging.In each pair, the left bar is the previous single-stream baseline (1×, by definition) and the right bar is the minimum speedup the converged engine has to clear at every release (the floor of the band locked in CI). The ceiling is 4 to 5× across the same cells, depending on file size, network and provider.
What is still ahead. The current shared engine is the chunk-level foundation. The next step is to extend the same scheduler to drive the full multi-file lifecycle end to end (discover, compare, plan, transfer, verify, commit) in a single graph, with the AIMD backpressure activated in production for rate-limited cloud APIs (Google Drive, Dropbox, OneDrive, Box and friends). That work is planned, staged in four phases, and byte-identical-gated with the existing paths at every step. No claim, no behaviour change without the proof.
CLI:
aeroftp-clinow reaches 69 top-level subcommands and is feature-complete for everyday workflows. Highlights include batch scripting (.aeroftpscripts with shell-like quoting and injection-safe variable expansion),agent peek(read-only view of the staged and pending transfer queue), continuous bidirectional sync (sync --watchwith native filesystem watcher and anti-loop guards),--jsonoutput across every command,aeroftp aerorsync probeandmodefor the native engine, the optionalaeroshort alias, transfer-capability discovery for agents (LLM tooling and automation), and a unified--max-transfercap that applies to the GUI, the CLI, and AeroSync together. The same shared transfer engine now powers both the GUI and the CLI, so throughput numbers no longer drift between them.Reproduce the numbers from your own machine. The speedup bands and the delta-sync savings shown in the two charts above are not "marketing", they are reproducible from your terminal. Three dedicated subcommands ship with the binary:
aeroftp-cli speedmeasures upload and download throughput against any writable remote, with SHA-256 integrity verification on by default, configurable test-file size (-s 10M,100M,1G, ...) and iterations, JSON v1 report output, and automatic cleanup of the scratch file from the provider trash where applicable. One-shot, one server.aeroftp-cli speed-compare url-a url-b ...ranks two or more servers side by side in the same run, with configurable parallelism (1 to 4 concurrent benchmarks), and writes the results to JSON, CSV and Markdown reports in parallel. Handy to pick the fastest of your saved cloud accounts, or to compare two regions of the same S3-compatible provider.aeroftp-cli benchmarkruns a community-driven sweep acrossupload / download / list / stat / deleteoperations at three preset levels (quick~30s on a 10 MB payload,standard~5 min on 1M + 100M + 1G,deep~30 min on a broader matrix), with fully anonymized output (no hostnames, paths, credentials or bucket names recorded) and a--consent-publishflag that prints a paste-ready Issue block so the community can pool real-world numbers across providers. The report is a stable v1 JSON schema so it can be diffed and aggregated automatically across machines and releases.GUI: countless tweaks based on community feedback. The most visible recent ones include the connection-state pulse on saved-server cards (the dot now softly pulses when a profile has an active session), a Disconnect entry in the context menu, the AeroFile Sync unified dialog replacing three legacy menu entries, the transfer queue with real staging (items land staged first, an explicit dispatcher moves them to pending, with an Auto-start setting), and a Settings knob for the download segment count when you want to override the heuristic. Beyond the highlights, a long tail of smaller refinements landed across saved servers, the Settings panel, the connection flow, the Activity Log, AeroVault UX, and the CLI profile-management surface. Many of these refinements trace back to detailed UX reports from the community, with a special mention to @EhudKirsh whose sustained stream of feedback, wishlists and clean reproductions has shaped a substantial portion of this work across the v3.6.x through v3.8.x cycle. There are far too many individual changes to list, and we prefer keeping the recognition broad rather than picking a handful.
A Special Thank You
I want to express my deep gratitude to everyone who contributed to the GUI improvements and feature testing. A huge, special shoutout goes to @EhudKirsh, who has provided (and continues to provide) truly invaluable contributions to the project, from GUI refinements to the sustained design contribution behind the AeroVault wrapper stack (the compression to chunking to crypt to error-correction pipeline, the wrapper-vs-step taxonomy, the small-file-packing model).
And a wider thank you to every community member who reported bugs, suggested improvements, tested edge cases or simply sent a patient repro:
Each report, each piece of feedback shapes a release. Thank you all.
🛑 Time for a Checkpoint: Stabilization and Documentation
With so much new functionality added, it is time for a general briefing and a serious checkpoint. Before we rush into more new features, we need to:
🛠️ What's Next?
My focus: I will keep working under the hood on the critical infrastructural step that anchors the whole release cycle, which is extending the transfer engine convergence to the full multi-file lifecycle end to end. The plan is staged, gated, and byte-identical with the existing paths at every step (no overclaim, no behaviour change without the proof).
How you can help: please keep your feedback coming. Bug reports are the absolute top priority: any reproducible issue or regression you spot will be triaged and addressed ahead of every other update or new-feature request, so please open an Issue with the
buglabel and a clear repro as soon as you hit one. Beyond that, suggestions to refine the app and make the experience smoother and more intuitive are also precious. I truly appreciate the time and passion you put into AeroFTP.Housekeeping: I will be doing a comprehensive review of all pending items in the ISSUES section. Once that is done, I will publish a follow-up post to keep everyone aligned on what is pending and what is resolved.
An idea I am floating, a proper community forum: GitHub Issues and Discussions are great for tracking bugs and feature requests, but they are not the most natural venue for open-ended conversations between users (protocol tips, use-case help, "how would you do this", longer-running threads). I have been thinking about opening a proper community forum, built on Discourse (the open-source platform that powers the Rust users forum, the Caddy community and many other established open-source spaces). The technical setup is a few minutes for a professional instance. Rather than burying the question inside this long update, I will publish a short separate follow-up post dedicated to this single topic, where the vote and the discussion can live cleanly. Stay tuned for that.
A note on past CHANGELOG entries and commit messages: looking back at the last few releases, I owe you an honest apology where the CHANGELOG entries or some commit messages have been imprecise, too generic, or hard to parse. The pace was high and clarity sometimes paid the price. I am putting together a predefined template I will follow consistently from now on, so it becomes easier to read and search the project history. If you have a specific release note that left you guessing, please flag it: those will be the first targets to rewrite with the new template. Thank you for the patience while I tighten this side of the workflow.
Thank you all for being part of this journey.
Best,
@axpnet
Beta Was this translation helpful? Give feedback.
All reactions