[ COMMUNITY UPDATES ] AeroFTP: Major Milestones, Checkpoint, and Thank You

[axpnet]

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.1 binary, 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 pget and sync commands.

  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-cli now reaches 69 top-level subcommands and is feature-complete for everyday workflows. Highlights include batch scripting (.aeroftp scripts 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 --watch with native filesystem watcher and anti-loop guards), --json output across every command, aeroftp aerorsync probe and mode for the native engine, the optional aero short alias, transfer-capability discovery for agents (LLM tooling and automation), and a unified --max-transfer cap 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 speed measures 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 benchmark runs a community-driven sweep across upload / download / list / stat / delete operations 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-publish flag 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:

• @coolfocks (Tom)
• @ironhussar
• @raelb (Rael Bauer)
• @saschabuehrle (Sascha Buehrle)
• @scottonanski (Scott O'Nanski)
• @Sherlock1979

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:

1. Align and update all public documentation across the four surfaces (the app repo, docs.aeroftp.app, the website, and the AeroFTP MCP extension).
2. Fortify and optimize the existing features, including AeroVault v3 (still Beta, watching for community feedback before promoting), the AeroFile two-panel surface, and the AeroRsync engine under cross-OS conditions.
3. Test as rigorously as possible to stabilize and refine the solid foundation we have already built.

🛠️ 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 bug label 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

[axpnet]

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):

1. Should AeroFTP open a separate community forum, alongside the existing GitHub Issues and Discussions?
2. If yes, on which platform?

How to vote

• 👍 on this comment = yes, I would use a community forum
• 👎 on this comment = no, prefer to keep everything on GitHub
• If you voted 👍, please also reply with the platform you prefer. Reactions tell me the yes/no lean, replies tell me which platform.

Credible platforms (pick one, or propose your own)

• Discourse (discourse.org): the de-facto open-source forum standard, most mature, biggest plugin ecosystem, GitHub SSO out of the box. Live examples: Rust users, Caddy, rclone, Docker, Python, Discourse Meta.
• NodeBB (nodebb.org): Node.js, lighter, very fast on mobile, smaller plugin ecosystem.
• Flarum (flarum.org): minimalist PHP, clean UX, less mature than Discourse / NodeBB.
• Lemmy (join-lemmy.org): federated forum on ActivityPub (fediverse), Reddit-style UX.
• Other: name it in a reply.

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 forum.aeroftp.app, GitHub sign-in (no separate account), no migration of existing GitHub Discussions, the forum is purely additive.

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.

[EhudKirsh]

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.

[EhudKirsh]

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.

[axpnet]

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.

You are right, and the confusion is on us, not on you. Today the .aeroftp extension is overloaded across two different formats:

1. Profile export (JSON envelope with an encrypted payload): the file you get when you export saved server profiles from the GUI. Double-clicking it opens the AeroFTP GUI and routes to the import flow. Source of truth: src-tauri/src/profile_export.rs.
2. Batch script (plain text, sequence of commands with shell-like quoting and injection-safe variable expansion): the file aeroftp-cli batch <file>.aeroftp executes. Not double-clickable, only invoked explicitly through the CLI. Source of truth: src-tauri/src/bin/aeroftp_cli.rs (the batch subcommand).

So the two formats are operationally distinct (GUI double-click goes to profile import, CLI batch subcommand reads a script) but the file extension is shared, which is exactly the source of the confusion.

There is also a third related format that does NOT share the extension and is unambiguous: .aeroftp-keystore, the full encrypted backup of the installation state (vault entries, SQLite databases, plugins, sync snapshots, UI preferences). That one is fine as is.

The right fix is to give the batch script its own extension so the collision is gone. The leading candidate is .aeroftps (short, paired naturally with .aeroftp for profile export), with .aeroftp-script as a more verbose alternative if .aeroftps reads ambiguous. I will open a small follow-up issue tracking the rename, with a migration path (keep .aeroftp accepted by the batch subcommand for one or two releases with a deprecation notice, then drop it). If you have a preference between .aeroftps and .aeroftp-script, please say so in that follow-up, your taste on naming has been consistently right so far.

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 .aeroftp script actually looks like, so the second meaning is concrete. This is a tiny deploy script you would run as aeroftp-cli batch daily-deploy.aeroftp:

# daily-deploy.aeroftp

SET HOST=sftp://deploy@prod.example.com
SET DATE=2026-05-21

CONNECT ${HOST}
MKDIR /var/www/backups/${DATE}
PUT ./dist/index.html /var/www/index.html
PUT ./dist/app.js /var/www/app.js
ECHO Deployment ${DATE} complete
DISCONNECT

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 ON_ERROR CONTINUE | FAIL policy are documented in docs/CLI-GUIDE.md under the Batch Scripting section. The script format is plain text, easy to commit to a repo, easy to diff, easy to run from CI.

[axpnet]

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.

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 rsync protocol, with 25+ years of production hardening behind it, and we wired it in through the rsync binary over SSH (rsync_over_ssh.rs). It worked beautifully on Linux and macOS.

The Windows problem

Windows does not ship with an rsync binary, and installing one requires WSL, cygwin, scoop or chocolatey, none of which a typical user is willing to set up just to sync a folder. So we ended up with an embarrassing feature-parity gap: Linux and macOS users got delta sync, Windows users were stuck on full re-uploads.

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 rsync --server on the far side, with no external binary needed on the client. Cross-OS first-class, single binary, no install ritual. On Linux and macOS the classic binary path still works in parallel through the same DeltaTransport trait, and the user can pick Auto / Classic / Native in Settings → Sync.

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

• Large files that change partially. A 32 MB project that you edit 5% of: classic file copy sends 32 MB, AeroRsync delta sends about 43 KB. Live-measured on our test rig against rsync 3.4.1. This is the "I tweak a few minutes of a long video, I do not want to re-upload the whole project" case.
• Big folders where most files stay the same between syncs. The second pass over a 100 file batch (55 MB total) sends about 302 KB across the wire (99.45% saved), and reuses one SSH session instead of opening 100. This is the daily/weekly backup use case (incremental snapshot to a NAS or a remote server).
• Slow, flaky or metered uplinks. Residential connections, hotel WiFi, mobile tethering. Here the savings are not just nice-to-have, they are the difference between a sync that completes and one that gives up halfway.
• Resuming an interrupted transfer. Where the protocol allows, the delta engine restarts from where it left off, not from scratch.

When AeroRsync does NOT help

• First-time uploads. No baseline on the destination, nothing to delta against. The engine detects this and falls back to a plain transfer, no overhead added.
• Tiny files (below about 1 MiB). The delta protocol overhead is bigger than the savings, so the engine takes the plain-copy path on purpose. Live measured break-even point matches the threshold.
• Files that completely change every sync (random binaries, encrypted blobs without deterministic encoding, fresh database dumps). No common blocks between the old and the new version, the engine still tries but the savings are zero or negative.

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 rsync binary on Unix. So:

• File-by-file delta upload and download, with multi-file batches sharing one SSH session: shipped, enabled by default since v3.8.0
• Recursive tree sync with hardlinks, xattrs, ACLs, sparse files, the full classic-rsync surface: not in scope, those workflows still rely on the classic rsync binary on Unix (fallback path inside the same DeltaTransport trait)

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 (aeroftp-cli sync between two paths, aeroftp aerorsync probe <host> <user> to test against a remote, aeroftp-cli put/get with --delta for explicit per-file delta routing).

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".

[EhudKirsh]

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:

• Not require manual dev support just to create an account, which is not sustainable for your time management.
• Allow users to still post here on GitHub without posting in the forum first.
• Please go easy on users that didn't check whether an issue was already posted in the forum. A link to the forum in the GitHub issues page will help.
• Script the forum so it's impossible to dislike the comments of newcomers, or even not have a dislike option entirely to make the forum more positive.

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:
Because we're all busy with a lot on our minds, it's easy to accidentally miss some bullet points of feedback, like happened with #216. I think the solution here is to differentiate between small enhancements where there is not much to discuss, and big new features, that deserve their own dedicated posts. For example, #224 is asking for a new feature, and it's big with a lot to discuss, so it's out of scope for wishlists. The issue is that you either wait until every request in a wishlist is implemented, even big ones, which delays closing it and opening a new wishlist with the current new version, or you close a wishlist and risk burying and forgetting requests that weren't implemented yet. I think the point of wishlist posts is decluttering, so instead of opening a new issue for any tiny enhancement, they're all in one place. So the only things in scope in a wishlist should be tiny enhancements that are quick to solve. I was thinking that maybe the nice thing about moving to another platform is have a form where users can list requests with unticked checkboxes, so these never get buried, but I think it's possible to reform our wishlist posts as I wrote.

Roadmap(s):
I also think that the current roadmap post #162 should be reserved only for discussing the overlays, and even be closed in the "far" future when it's all implemented/solved to not have too many open issues. The mobile phone can have its own roadmap. If you agree, you can make a separate "Roadmap - Mobile App" and rename #162 to "Roadmap - Wrappers/Overlays" or similar names. There are really not that many roadmaps possible anyway if you think about it.

AeroVault:
I plan to check out the new AeroVault V3 draft soon, and write about it in its dedicated repo to not clutter AeroFTP. I think that issues that are exclusively related to AeroVault should probably just go there.

[EhudKirsh]

Hey, over the past day I had 3 occurrences of having bad experience regarding the closing of issues:

1. I left a comment on [BUG] The 'Folders' button loads up forever in AeroFile 📁 #216, but couldn't re-open it even though I authored it. I think this is because you closed it. It's probably best to wait for a week for the author of an issue to respond or close it themselves. It writes "You do not have permissions to reopen this issue".
2. I accidentally closed [FEATURE] Table view for the Add Service page and maybe also CLI #224 on my phone, and then reopened it.
3. I then accidentally closed [FEATURE] Add a '2FA Code' input field when connecting MEGA #128 on my PC, and then reopened it.

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.

[axpnet]

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:

• Not require manual dev support just to create an account, which is not sustainable for your time management.
• Allow users to still post here on GitHub without posting in the forum first.
• Please go easy on users that didn't check whether an issue was already posted in the forum. A link to the forum in the GitHub issues page will help.
• Script the forum so it's impossible to dislike the comments of newcomers, or even not have a dislike option entirely to make the forum more positive.

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: Because we're all busy with a lot on our minds, it's easy to accidentally miss some bullet points of feedback, like happened with #216. I think the solution here is to differentiate between small enhancements where there is not much to discuss, and big new features, that deserve their own dedicated posts. For example, #224 is asking for a new feature, and it's big with a lot to discuss, so it's out of scope for wishlists. The issue is that you either wait until every request in a wishlist is implemented, even big ones, which delays closing it and opening a new wishlist with the current new version, or you close a wishlist and risk burying and forgetting requests that weren't implemented yet. I think the point of wishlist posts is decluttering, so instead of opening a new issue for any tiny enhancement, they're all in one place. So the only things in scope in a wishlist should be tiny enhancements that are quick to solve. I was thinking that maybe the nice thing about moving to another platform is have a form where users can list requests with unticked checkboxes, so these never get buried, but I think it's possible to reform our wishlist posts as I wrote.

Roadmap(s): I also think that the current roadmap post #162 should be reserved only for discussing the overlays, and even be closed in the "far" future when it's all implemented/solved to not have too many open issues. The mobile phone can have its own roadmap. If you agree, you can make a separate "Roadmap - Mobile App" and rename #162 to "Roadmap - Wrappers/Overlays" or similar names. There are really not that many roadmaps possible anyway if you think about it.

AeroVault: I plan to check out the new AeroVault V3 draft soon, and write about it in its dedicated repo to not clutter AeroFTP. I think that issues that are exclusively related to AeroVault should probably just go there.

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 aerovault repo, so this tracker stays focused on the AeroFTP app. I'll add a short pointer in the README and in the AeroVault v3 thread so it's obvious where to file what.

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.

[EhudKirsh]

I prefer .aeroftp-script to .aeroftps, because the latter gives a sort of .apks sort of vibe as being multiple .apk.
It's not common for an app to create its own script file format, so the s alone in .aeroftps won't be intuitive.
I understand and respect your reasoning for a dedicated script file format for AeroFTP, namely for security.

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.

[axpnet]

.aeroftp-script it is. Your reasoning about .aeroftps reading like the .apk/.apks plural rather than a distinct format is exactly right, and an app that invents its own scripting extension cannot rely on one trailing letter to disambiguate. I am locking the new extension as .aeroftp-script.

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 aeroftp-cli batch, so carrying a .aeroftp -> .aeroftp-script alias for several releases would cost more in confusion than it would save in disruption. The CLI now refuses any file passed to batch whose name ends in .aeroftp, with a one-line error pointing to the new extension; stdin mode (batch -) and every other file extension are unaffected. The profile-export format keeps .aeroftp. The keystore format keeps .aeroftp-keystore. No file-format changes.

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:

• A canonical .aeroftp-script carrying the AeroFTP-native commands (SET, CONNECT, SYNC, etc.), the same format that aeroftp-cli batch already understands. This is the source of truth and runs everywhere aeroftp-cli runs.
• An optional OS-native wrapper (.ps1 on Windows, .sh with #!/bin/sh on Linux/macOS) that just invokes the canonical script with the right shebang and platform detection. Dumb, thin, easy to share. The OS detection in the GUI auto-picks which wrapper to generate, exactly as you suggested.
• The import side reads either a canonical .aeroftp-script or one of the wrappers (with shebang stripped), parses the CONNECT + SYNC invocation, and populates the AeroSync GUI with the same settings the script would run with. Settings that do not round-trip cleanly (transient flags, scheduling state that does not belong in a script) are reported in a single import summary instead of failing the whole load.

Both changes are already in main: the rename at 83cef5b9 and the AeroSync export/import lane at a585abeb (PR #237, closing #133). They will go out together in the next tagged release; I will come back here with the version when it ships so you can try it on the AeroSync settings you actually use.

Thank you for catching the .aeroftp overload and for pushing back on the naming. Both saved me from shipping a confusing format collision.