AeroVault Wrapper-Stack and Cryptography: Design Conversation #276
Replies: 11 comments 36 replies
-
|
I have plenty of more things to add on this topic, but I want to make sure we agree on the organisation first so I know where's the right place to post what. Perhaps you forgot, but I thought we agreed in #271 (comment) to keep #272 as a roadmap exclusively for the wrappers/overlays, and offshoot anything that's exclusive for AeroVault to its dedicated repo. So I didn't expect this comment as a separate post, as I thought you might post a comment like this in #272. If you agree, please rename #272 to "[ROADMAP] Wrappers/Overlays" or a similar name when you're ready, and also make a "[ROADMAP] Mobile App 📱". Although, the latter is of course less of a priority and I don't plan on posting anything on it for a while, but again, I have big ideas there as well. I can think of at least one more idea for another [ROADMAP], but I want to definitively hear that you agree to this structure before opening it as well. |
Beta Was this translation helpful? Give feedback.
-
|
I was actually trying to better organize the threads using the Discussion section to avoid creating too much confusion in ISSUES and to separate discussions from bugs/reports. It's not a firm decision, it's just a test. Moving the discussions to two different repos might actually disrupt the discussion a bit. We need to make a final decision whether to discuss them in the AeroVault repo (which exists only for the crate and has intentionally remained at v2 while awaiting the direct upgrade to v4) or to concentrate everything here (since it's the cradle of AeroVault, where it truly lives and operates). Perhaps the idea of two repos is more technically correct, but in this specific case, it's better to stay here. What do you think? Sorry for the change of heart, but I'm considering it; it's not a firm or fixed idea. |
Beta Was this translation helpful? Give feedback.
-
|
No need to be sorry, you're very polite. I just didn't expect this post because I thought we already agreed on a structure. I agree that it's best to leave the Issues page just for reporting bugs and security vulnerabilities, and everything else should go in the Discussions tab. I wrote about this in #270 (comment) just now. However, you can create a Discussion tab in the AeroVault repo. It's also possible to start an issue there and later convert it to a discussion in the future. I prefer to use that repo because it fits better and declutters this repo. Otherwise the AeroVault repo will remain mostly empty in terms of issues, if its issues mostly go here. I see AeroVault as having the potential of being a standalone strictly offline app, that's independent of AeroFTP. So I think that part of its independence is using its own Issues and Discussions tabs. I see AeroVault is a kind of dependency of AeroFTP. And who knows? Perhaps AeroVault will be a dependency of other apps in the future. It just feels a little out of place that if AeroVault has its own dedicated repo, that its design would be exclusively written on another repo, even the aspects that have nothing to do the wrappers/overlays of AeroSync. |
Beta Was this translation helpful? Give feedback.
-
|
Quick security update for this thread. The current AeroVault format version is now v3, shipped in the standalone crate Why v3 landed now: the deep audit surfaced a chunk-splicing gap (CRYPTO-01). The old per-chunk authentication bound only the chunk index, reset per file under one master key, so someone who could already edit a vault could swap one file's chunk for another's and have it still extract as authentic. v3 binds a per-file random id plus the chunk count and index into the AEAD, on both the inner layer and the cascade, encrypt and decrypt. The file id lives in the AES-SIV-encrypted (authenticated) manifest and the version byte is under the HMAC-SHA512 header MAC, so neither can be stripped to force the old path. This was a security-driven step; the larger wrapper-stack work continues on its own track. Verified before shipping: the crate test suite, real round-trips (v3 and v2 both byte-identical, tampered vaults rejected), and a cross-tool round-trip uploading a vault from AeroFTP and pulling it back with rclone, no regressions. On where this lives: I hear your point about keeping AeroVault in its own repo. The 0.4.0 changelog is committed in |
Beta Was this translation helpful? Give feedback.
-
|
@EhudKirsh bringing the Error Correction design here into the AeroVault design thread, since this is the home you and I set for AeroVault design follow-ups. The track itself was opened in the roadmap (#272, section 4). This post reports what is actually built, makes good on the naming point you raised, lays out the placement decision with the full trade matrix and the reasoning behind every call, and puts the open questions in front of you for the pre-tag review pass we agreed on. Nothing here is tagged or in a release. This post is the review surface, on purpose, and everything in it is open to revision, not presented as closed. Status: development is underway on a working branch (not pushed, not tagged). What is built and green on local gates right now: the embedded Reed-Solomon layer over the cipher blocks (create / scrub / repair, CLI and GUI), and, new since I started this write-up, the metadata-locator protection in section 4 (a corrupted manifest is now rebuilt from its own parity instead of being fatal, with a regression test). The optional detached placement (section 3) is the next slice and is presented here as design for your review before it lands. I am sharing this now to inform and to get your read; the testable release still waits for your review pass, per section 6. 1. Naming: the acronym is goneYour point from the 2026-05-29 comment: stop using "ECC" for Error Correction, because in a thread full of cryptography it collides with Elliptic Curve Cryptography, and the second C was never well justified. You are right and I agreed. The whole surface is moving to "Error Correction" spelled out: UI strings, CLI help, the docs, and the code symbols and on-disk identifiers too, so the acronym does not survive anywhere a user or a reviewer would read it. If you still spot "ECC" after this lands, it is a miss; flag it. 2. The format decision: v4 is v3 plus Error Correction, not a new formatYou framed this exactly right in May: "V4 will simply be V3 plus these added Error Correction files, which a V3 version of AeroFTP can simply ignore." That is the contract, and it held through implementation. There is no separate v4 format and no separate v4 file. v3 already reserved an extension directory and an extension payload region in its 1024-byte header, with the rule that a reader rejects only Why this and not a separate
The result: a pure v3 reader opens and extracts a v4 vault unchanged (it walks past the recovery extension), and "v4" is the feature label for "a v3 vault with the Error Correction wrapper enabled", not a version bump. 3. The decision I want your eyes on: where the recovery data livesThis was a stated preference of mine, not a closed agreement between us, so it is the heart of this review. You pictured Error Correction as files "put to the side" (the par2 and Kopia separate-file model), and later as parity "appended to the end of its chunk". I shipped the first cut as an in-container block (the recovery data sealed inside the single Rather than argue one model, here is the full comparison across the dimensions that actually decide it, including the append-per-chunk variant you raised, so the reasoning is on the table and not just the conclusion. 3.1 System comparison
3.2 Failure-mode coverage, stated preciselyOne thing I want to be exact about, because it is easy to oversell Error Correction and you would catch it: a detached parity copy does not make Error Correction a substitute for a second full backup. Parity at, say, 20 percent cannot reconstruct an entire lost medium; if the whole device holding the data dies, the data is gone and a fraction of parity cannot rebuild it. That is what a second copy is for. What the detached copy actually buys is decorrelation: it puts the recovery data on a different medium so that a single localized failure event cannot take out a block and its only recovery copy at the same time. With that framing honest:
3.3 The recommendation, with the reasoningI do not want to pick one model, because the matrix shows they cover different cells and the union covers all of them with one codec. The proposal:
Why Why Why this is cheap to build and not a second engine: the recovery payload is already a self-contained, serializable blob, and the reconstruction path already takes those bytes as an input rather than reading them only from the container. So a detached copy is a placement choice, not a parallel implementation. One codec, one audit pass, your point about audit tractability preserved. Why append-per-chunk is dropped: once you have 4. The metadata locator: now protected for the manifest (implemented)Scrub locates damaged blocks by the per-block
A regression test covers it (corrupt the manifest on disk, the vault still opens, extracts byte-identical, and repair heals the on-disk copy), with a negative control proving a non-Error-Correction vault with the same corruption is fatal, so the rebuild is demonstrably what saves it. The honest remaining limit: this protects the manifest, not the 1024-byte header itself. The header is small, fixed-layout and HMAC-protected, so a header hit currently fails closed at open. Covering the header too is the natural job of the detached copy (the case where the in-file copy is the casualty), and it is on the list below for your review rather than shipped silently. 5. The scheme and its parameters, with the reasoning for eachWhat is built on the embedded side today, and why each parameter is what it is:
6. The commitment, restatedPer what we agreed: this does not get tagged, v3 does not leave Beta, and there is no milestone tag, until you have had a pre-audit review pass on this design and the spec. No deadline pressure from my side; the point of the gate is that the review happens. Anything you flag is a spec bug by default until shown otherwise, same rule as the code. 7. Open to changes and integrationsNothing above is closed except where we explicitly agreed (the wrapper stack, the V4 = V3 + Error Correction contract, the recovery-not-just-generation requirement). I would specifically value your read, and counter-proposals, on:
As always this track carries your name: the wrapper-stack framing, the V4 = V3 + Error Correction contract, the par2 reference, and the recovery-not-just-generation requirement are yours, and the credit stays inline in the spec and in the vault receipt. |
Beta Was this translation helpful? Give feedback.
-
|
@EhudKirsh this is exactly the review pass the gate was for, thank you. Going point by point, because every one of these lands. 1. "Sidecar" is a property, not the separate-file placement
You are right and this is a real correction, not a quibble. I was using "sidecar" to mean "the separate file", and your framing is cleaner: Sidecar is the property of a non-transforming overlay - Error Correction reads the bytes and adds protection without rewriting them, where compression / chunking / encryption must transform to do their job. Under that property the parity can live either embedded or separate; both are "sidecar" in your sense, and embedding is arguably more sidecar-like (the attachment the bike pulls), not less. So I'm splitting the vocabulary as you ask:
Agreed, and that's the better mental model - placement becomes "where the sidecar's bytes go", not a different feature. You also hint at a second non-transforming overlay we haven't discussed:
Noted and parked - when you're ready, open it and I'll bring the same treatment. 2. Table 3.1 missing the cost of
|
| Dimension | Embedded | Detached | Both | Append-per-chunk |
|---|---|---|---|---|
| Parity storage cost | 1x | 1x | 2x (parity stored twice) | 1x |
with a note that beyond processing time and complexity, the doubled parity footprint is the real price of both.
3. Support all of them
since there are significant pros and cons, all of these options should be supported. This is what I'd expect from the best aspiring research platform/app on file management.
That's the plan - embedded (default), detached, both all ship; the matrix shows each owns cells the others don't, so dropping any of them loses coverage. The default stays the safe no-surprise one; the others are a flag away.
4. Different algorithm per placement
I also wonder whether it might be better to use one algorithm, like Reed-Solomon, as either separate or embedded, and another algorithm in the other place. This way covers as much ground as possible with various Error Correction approaches to maximise the protection of data from corruption.
Genuinely interesting, and it would buy algorithmic decorrelation - a bug or blind spot in one codec wouldn't take out both copies in a both setup. The tension is with the "one codec, one audit pass" property I leaned on, which keeps the security review tractable.
My read: the architecture already makes this cheap, because placement is just "where the bytes go" and the codec is a separate choice - so a second algorithm is possible without a parallel engine. But I'd keep single-codec as the default (one audit surface for the median user) and treat a heterogeneous both (e.g. Reed-Solomon embedded + a different code detached) as an explicit opt-in once the single-codec path is audited and shipped. That way we don't pay the second-codec audit cost up front, but the door you're pointing at stays open. Does default-single / opt-in-heterogeneous match what you had in mind, or were you picturing it on by default?
5. Re-hashing cost
won't appending Error Correction require hashing the whole file or chunk again? [...] it's extra complexity and processing, so it's something to think about. Maybe it's possible to easily only hash parts of files.
Good instinct, and the design already does the "hash parts, not the whole" thing you're reaching for. Parity is computed over the cipher blocks, and each shard already carries its own per-shard BLAKE3 computed once at seal. So:
embeddedanddetachedover a vault: no whole-file re-hash - the recovery payload is a self-contained blob and the per-shard checksums are the only hashing, done once.- generating Error Correction over an arbitrary external file (your point 8 below): one pass to shard-and-hash it, but still per-shard, never "the whole file again per chunk".
Append-per-chunk was exactly where this got ugly (it re-touches layout and offsets), which is one more reason it's dropped in favour of embedded + detached.
6. Sidecar format - look at Kopia / par2 first
my only feedback for now is to look at what Kopia and possibly other apps are doing. I think it's best to start with being able to support existing standards, and then improve upon these by making your own. This is what you've done with Cryptomator Vault and AeroVault, and are about to do with AeroCrypt over Rclone's Crypt.
Agreed, and that's the right order - embrace the standard, then improve. par2 is the established parity-sidecar format and Kopia's Reed-Solomon shard layout is the closest living reference, so I'll study both and align the detached-file framing to what's already proven before inventing AeroFTP-specific framing on top (vault-binding so a wrong file is refused early, etc.). Same playbook as Cryptomator -> AeroVault and Crypt -> AeroCrypt.
You can also do it with Syncthing and P2P transfer in #284, and AeroRsync [...] I'd like to expand more on this paragraph, but I will probably do so elsewhere
Looking forward to that - open it where it fits and I'll engage there.
7. CLI flags - settled
--ecand--error-correctionseem like reasonable flags, so let's keep both. I'm not a fan of a--eccflag for Error Correction, as you might have imagined.
Settled: --error-correction as the canonical flag, --ec as the short alias, and --ecc is gone (it dies with the acronym). That closes the open CLI naming question from the follow-up post.
8. Error Correction over any file, idempotency, and both ordering
I like the idea of picking just about any file and generating Error Correction for it.
This generalises Error Correction from "a vault wrapper" to "a standalone parity tool over any file" - which is exactly the par2 mental model and a natural fit. I'll scope it as its own surface (a parity-style command over an arbitrary path) so it doesn't get tangled into the vault-only path, but the codec is shared.
It's important to make sure that AeroFTP recognises its own embedded Error Correction so as to not generate Error Correction for another existing Error Correction needlessly.
Agreed - idempotency guard. The engine will detect its own parity (extension marker for embedded, format magic for detached) and refuse to wrap parity-over-parity unless explicitly forced.
For the Both option, it's probably best to generate the Error Correction to a separate file and then embed it, as opposed to the other way around. It's simpler than finding where the file/chunk content ends, and where its Error Correction begins.
Accepted as the implementation order: for both, compute the detached payload first, then embed a copy - never embed-then-extract. Cleaner, no boundary-hunting inside the sealed blob. Good call.
9. Percentage selection (Kopia / QR levels) and absolute byte targets
KopiaUI gives the option of selecting the % in byte size of the input files [...] with 10% being the maximum. [...] QR codes [...] also use percentages: Low ~7%, Medium ~15%, Quartile ~25% and High ~30%. If you can support selecting absolute targets in byte size, that's also welcome.
This is the answer to my "profiles vs raw percentage" question, and your framing is better than mine. I'll expose both: a percentage dial and an optional absolute byte target. The familiar named levels map straight onto the QR scale you cite - Low ~7%, Medium ~15%, Quartile ~25%, High ~30% - which most people already recognise from QR codes, so we get a shared vocabulary for free.
One honest note: AeroFTP's current default is 10+2 (~20% parity), i.e. higher than Kopia's 10% cap and sitting between your QR "Medium" and "Quartile". I think that's right for the cold-storage / USB / NAS media this targets (Kopia leans on already-redundant repositories), but the point is the dial is exposed and the user picks - not a single baked number.
10. "Profile names", JSON, metadata locator
I'm not sure what you mean by "profile names". I don't have more
--jsonfeedback currently. I don't know much about the metadata locator and parameters.
That's on me - "profiles" was my term for medium presets (cloud / usb-nas / cold-archive). Given your point 9, I'm collapsing that into one vocabulary: the QR-style named percentage levels (Low/Medium/Quartile/High + custom), so there's no second naming scheme to learn. No "profile names" to settle anymore - they become the percentage levels.
On the metadata locator and parameters (sections 4 and 5): those are implementation-side (how a corrupted manifest is rebuilt from its own parity, shard sizing, all-or-nothing repair) and nothing there needs a decision from you - I flagged them for transparency, not for a ruling. No action needed on your side.
11. Mounting - the aspect I left out
Another important aspect which you left out here, perhaps I didn't highlight it before in #162, is mounting. [...] it would be nice to be able to mount and view any profile before and after each wrapper stage.
You're right that I left it out, and it's a real gap in the post. Mounting exists in the codebase (AeroFTP ships a FUSE layer via fuser), so "mount and view at each wrapper stage" is an extension of something already there rather than a new engine - I'll give it its own design pass against #162 rather than bolt it onto this thread.
if the sidecar is a separate file rather than appended to the end, there will be barely any difference between the view that's on a cloud drive/external hard drive [...] and the view of it before the sidecar is created, because it's just adding separately.
This is a strong argument for the detached placement that the matrix didn't capture: with a detached file the mounted / cloud view is unchanged except for one extra object, whereas embedding rewrites the container the user sees. I'll add this as a row/note in 3.1 (detached = storage view stays stable; embedded = container changes) - it's a genuine point in detached's favour for mount-and-browse workflows, and it pairs with your point 1 (embedding is the more invasive of the two, even though it's the "more sidecar-like" attachment).
Summary of what changes from this pass
- Terminology: "Sidecar" = overlay property; placements rename to
embedded/detached/both(word for the middle one is yours to confirm). - Table 3.1: add the
both= 2x parity cost row, and a detached = stable-storage-view row. - Flags settled:
--error-correction+--ec, no--ecc. - Redundancy UI: QR-style named % levels + absolute byte target; "profiles" folded into these.
bothordering: detached-first, then embed.- Idempotency guard + Error Correction over arbitrary files added to the design.
- Heterogeneous codecs and mount-per-stage: accepted as directions, scoped as opt-in / their own pass.
Still nothing tagged, v3 stays in Beta, per the gate. Anything above I've mis-read is a spec bug by the same rule. And as always the framing here is yours - the sidecar-as-property correction is going straight into the spec with your name on it.
Beta Was this translation helpful? Give feedback.
-
1. Sidecar Property
At any rate, you might want each of these 2. Table 3.1"Parity storage cost" will be unclear to a layman reader unfamiliar with this post. I strongly suggest using the term Byte Size. 4. Default PictureI had a picture in my mind of the default Error Correction structure from my chats with AI, 6. Another Sidecar OverlayAs for the other sidecar overlay I hinted at, Let's just say that it's something that should ideally work entirely offline and independent of AeroFTP, 9. Various Target LevelsAeroVault and AeroSync should have a |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Ehud, going point by point. 1. 2. "Parity storage cost". Agreed, that phrasing is jargon. I'll switch Table 3.1 to an explicit byte framing ("parity byte size" / extra bytes written). 4. Default structure. Good: I'll keep 6. The other sidecar overlay. Fully agree: park it, give it its own offline-first repo when the time comes, and keep this round focused on the four overlays we already scoped. 9. Configurable levels. Yes to both, in AeroVault and AeroSync: a number input + range slider for the zstd level (with Fast/Balanced/Archive as the guided buttons), and the same number+range for the EC percentage with a few labelled stops (Low ~7%, Medium ~15%, like QR codes), fine-tunable from 1% up. Buttons for familiarity, slider for exact control. I'll capture it as the UI spec for when EC lands in the GUI. Nothing here is in code or tagged yet: this stays the review surface, as agreed. |
Beta Was this translation helpful? Give feedback.
-
I'm not sure. I'm curious to see how AeroSync will handle Error Correction first, which might give me an idea. |
Beta Was this translation helpful? Give feedback.
-
|
No date to give you yet, by sequence, not by calendar:
So: AeroVault embedded ships first (review-gated, ready), AeroSync EC follows. No version lock on either, they go out when the review and the design are done, not on a fixed date. |
Beta Was this translation helpful? Give feedback.
-
AeroVault v3: stress validation for the Beta to Stable promotionv3 has been the on-disk AeroVault format since Method4,914 real CLI operations across 7 scenario families, run in parallel on the release binary (so the Argon2id 128 MiB KDF runs for real on every open). Every case asserts one of two things: a byte-exact round-trip (SHA-256 of the extracted file equals the original), or a correct rejection (wrong input fails cleanly, never silently). A handful of representative commands are shown below; the battery runs thousands. Scenario families
Results
Representative commands (the battery runs thousands of these)Round-trip integrity, byte-exact across formats, profiles, sizes and content shapes: # v3 / archive profile / 300 KB incompressible
$ aeroftp-cli vault create v.aerovault --vault-version v3 --profile archive
$ aeroftp-cli vault add v.aerovault payload.bin
$ aeroftp-cli vault extract v.aerovault payload.bin out.bin
$ sha256sum payload.bin out.bin # identical
9d399285f16a0bcee0d8420444731240018335bbf0415a949cf2c0797113a909 payload.bin
9d399285f16a0bcee0d8420444731240018335bbf0415a949cf2c0797113a909 out.binTamper detection, a single flipped byte in the ciphertext is caught before any plaintext is returned: $ printf '\x00' | dd of=v.aerovault bs=1 seek=120000 count=1 conv=notrunc
$ aeroftp-cli vault extract v.aerovault payload.bin out.bin
Error: Cipher block hash mismatch for chunk ccb51bfb... # exit 1, rejected before any outputWrong password, fails closed, no plaintext leak: $ AEROFTP_VAULT_PASSWORD="not-the-password" aeroftp-cli vault extract v.aerovault payload.bin out.bin
Error: AES-KW unwrap failed # exit 1, key unwrap fails, no plaintext producedGarbage input, random bytes as a vault never panic the parser: $ head -c 50000 /dev/urandom > junk.aerovault
$ aeroftp-cli vault info junk.aerovault
Error: Failed to read archive: invalid Zip archive: Could not find EOCD # exit 1, clean rejectionConclusion🟢 4,914 / 4,914 cases pass. The integrity guarantee held across 2,500 byte-tamper iterations with zero silent corruption, and 1,500 garbage inputs with zero panics. The one real defect the battery found (the v2 named-extract bug above) is fixed and pinned by a new regression test. Combined with the existing unit suite (full Rust lib suite green) and the v3 audit (CRYPTO-01 chunk-splicing fix shipped in v3), this is a technical green gate. My recommendation: v3 is ready to move from Beta to Stable. As always, nothing here is tagged; flagging it for review first. |
Beta Was this translation helpful? Give feedback.
-
AeroVault v4 (v3 + Error Correction): development follow-up, audit, fixes, and live evidenceStatus at a glance:
Following the Error Correction design I posted here on 8 June, I took the track end-to-end internally so the pre-tag review has something concrete to push on. The point of building it now is exactly to surface technical problems early, before anything is tagged, rather than discover them after a release. Nothing below is tagged or in a release. This is still the review surface; everything is open to change on your read, @EhudKirsh. What is built (recap)v4 is not a new format, it is v3 + an Error-Correction layer, a non-critical extension, so a v3-only reader still opens a v4 vault (it just ignores the parity). The slices, as built:
Audit: final assessmentI ran a full post-implementation audit (four independent review passes: parser/security, Reed-Solomon correctness, sync integration, and code quality/duplication). Headline:
All critical/high/medium items are fixed on the branch, plus a set of low/quality items (dead-code removal, dependency pinning, +9 direct codec tests). Full report lives in the dev appendix. Gate: all green
Live evidence (real CLI, no mocks)Embedded parity: inject damage, detect it, repair it, byte-verify the recovered file: $ aeroftp-cli vault create v.aerovault --error-correction --recovery-level 20
$ aeroftp-cli vault add v.aerovault secret.bin # 300 KB incompressible
$ aeroftp-cli vault scrub v.aerovault --json
{ "checked": 1, "count": 0, "damaged": [], "parity_source": "embedded" }
# corrupt 48 bytes inside the encrypted data section, then scrub again:
$ aeroftp-cli vault scrub v.aerovault --json
{ "checked": 1, "count": 1, "damaged": [ { "id": "e840a885...", "on_disk_len": 300051 } ], "parity_source": "embedded" }
$ aeroftp-cli vault repair v.aerovault --json
{ "repaired": 1, "damaged": 1, "dry_run": false, "parity_source": "embedded" }
$ aeroftp-cli vault extract v.aerovault secret.bin out.bin
$ sha256sum secret.bin out.bin # identical, recovery is bit-exactDetached parity, and the safety property that matters most: a hostile recovery file is rejected, the vault is left untouched, and the genuine parity then repairs the same damage: $ aeroftp-cli vault export-parity v2.aerovault
Wrote recovery file v2.aerovault.rec (12 shards, 300051 bytes protected, 20.1% overhead)
# a random 5 KB ".rec" handed to repair on a damaged vault:
$ aeroftp-cli vault repair v2.aerovault --parity bogus.rec --json
Error: recovery file does not match this vault (exit 1, vault unchanged)
# the real sidecar repairs it:
$ aeroftp-cli vault repair v2.aerovault --parity v2.aerovault.rec --json
{ "repaired": 1, "parity_source": "explicit" }(8/8 live scenarios pass, including Interesting ideas the audit surfacedThese are not committed scope, they are the genuinely novel directions the audit turned up, worth your eyes:
Remaining workDecisions still openThree calls are still open before this can be tagged:
Everything else in the tree above is decided. The tag stays blocked until these are settled; any of them can also move back into the roadmap if that is a better home. |
Beta Was this translation helpful? Give feedback.
-
So in other words, is that chunking of large buckets into smaller chunks only for transfer as opposed to at rest for S3? I use the word bucket instead of a file here because we refer to S3. |
Beta Was this translation helpful? Give feedback.
-
|
Also, you might want to add to table 3.1 above the detached advantages I just listed. |
Beta Was this translation helpful? Give feedback.
-
|
Both good follow-ups. On S3: yes, exactly. Multipart is purely a transfer mechanism, the parts are reassembled server side into one object, so at rest there is no chunking and nothing is stored in pieces. The 5 MB minimum applies only to a part during the upload protocol, never to the stored object, which is why a sub-5 MB file (or a small On table 3.1: agreed on both counts. I will add the two |
Beta Was this translation helpful? Give feedback.
-
|
Done: table 3.1 now lists the two |
Beta Was this translation helpful? Give feedback.
-
|
Link to the updated table, for reference: #276 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
🟢 AeroVault v4 EC follow up: windowed streaming, the size cap is lifted Continuing the large-file thread: the detached How it works, briefly:
Live evidence (real CLI, MEGA, no mocks)
Caps and safeguards
Tests executed
One honest note: the plaintext is fully streamed, but the sidecar itself is still read into memory on the repair path, which is why the default cap is 1 GiB for now. Lifting it further needs a streaming sidecar (parse and fetch parity window by window), which is a separate follow up. Next: a top-level |
Beta Was this translation helpful? Give feedback.
-
|
Good questions, in order. How the tests corrupt things, and the format point. You are right that a flip can change how a parser reads a file: corrupt a length or an offset and the structure is suddenly invalid. Error correction sidesteps that entirely, it protects the raw byte stream, so it restores the exact original bytes regardless of what the corruption did to the format interpretation. The harness just XORs a byte (or wipes a whole window) at chosen offsets, in the file and, for the sidecar tests, in the The Crypt wrapper is the key insight. EC runs LAST in the wrapper pipeline (compression, chunking, crypt, then EC), so inside a Corrupting the file only, versus the file and its sidecar.
On "v4 = v3 plus a detached sibling": yes, and embedded is already there too. Placement is a three-way choice:
So a user who wants the parity inside the container already gets it, exactly as you suggest. And your last point is exactly right. Embedded placement is literally "EC appended as trailing bytes", and it works for any format that tolerates trailing data (the vault's extension area is built for it). The catch is that not every format ignores trailing bytes, so the universal version of your idea is the detached sibling: it protects ANY file without touching it. That is why detached is the default, and the planned |
Beta Was this translation helpful? Give feedback.
-
|
A few diagrams to make the above concrete. 1. Where error correction sits. EC is the last wrapper, so it protects the ciphertext, not your file. It never decodes the format, it just restores the exact bytes, then decryption gives the file back.
2. Parity placement. Detached is the default (the .aerovault stays byte-identical to a plain v3, parity in the sibling), embedded keeps the parity inside the container, both writes it in both places (in-container plus a sibling).
3. Recovery, file only versus file and sidecar. With the sidecar intact you reconstruct and re-verify against the authenticated hash. A lightly damaged sidecar self-heals first (its replicated locator is repaired and rotted parity shards are routed around) and still recovers within the parity budget. Only damage past that budget falls back to the embedded copy if one exists, otherwise the vault is left byte-for-byte untouched, never a wrong overwrite.
|
Beta Was this translation helpful? Give feedback.
-
|
Nice diagrams. Please add the word 'sibling' to the both as well, so there's absolutely no confusion as to why it's not there but it's in the detached scenario. Also, surely if |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, glad they help. Good catch on And on a slightly-corrupted The recovery file now self-heals. Its small critical metadata (the header, the segment directory, the per-window geometry, the part that locates everything) is stored redundantly, so a stray flip there is repaired from a good copy before anything else runs. The bulk of the file is parity, and that was already resilient: every shard, data and parity, carries its own checksum and reconstruction treats a mismatching shard as an erasure and routes around it. So a lightly-damaged The safety property is unchanged: recovery only writes after the rebuilt bytes re-verify against the authenticated values (the vault's header MAC and manifest cipher_hash, or the file's content hash for AeroSync). Damage beyond the budget makes the repair fail and leaves the original byte-for-byte untouched, never a wrong overwrite. Lose the recovery data past what it can self-heal and you lose the recovery, the same par2 property that makes the parity location a choice. Both updated diagrams are refreshed in place in the diagrams post above. |
Beta Was this translation helpful? Give feedback.
-
|
Considering that if you still have an uncorrupted file, you can always generate it new EC, maybe the focus of EC should be just on recovering the original file as opposed to healing itself? Perhaps I misunderstand Error Correction, but is the self-healing of |
Beta Was this translation helpful? Give feedback.
-
|
Good question, and no, the self-healing does not come out of the main file's parity budget. The sidecar has two parts: the parity (the Reed-Solomon shards that actually rebuild your The locator is a few hundred bytes, and it is fixed regardless of file size. Concretely, the redundancy adds about 360 bytes total. On a 1 MB file the whole sidecar is 154,621 bytes at the medium level (15.4% overhead), of which the self-healing redundancy is those ~360 bytes, so roughly 0.2% of the sidecar and 0.04% of the file. Protect a 1 GB file and it is still ~360 bytes, now a rounding error. So self-healing does not reduce how much damage to the main file you can recover. On the "maybe EC should just focus on recovering the original" point: that is exactly the focus, and self-healing serves it. You are right that if you still have a good original you can always regenerate parity, but EC is for the case where you do not. The failure I wanted to close is this one: your So it is not "spend parity to heal the sidecar". It is "spend ~360 fixed bytes so a slightly damaged sidecar is still usable when you need it most". |
Beta Was this translation helpful? Give feedback.
-
|
Maybe I'm up to something and maybe I'm up to nothing here, but if the issue is that a cryptographic hash may fail due to a bit flip, |
Beta Was this translation helpful? Give feedback.
-
|
I like the instinct, and you have put your finger on the real property: a cryptographic hash is all-or-nothing, it tells you "identical or not" and nothing about degree. So the question "can we measure how damaged this is" is a good one. The catch is that a recovery path can never act on "approximately right". The whole safety model is that we re-verify the rebuilt bytes against an exact hash before we persist anything, so a sidecar can only make a repair fail, never corrupt good data. A fuzzy match that says "this copy is 95% similar to what it should be" cannot be used as the source of truth, because we still do not know which 5% is wrong, and writing it back would be exactly the silent corruption we are trying to prevent. So fuzzy hashing cannot replace BLAKE3 for the integrity decision itself. But here is the nice part: the "how corrupted" meter you are asking for already exists, and it is sharper than a single fuzzy score. The format is built from many small self-checking pieces. Every Reed-Solomon shard carries its own checksum, and the locator is stored in three copies each with its own checksum. So instead of one fuzzy number for the whole file, we already know exactly which shards and which copies failed. That gives a precise, actionable map: "12 of 15 shards intact in this window, 2 of 3 locator copies good", and from the shard count versus the parity budget we can even say up front whether a repair will succeed. That is strictly more information than a similarity score, and it is the same data reconstruction already uses to route around the damage. There is also a practical issue with fuzzy hashes specifically here: the locator is tiny, well under a kilobyte, and ssdeep / TLSH style hashes want much more input to be meaningful and can collide, so on this data they would be weaker, not stronger. Where your idea does land cleanly is diagnostics, not recovery. A "health" readout on verify (something like "this sidecar is 90% intact, repair likely" or "too damaged to recover") is genuinely useful, and we can build it for free from the shard and copy failure counts we already compute, no fuzzy hash and no new dependency. If that is the experience you were picturing, I am happy to surface it on the verify path. And to be fair to fuzzy hashing, it is a great tool in its own domain, finding near-duplicate or similar files, which is a different problem from deciding whether a recovery file is byte-exact. Thanks for pushing on this, it is the right kind of question. |
Beta Was this translation helpful? Give feedback.
-
|
Also, BLAKE3 is faster, so it's best to start with it, and if a task can use either cryptographic or fuzzy hashes (hard to imagine them as alternatives), it's best to pick cryptographic for the speed. I wasn't thinking too deep, I just noticed a pattern and connected 2 dots. |
Beta Was this translation helpful? Give feedback.
-
AeroVault v4 (v3 + Error Correction): ready to ship, asking for your go-ahead🟢 This is engineering-complete and staged on every surface. Before I tag the release I want your read, @EhudKirsh, since we agreed v4 would go out on your review pass, and your testing and design input shaped most of it. Where it stands: The self-healing Beyond the unit suite there is now a repeatable, seeded stress campaign for the self-healing format, run on the release binary. 2,017 end-to-end cases drive the real
The standout: the app and the standalone The earlier open decisions are settled, the way this thread landed them. There is one unified detached recovery format, Your two recent questions are answered in-thread: the self-healing redundancy costs about 360 fixed bytes and does not touch the main file's parity budget, and the fuzzy-hash idea is better served by the per-shard and per-copy failure counts we already compute (which I am happy to surface as a health readout on verify). Your V3 Beta report on the crate discussion is handled too. Extract all, a first-class add-folder picker, the receipt save dialog, the "Time elapsed" wording, and a pre-flight memory guard so a very large input warns instead of OOMing are all done. Drag-and-drop onto the create screen, the change-mode action, true streaming vault I/O, and the On framing: there is no beta label. The validation here is extensive and the audit is continuous, so refinements land in later releases rather than gating this one. If you are comfortable, I will take that as the go-ahead and tag it. If anything still looks off to you, this is exactly the moment to say so and I will hold. Thank you for the depth you brought to this one. It is a better format because of it. |
Beta Was this translation helpful? Give feedback.
-
AeroVault compression, measured: AeroVault v3 vs zip / 7z / tarFollowing the readiness note above, the one thing I would rather show than assert is how AeroVault actually compresses, so here is a full benchmark against the zip / 7z / tar encoders we ship. Every format is driven through the one AeroFTP CLI, so the comparison is self-consistent: same machine, same corpora, same harness, timed under The corpora span the honest range from compressible to incompressible:
Shannon entropy is Compressed size as a percentage of original, by corpus
text corpus at 32 MiB
mixed corpus at 32 MiB
The speed vs size tradeoff, with the Pareto frontierSpeed and size pull against each other, so the chart marks the Pareto frontier: a format is on it when no other is both smaller and faster, and the hollow points are dominated (some frontier format beats them on both axes at once). The faint green wedge below-right of the curve is the unreachable small-and-fast corner, which is why it sits empty. 
Compress and extract throughput
Peak memory during compress, and time vs input size
What the numbers sayThe KDF floor is real and deliberate. On the smallest input AeroVault spends about 778 ms to compress against zip-aes at 46 ms, because Argon2id at 128 MiB runs once per container. That is brute-force resistance, not a slow compressor. The clear lever is a cached-key batch mode so the KDF is paid once across many small containers rather than per file. On ratio, AeroVault is competitive at the dense end. On text, aerovault-archive lands at 15.6% against 7z at 15.1%, a 0.5 point gap, and the very tightest is tar.bz2 at 12.8%. AeroVault-fast trades some ratio for far more speed: about 16x faster than the dense AeroVault-archive profile and roughly 33x faster than 7z, which is the right default for an interactive app. One honest result the frontier surfaces: on the text corpus tar.bz2 dominates 7z, tar.xz and AeroVault-archive, because it is both smaller and faster than all three. This is corpus-specific, bzip2 is unusually strong on prose, but it is a fair signal that the densest-but-slowest profiles are not the rational pick on text. On incompressible data every format sits near 100%, with the largest expansion being tar.bz2 at 100.5%. That delta over 100% is the honest cost of framing and encryption on already-random bytes. Two concrete improvement levers fall out of this. The 7z integration currently ignores Output was byte-stable across all repetitions, and the run is reproducible from the same seed and binary. |
Beta Was this translation helpful? Give feedback.
-
Can't there be a mechanism to reject increases in byte sizes due to compression and simply go with the original files instead? |
Beta Was this translation helpful? Give feedback.
-
|
Let me ask the obvious question: why not switch the Archive and Balanced options from |
Beta Was this translation helpful? Give feedback.
-
|
Good question, and the benchmark is the right lens for it, so I am logging this as a tracked item rather than flipping the defaults on the spot. The nuance the chart shows is that the best codec is corpus dependent. tar.bz2 dominated on prose specifically (bzip2 is unusually strong on text), but on mixed and incompressible data the gap closes and zstd keeps a large speed lead, which is exactly why the Fast default leans on zstd. So "Archive to bz2, Balanced to gz" is a real candidate, not a clear universal win, and that is the kind of call a per-surface benchmark should make rather than a snap switch. Tracked as one item: re-evaluate the Archive and Balanced default codecs against the benchmark, surface the comparison chart wherever compression is offered (AeroVault, AeroSync, AeroFile) so the trade is visible instead of hidden, flag where 7z and tar.xz are not the rational pick, and add zstd (Fast especially) to AeroFile. The benchmark harness already exists, so this is evaluation and UI work, not new measurement. Thanks for pushing on this. |
Beta Was this translation helpful? Give feedback.
-
After a docs and code review: naming clarity, AeroVault v4, and AeroCrypt ProfilesAn honest note to open. We have just done a thorough pass over our documentation and our code together, and we found a number of things worth tidying, starting with terminology. Clear and consistent naming is something this community has asked for more than once, and it was overdue, so we are doing it in the open. Three things come out of that review. First, we are settling on a clear name for our native client-side encryption overlay: AeroCrypt. The docs have referred to it as AeroFTP-Crypt, and the word overlay had drifted across surfaces, so we are fixing the vocabulary. Second, we are upgrading AeroCrypt from a CLI beta to a first-class component in the GUI. Third, we are adding the new AeroCrypt Profiles on top of it. The rest of this note is the concrete next step that gets us there. To be precise about terms, the earlier request on this thread was for AeroVault v3 plus Error Correction, set out in the two comments above, the ready to go note and the benchmark. That addition, Reed-Solomon parity computed over the v3 ciphertext, is exactly what we mean by v4. The work is built, audited and benchmarked, so we are advancing with it. v4 is the natural and awaited destination this thread has been building toward, not a detour. In plain terms it means a vault can now survive partial corruption: if bytes rot on disk, or a transfer damages part of the container, the Reed-Solomon parity rebuilds the damaged shards and the vault still opens, with verification happening before decryption so a tampered container fails closed. The overhead is a level you pick on the same QR style scale, and the Beta label comes off. The same step consolidates the AeroVault cryptography into one audited engine, and that is what carries us to the rest of the destination. The native AeroCrypt overlay, which has matured through the CLI as a beta, comes to the GUI bound to a saved connection as an AeroCrypt Profile, so any commodity remote becomes a transparent zero knowledge store you browse in the normal dual panel, both sides encrypted and readable only inside AeroFTP. rclone-crypt stays beside it as the interop lane, the way Cryptomator sits beside AeroVault: we support the foreign format and we lead with ours. We will open a dedicated roadmap Discussion to carry that part forward. To keep the two clearly apart, since they are easy to confuse, a quick reminder of the distinction:
Both are built on the same audited crypto core, one codec and one audit pass: only the shape after encryption differs. To be clear, this is not a request for sign off, it is a status update: we are advancing to v4, and gathering remarks from the community along the way. The overlay chapter then begins on top of it. Two points where your input would help most: whether the encrypted scope should default to a subfolder so a profile is never accidentally half encrypted, and whether the platform cipher should be chosen automatically or offered as an explicit toggle. Thoughts from anyone here are welcome, on these or on the terminology cleanup itself.
|
Beta Was this translation helpful? Give feedback.
-
|
There should absolutely be a choice between using Rclone Crypt and AeroCrypt, any time any path is encrypted. Considering that there are risks such as nonce-misuse with Rclone Crypt and the experimental nature of AeroCrypt, I think that both should be opt-in. I was going to write more about this in length in #272, but it's best to write about this now since Crypt for AeroSync seems to be right around the corner. Basically, I'm sitting on a figurative mountain of notes where I write ideas as soon as I come up with them I know that I wrote before that I like the idea of each wrapper being its own profile, but I'm rethinking this. With Rclone, So the order is:
Basically, the first wrapper, whichever it is, shows the files in their original plaintext form when clicking on it or mounting it. I'm guessing that previewing these remote files and their metadata will be in RAM as opposed to temporary files. Whatever AeroFTP does currently when previewing the files that are in cloud drives, as well as what Rclone does in normal and Crypt remotes. To perform Rclone's equivalent of Each set will have its own path. When using Rclone, I personally like to direct Crypt remotes to "Crypt" subfolders. This leaves plaintext sibling items clearly separated from encrypted files and folders, including items that some cloud drives create and refuse to remove. As for the symbol of each overlay badge, I plan to write about it in #272. I was thinking of suggesting even having the ability to have multiple Crypt wrappers in the same set for paranoid defence-in-depth double-encryption, but I think it's best to achieve this with only a single Crypt overlay. So when setting up any overlay, the user will choose its settings, including the number of layers of encryption in Crypt, each having a different algorithm: XSalsa, AES, ChaCha, etc. |
Beta Was this translation helpful? Give feedback.
-
|
This is exactly the kind of note worth posting now rather than holding for #272, thank you.
Agreed, and that is exactly how v4.0.5 behaves already: there is no default cipher, you actively choose AeroCrypt or Rclone Crypt by clicking in the GUI or typing in the CLI, so nobody encrypts by tapping Enter. On the experimental worry, that is precisely why we just ran a severe pre-release audit on the native overlay and hardened it (the green note above). AeroCrypt is built on AES-256-GCM-SIV, which is nonce-misuse resistant by design, the very risk you point at in Rclone Crypt's construction, and the format now binds length and carries a key-bound config MAC. So the two genuinely sit on different footings, and both stay opt-in.
I think you are right, and the 2N to 5N explosion is the real argument against wrapper-as-profile. The badge set on a single profile reads as the cleaner direction, and it lines up with what AeroCrypt Profiles is meant to be: one saved connection, a set of clickable wrapper badges, each badge a before/after view after peeling that layer, the Connect action showing the overall before/after. That is the model I want to design around.
I agree with this whole shape as the design direction: a fixed wrapper order (AeroFile, AeroCompress, AeroChunk, Crypt, AeroCorrect) where you choose which layers to enable rather than reorder them, one remote path per set with multiple sets when someone wants different paths, defense in depth living inside a single Crypt overlay as a setting rather than as multiple Crypt badges, and 🔒 for the Crypt badge to match the E2E profiles. One detail I want to keep open is the AeroCompress versus AeroChunk ordering you flagged, since I am not yet certain which should sit first. One point of fact rather than design: previews already resolve in RAM today, not via temp files, so that part of your guess matches how AeroFTP works now. I do not want to turn this into commitments in the release thread, so I am not going to promise specific surfaces here. The honest next step is that this is the AeroCrypt Profiles chapter, and its detailed design (the badge set, the order question, per layer views and mounting, the symbols) belongs in the dedicated Wrappers/Overlays roadmap. I will carry your model there so we converge on it properly, and none of it gets lost. For v4.0.5 the scope stays what is built and audited: AeroVault v4, and AeroCrypt hardened and first-class, both opt-in. On your earlier benchmark question, which I would rather answer with a fix than a promise:
🟢 Done, and it ships in the imminent v4.0.5. ZIP compression now decides per entry: if a deflate pass would not make a file smaller, that file is stored as-is instead of deflated, so packing incompressible data no longer inflates it from compression, while compressible files still deflate normally. To be precise about scope, this is the per-entry store mechanism that ZIP is built for. The single-stream codecs (tar.gz, tar.xz, tar.bz2) still carry their small inherent framing on already-random bytes, which is the unavoidable cost of choosing that container, not compression expanding the payload. |
Beta Was this translation helpful? Give feedback.
-
AeroCrypt, audited and hardened before it ships green🟢 You flagged the experimental nature of AeroCrypt, and you were right to. So before AeroCrypt rides into v4.0.5 as a first-class component, we put the native overlay through a severe pre-release audit with one target: a strict external reviewer should find nothing. It now passes that bar, and here is the whole pass in the open. This also answers your opt-in point directly: there is no default cipher. You actively pick AeroCrypt or Rclone Crypt, by clicking in the GUI or typing in the CLI, exactly as you asked. We lead with AeroCrypt and keep Rclone Crypt beside it as the interop lane. Encryption that browses like any other serverThere is a second thing worth calling out, which you pointed at earlier. Rclone Crypt used to open in its own modal, a bit like an AeroVault container. Now both overlays, AeroCrypt and Rclone Crypt, are integrated directly into the normal dual panel. You unlock once, and from then on the decrypted folder reads, navigates and transfers exactly like a connected server, with clear names on your side and ciphertext on the provider's. The practical payoff is that this turns any cloud into a zero-knowledge target. You get the same experience you would have on a natively encrypted provider like Filen, MEGA or Internxt, except you can have it on any of the 28 backends, even the ones that offer no encryption of their own, with the outer layer keyed only by you. On a provider that already encrypts at rest, the overlay is a second independent layer on top of theirs, genuine double encryption where the key that matters never leaves your device. 
What the audit looked atFive independent reviewers swept the whole native surface (the shared crypto core, the file format, the Tauri/GUI provider commands, the CLI Findings, and what we did
Two of these were not theoretical. We reproduced them live on a real backend on the shipping binary, then re-ran the same probes after the fix. The format, in one viewAeroCrypt writes one encrypted object per file ( Each block authenticates both its own index and the total count, and the reader requires that exactly Why truncation now fails closed (the math)Let a file be An attacker who drops the last so Why a tampered config (or wrong password) now fails closedThe v3 config carries a key-bound MAC: It is recomputed and compared in constant time on every unlock. Since Where it sits next to rclone cryptFor completeness, here is the rclone crypt format we read and write on the interop lane, and the two formats side by side. Rclone crypt is mature and widely used; its content cipher is a stream AEAD, so it is not nonce-misuse resistant by construction, which is the property you flagged and the reason AeroCrypt leans on AES-256-GCM-SIV. 
Live evidence (real backend, real CLI, no mocks)
Gate
What this meansAeroCrypt is no longer a CLI beta with rough edges. It is an audited, length-bound, tamper-evident overlay built on AES-256-GCM-SIV (nonce-misuse resistant by design, which is the property Rclone Crypt's construction does not give you), and it is opt-in with no silent default. That is the footing we wanted before it becomes the led encryption option in the GUI, with Rclone Crypt staying beside it for interop. The full write up lives in our internal audit appendix, happy to share any specific part if useful. |
Beta Was this translation helpful? Give feedback.
-
|
A sneak peek at AeroCrypt Overlay in action 
|
Beta Was this translation helpful? Give feedback.
-
|
NOTE: The AeroCrypt and AeroVault audit was performed by Claude Fable with MAX effort within 72 hours of public release. It consumed an entire 5-hour session in about 15 minutes, orchestrating Opus agents. Interestingly, it didn't find many vulnerabilities, although some appeared serious. Given the excessive token consumption, I stopped using it, and within a few hours it was suspended by the US government, as you know. |
Beta Was this translation helpful? Give feedback.
-
|
I've heard about the drama between Anthropic and the US government. I thought it was only threats. At any rate, I was just in the middle of writing feedback for the screenshots you shared:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks Ehud, and no need to worry on the Claude side, my access is fine and AeroAgent is unaffected, it was a lighter situation than it sounded. I will keep an Announcement in mind if anything material changes, but there is nothing to report right now. All five UI points from your screenshot feedback are done on the way to v4.0.5. 🟢
Done. There is now a collapsible "Wrappers / Overlays" section, collapsed by default, so nothing shows until you open it. Crypt is the first sub-section inside it and future overlays slot in alongside, so the password, salt and algorithm fields only appear once you tick Crypt and pick a type. The section auto-opens when you edit a profile that already carries an overlay.
Done. The section is titled "Crypt (Encryption)", with no "Profile", "overlay" or "Aero" in it. Rclone Crypt is now the left button and AeroCrypt (native) is on the right.
Agreed, that line was wrong for the interop case and is fixed. The general hint is shorter now, and the readability note is per type: Rclone Crypt reads "Standard rclone crypt format: also readable by rclone with this password", while the native format keeps "readable only from AeroFTP".
Done, the Salt field now has the same show/hide eye toggle as the password.
Done, both fields now have a label above them, with the placeholder kept only as a secondary hint. These ship in v4.0.5. Thanks again for the precise pass. |
Beta Was this translation helpful? Give feedback.
-
|
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.
-
Anchor for the AeroVault design conversation in Design Threads. The full historical thread lives in the Community Roadmap discussion (the conversation that ran 2026-05-07 to 2026-05-19, with substantial design contribution from @EhudKirsh, credited inline in every AeroVault receipt and in the v3.8.0 release notes).
This post serves two roles at once: a checkpoint of every decision that came out of that conversation, and a starting base for everything that follows. Read it as the shared ground from which the next design questions on AeroVault start, not as a closing summary.
The pipeline at a glance
Each box is a first-class wrapper, not a sub-step buried inside another. Order is non-arbitrary: compression before crypt (so the ratio survives), crypt before ECC (so confidentiality survives parity-byte failures).
Checkpoint: agreed decisions
Cryptography matrix
Position against existing tools:
Where it lives in the codebase
docs/AEROVAULT-V3-SPEC.mdsrc-tauri/src/aerovault/src-tauri/src/vault_telemetry.rs(VaultReport)aeroftp-cli vault {create,add,info,extract}with auto-detection across v1/v2/v3What this thread is for going forward
If a question is small enough to live in the v4+ Wishlist, it belongs there (wishlist Discussion). If it is wishlist-scoped but specifically about AeroVault, drop a link from there back to a post in this thread for the design context. If it is roadmap-scoped (multi-day, architectural), it belongs in the Roadmap discussion; a link from there to a post here is fine when the AeroVault design framing is the focus.
References
docs/AEROVAULT-V3-SPEC.mdBeta Was this translation helpful? Give feedback.
All reactions