Format Coverage: which compression, archive and encryption formats should I add next?

[axpnet]

AeroFTP already covers the common archive and encryption path. This discussion is about the next missing formats people actually need to open, create, browse, verify, repair or restore. Please vote for formats tied to real files you encounter, not just formats that are technically interesting.

Some of these are genuinely obscure or only used in professional and niche environments. I left them in on purpose, because part of the goal is broad format coverage and part is simple curiosity.

What I am asking: reply under the "Cast your vote here" comment indicating the format you would like to see and the motivation behind it, in priority order. I will tally ranked votes first, then use top-level discussion for corrections, missing formats and implementation notes.

---

Already covered today (baseline, for reference)

Local archive create/extract: zip, 7z, tar, tar.gz, tar.xz, tar.bz2, plus rar extraction. ZIP and 7z support AES-256 passwords on both create and extract. For 7z specifically the encryption story is already broad: I create AES-256 content-encrypted archives, and the Archive Browser already opens, lists and extracts header-encrypted 7z (the -mhe=on mode where filenames are hidden) once the password is supplied. The GUI Archive Browser can browse ZIP, 7z, TAR and RAR without extracting, with selective extraction.

First-party AeroFTP formats: .aerovault encrypted containers, including v2 and the v3/v4 track; .aerozip plaintext recoverable archives with zstd, integrity checks and Reed-Solomon parity; .aerocorrect detached recovery sidecars. .aerozip is not confidential, it is recovery-oriented.

Encrypted overlays and vaults already covered: Cryptomator vault format 8, rclone crypt, and the native AeroCrypt overlay (AECR). RAR extraction is extract-only, and encrypted RAR support follows what the bundled UnRAR path can list or extract with a password.

Note: zstd is already linked and used internally by AeroVault v3, .aerozip, keystore paths and related storage flows. What is not exposed yet is generic .zst, .tar.zst and stacked archive support as normal local archive formats.

ZIP-family package containers such as APK, JAR, WAR, NUPKG, VSIX and OXT are already ZIP at the archive layer. A package-specific manifest UI would be a separate vote.

---

Legend

Effort: 🟢 medium-low, ship in a short pass. 🟡 medium-high, needs real work (a port, a build-time dependency, a scoped external-tool integration, or read-only scope). ⚪ parked or ruled out, see the transparency section at the end for the reason against each.

Category badges:

encrypted folder overlay, transparent layer on top of cloud or remote storage
portable encrypted object, archive or container
compression, package, archive or filesystem image format
recovery sidecar, backup repository browser or restore surface

Scope note: for stream codecs like zstd, LZ4, Brotli and Snappy, the first milestone is decode/extract and stacked tar support, not inventing a new multi-file archive container.

---

Encrypted folder overlays

These formats encrypt a mounted or synced folder so each object lands on remote storage already encrypted.

Format	Effort	What it is	Crypto	Rust path	Ref
gocryptfs	🟡	Well-documented open-source encrypted overlay filesystem for cloud-synced folders	AES-256-GCM content, AES-256-EME filenames, scrypt password KDF, HKDF-SHA256 subkeys	clean spec, filename crypto and layout work	crypto
securefs (lite)	🟡	Cross-platform encrypted overlay, practical for local and cloud sync	AES-GCM content, AES-SIV filenames, Argon2id by default, with lite-mode rollback caveats	primitives mostly available, format work needed	design
CryFS	🟡	Block-based encrypted cloud filesystem that hides metadata and directory structure better than file-per-file overlays	configurable data cipher, AES-256-GCM protected config layer, scrypt KDF	upstream CryFS 2.0 Rust rewrite is alpha; production support still needs filesystem-scale work	how it works

---

Portable encrypted objects and containers

These are single-file encrypted objects, encrypted archives, or bundle conventions. Some hold many files directly, others need a tar or zip layer.

Format	Effort	What it is	Crypto	Rust path	Ref
age (.age, .tar.age, .tar.zst.age)	🟢	Modern file encryption; pair with tar or zstd for portable multi-file bundles	ChaCha20-Poly1305 stream encryption, X25519, scrypt and other recipients	age crate, reference-grade ecosystem	spec
OpenPGP (.gpg, .pgp, .tar.gpg)	🟡	Classic interoperable encrypted messages, public-key or passphrase based	AES family, CFB/MDC or RFC 9580 AEAD, S2K including Argon2id	rpgp or sequoia-openpgp, scope carefully	RFC 9580
7z hidden-filename create (-mhe=on)	🟡	Narrow gap, not a new format. I already read, list and extract header-encrypted 7z, and I already create AES-256 content-encrypted 7z. The only missing piece is creating archives with the filenames hidden too	AES-256-CBC, SHA-256 KDF iterated 2^19	would need migrating from sevenz-rust to sevenz-rust2, and header-encrypted write support there is still uncertain	crate
AxCrypt (.axx)	🟡	Widely used per-file encryption format, especially in Windows workflows	AES-128/256-CTR, PBKDF2-HMAC-SHA512, key wrap, HMAC-SHA512	open spec, no mature Rust crate	spec PDF
Picocrypt (.pcv)	🟡	Archived but stable encrypted volume format with optional recovery and deniability	XChaCha20 plus keyed-BLAKE2b, Argon2id, HKDF-SHA3; Serpent/HMAC-SHA3 in paranoid mode	port from Go or implement a careful subset	project
AES Crypt (.aes)	🟢	Simple portable per-file encrypted stream	AES-256-CBC, key stretch via SHA-256 iterated 8192 times in v2 (PBKDF2-HMAC-SHA512 in v3), HMAC-SHA256 integrity	aescrypt-rs exists, or implement directly from the spec	spec
CMS / PKCS#7 / S/MIME (.p7m, .p7e, .p7enc)	🟡	Enterprise and public-sector encrypted object format	algorithm-suite dependent, CMS EnvelopedData and EncryptedData	useful for import/decrypt workflows, not a multi-file vault	RFC 5652

---

Compression, archive and package formats

Beyond ZIP, 7z, TAR, GZ, XZ, BZ2 and RAR. Split into formats people hit every day and the niche or professional ones.

High value, formats users actually encounter

Format	Effort	What it is	Encryption	Rust path	Ref
Zstandard (.zst, .tar.zst, .pkg.tar.zst)	🟢	Modern stream codec used by Linux packages, OCI layers, filesystems and fast archives	no	zstd, already linked; expose as single-file codec and stacked tar decoder	crate
LZ4 (.lz4)	🟢	Speed-first codec used in databases, kernels and fast backups	no	lz4_flex, pure-Rust frame format	crate
Brotli (.br)	🟢	Web and font ecosystem, high ratio on text	no	brotli, Rust implementation with streaming APIs	crate
lzip (.lz)	🟢	LZMA-based long-term archive stream with integrity tooling such as lziprecover	no	lzma-rust2, lzip reader/writer support	crate
CAB (.cab)	🟢	Microsoft Cabinet, Windows installers and driver packages	no	cab, read/write with caveats: writes uncompressed/MSZIP, reads LZX, no Quantum	crate
MSI (.msi, .msp)	🟢	Windows Installer packages, often with embedded or external CAB payloads	no general archive encryption	msi for the installer database plus cab for payload extraction	crate
Debian packages / ar (.deb, .a)	🟢	Debian packages and Unix static-library archives. .deb is an ar container with tar members, often gzip, xz or zstd compressed	no	debian-packaging or ar + tar + codecs	crate
ISO 9660 / UDF bridge (.iso)	🟡	Optical, installer and boot images, including Joliet, Rock Ridge, El Torito and modern UDF bridge discs	no	hadris-iso for ISO; hadris-udf / hadris-cd for UDF bridge, validate maturity first	ISO, UDF, CD
SquashFS (.squashfs, .sfs)	🟢	Read-only filesystem image, inside Snap, AppImage, firmware and live media	no	backhand, Rust read/create/modify path with codec caveats	crate
Apple flat package / XAR / PBZX (.pkg, .xar, Payload)	🟡	macOS installer packages and software-update payloads	signatures, not general archive encryption	apple-flat-package, apple-xar, pbzx, plus cpio/xz payload work	flat pkg, XAR, PBZX
WIM / SWM / ESD (.wim, .swm, .esd)	🟡	Windows file-based deployment image with compression and full-file single-instance storage	no general archive encryption	wimlib via FFI realistically; pure-Rust paths are not mature enough	spec, wimlib

Niche and professional, the interesting ones

Format	Effort	What it is	Encryption	Rust path	Ref
Snappy framed (.sz)	🟢	Speed-first codec mostly seen in big-data and database ecosystems; standalone .sz is less common than zstd/LZ4/Brotli	no	snap, pure-Rust framed and raw Snappy	crate
ZPAQ (.zpaq)	🟡	Journaling, deduplicating, max-ratio archiver with versioned rollback, rarely supported outside specialist archivers and backup tools	yes, AES-256 + scrypt	zpaq_rs, libzpaq via a build-time C++ shim	zpaqfranz
LHA / LZH (.lzh, .lha)	🟢	Retro, Amiga and Japanese archives	no	delharc, read/extract path, not a full writer	crate
cpio / initramfs / RPM payloads (.cpio, .img)	🟢	Unix archive payloads used by initramfs and RPM internals	no	cpio-archive for newc/odc; pair with gzip/xz/zstd as needed	crate
EROFS (.erofs)	🟡	Android system and vendor partitions, embedded Linux	no	erofs-rs, pure-Rust reader for images	project
Apple AEA (.aea)	🟡	Apple Encrypted Archive used in modern Apple firmware and software workflows; read/seek path exists but should be treated as experimental	yes	aea-tools, read/seek first	project

---

Recovery sidecars and repository browsers

These are not all the same kind of format. Some are true content-addressed backup repositories, like restic, Borg, Kopia, Duplicacy and Proxmox Backup. Some are deduplicating archives, like DAR, ZPAQ and WIM. Some are recovery sidecars, like PAR2. Some are filesystem replication streams, like ZFS and Btrfs send. I would prioritize read-only browse, verify and restore flows, so AeroFTP stays a file manager and does not become a backup scheduler.

Format	Effort	What it is	Crypto	Rust path	Ref
PAR2 / Parchive (.par2)	🟢	Standard sidecar verification and repair files for any archive or folder	no encryption, Reed-Solomon recovery data	rust-par2 for verify/repair; par2cmdline fallback if needed	project, crate
DAR (.dar)	🟢	Classic random-access Disk ARchive, useful as a read-only archive browser	DAR supports encryption and per-file compression, but the current pure-Rust reader handles compressed unencrypted archives only	dar-core / dar-forensic, pure-Rust read-only path	reader
restic (browse)	🟡	Read-only snapshot browser and restore for restic repositories, huge install base	AES-256-CTR + Poly1305-AES MAC; zstd in repository format v2	rustic_core, pure-Rust read/write ecosystem, scope AeroFTP to browse/restore	crate
Proxmox Backup / PXAR (.pxar, datastore)	🟡	Deduplicated backup datastore for hosts, VMs and containers, with browsable file archives	optional encrypted chunks	upstream Rust ecosystem exists, but full datastore/protocol support is larger than plain archive extraction	docs
Borg (external CLI browse)	🟡	Deduplicating backup repository with compression and optional authenticated encryption	mode-dependent	native Rust browse is not realistic today; read-only support via installed borg CLI would be feasible	docs

---

⚪ Considered and parked or ruled out (full transparency)

I am listing every format I evaluated and set aside, with the reason against, so you can see the analysis was complete and weigh in if you think I dismissed something too quickly.

⚪ Encrypted folder overlays

Format	Reason against
EncFS	2014 security audit found real weaknesses, superseded by gocryptfs, legacy
eCryptfs	In-kernel stacked filesystem, Linux-centric, root/admin shape, not a portable cloud-folder format
fscrypt / ext4 encryption	Native disk/filesystem encryption, needs kernel support and a real filesystem, not portable files
Boxcryptor	Proprietary, assets sold to Dropbox in 2022, app shut down, no openable format
Sookasa / Odrive	Defunct or SaaS-only, proprietary, no openable format
Tahoe-LAFS	Grid and P2P paradigm, Python service, belongs to the peer/distributed-storage track rather than vaults

⚪ Portable encrypted containers and objects

Format	Reason against
VeraCrypt / TrueCrypt	Too recognizable to ignore, but better as a long-term stretch. Header decrypts in Rust, then AeroFTP still has to browse FAT, NTFS or exFAT safely.
LUKS / LUKS2	Linux and kernel centric, normally dm-crypt, inner Linux filesystem parsing kills portability
BitLocker / EFS	Windows volume centric, needs an NTFS reader plus key-protector handling, no good Rust ecosystem
Apple encrypted DMG / sparsebundle	Decrypt layer exists via dmgwiz, but inner HFS+ and APFS parsing makes listing heavy
PDF, ODF, OOXML encryption	Document payload formats, not general file vaults
KeePass .kdbx	Excellent Rust crate, but it is a password database, not a multi-file container
PEA / PeaZip native format	Public format and interesting authenticated encryption, but no mature Rust path and likely low demand compared with 7z, ZIP, age, OpenPGP, AxCrypt and AES Crypt

⚪ Compression and archive

Format	Reason against
DAR write	Creation needs C++ libdar, no mature FFI binding, only the reader path is plausible today
lrzip (.lrz)	No Rust library at all, FFI or subprocess only
lzop (.lzo)	Codec is easy, but byte-exact lzop file headers need a hand-rolled layer, low value
ACE (.ace)	No Rust decoder and a known remote-code-execution history (CVE-2018-20250), do not implement
EGG, StuffIt-X (.egg, .sitx)	No viable Rust decoder for the modern/proprietary formats; classic StuffIt .sit is a separate low-demand case
Apple Archive AA / AAR (.aar)	The Apple Archive family is worth watching, but AEA is the stronger first candidate because a Rust read/seek path exists today
VM disk images (.qcow2, .vmdk, .vhd, .vhdx)	Users may expect them, but real browsing requires block-device logic plus inner filesystem support, so this belongs to a disk-image track

⚪ Backup repositories and replication streams

Format	Reason against
Kopia	Repository format is configurable at creation, implementation is Go-first, no third-party Rust reader
Duplicacy	Interesting database-less chunk store with cross-computer deduplication, but no mature Rust reader and restore requires Duplicacy config/key/snapshot semantics
Duplicati	Remote data is split into .dlist, .dblock and .dindex volumes; practical restore is still tool-coupled and no Rust path exists
bup	Git packfile storage is intentionally accessible, but no native encryption and restore semantics are still bup-coupled
IBM Spectrum Protect (TSM)	Proprietary storage pools, format undocumented for third parties, API only
Bacula / Bareos	Volume/catalog model is documented enough for disaster recovery, but practical browsing needs catalog reconstruction or daemon-style tooling, too heavy for a file manager
Amanda	Format poorly documented externally, wraps native dumpers, no Rust path
git-annex / DVC / Perkeep	Interesting content-addressed ecosystems, but they are runtime/workflow systems rather than archive formats. git-annex and Perkeep do have encryption stories, so the issue is fit and scope, not only crypto.
ZFS send streams	Excellent replication format, but native browsing means replaying filesystem/block semantics. Raw encrypted sends are intentionally opaque without ZFS keys.
Btrfs send streams	Stream format is documented and parseable, but extraction requires replaying snapshot commands and handling parent subvolume semantics, so it is a filesystem replication track rather than an archive track.
Veeam VBK/VIB/VBM	Very relevant enterprise backup format, but proprietary; support should be vendor-extractor/API only, not native parsing

---

How to weigh in

I left a comment below titled "Cast your vote here". To vote, reply nested under that comment indicating the format you would like to see and the motivation behind it, in priority order.

Please keep general discussion, implementation corrections, and any format I missed in top-level comments on the main post. I will tally votes from the voting thread first, then use top-level discussion to adjust the roadmap.

Thank you for reading this far, and feel free to flag any format I missed.

---

[axpnet]

Cast your vote here

This is the voting thread. Reply nested under this comment to cast your vote.

Tell me the format you would like to see and the motivation behind it. List as many as you want, in priority order.

A simple template if you want one:

Format:
Why:

I tally ranked votes from this thread and the highest-ranked formats move into the roadmap first.

Please keep general discussion, corrections, and any format I missed in top-level comments on the main post, and keep this thread for votes only, so the count stays clean.