[ RFC ] AeroShare: User-to-User Encrypted P2P Transfer (Peer)

[axpnet]

I know I have crazy ideas, but we're not here to create something that already exists, but to innovate and find solutions and ideas that no one has ever implemented. Therefore, given the new user management system, the idea that intrigues me is transferring files from one AeroFTP user to another via a p2p connection. I want to explore this topic for research and personal interest. I realize it's a very complex topic and would introduce completely unexpected features in a file transfer client, but I feel it could be the missing link to complete the suite. I'll evaluate the possible avenues and whether or not to officially advance the proposal in the roadmap.

[axpnet]

RFC Brief

Below is a first-pass RFC brief for a research track, not a roadmap commitment.

Title
AeroFTP User-to-User Encrypted Transfer
Research RFC, exploratory only

Context
AeroFTP now has two foundations that make this idea worth studying: a local multi-user partition model in FTP_CLIENT_GUI/com.aeroftp.AeroFTP.metainfo.xml and a shared transfer engine in docs.aeroftp.app/architecture/dag-transfer-engine.md. It also has a strong local credential-isolation model in docs.aeroftp.app/credential-isolation.md.
The architectural tension is that AeroFTP explicitly states it has no server-side component and does not operate a relay or proxy in FTP_CLIENT_GUI/PRIVACY.md and FTP_CLIENT_GUI/PRIVACY.md. Any user-to-user transfer design must decide whether to preserve that constraint or relax it.

Problem Statement
AeroFTP is strong at user-to-server and server-to-server transfer. It does not currently provide a native user-to-user transfer model between AeroFTP identities or devices. The opportunity is to explore whether a secure, privacy-preserving, end-to-end encrypted transfer flow between AeroFTP users could become a differentiated part of the suite.

Goals

• Enable one AeroFTP user to send files directly to another AeroFTP user.
• Keep payloads end-to-end encrypted.
• Reuse as much of the existing transfer engine and vault model as possible.
• Preserve a simple, trustable UX: explicit consent, explicit recipient, explicit transfer session.
• Minimize metadata exposure.

Non-Goals for Phase 1

• Full sync or collaborative shared folders.
• Social graph, contact discovery, public directory, or messaging platform behavior.
• Always-on background federation across many devices.
• Anonymous mass file sharing.
• Perfect traffic indistinguishability or advanced censorship resistance.

Recommended Scope for the First Research Spike
Study only a one-shot, user-consented transfer flow:

• Sender selects one or more files.
• Sender creates a short-lived invitation or transfer code.
• Recipient accepts on another AeroFTP instance.
• Transfer uses end-to-end encryption.
• No permanent address book required.
• Online-only delivery for the first iteration.
• No guaranteed delivery while recipient is offline.

That is the smallest version that tests product value without accidentally building a full communications platform.

Architecture Options

1. Pure direct P2P, no relay
   Pros:

• Best alignment with AeroFTP’s current privacy posture.
• No service operations burden.
• Strong product story: direct encrypted handoff.

Cons:

• NAT traversal and firewall failure rates will hurt real-world success.
• Poor reliability across mixed home, mobile hotspot, office, and CGNAT environments.
• Harder to support offline recipient scenarios.
• High UX risk if connection success is inconsistent.

Assessment:

• Good research branch.
• Weak candidate for a polished default feature.

2. Relay-assisted, still end-to-end encrypted
   Pros:

• Best reliability and most predictable UX.
• Enables fallback when direct paths fail.
• Opens the door to offline delivery queues later.

Cons:

• Contradicts today’s “no proxy / no server-side component” posture.
• Introduces cost, abuse prevention, rate limiting, and legal/privacy obligations.
• Becomes a service, not just a desktop capability.

Assessment:

• Most practical if the feature ever becomes mainstream.
• Too heavy as a first commitment.

3. Hybrid: direct when possible, encrypted relay fallback
   Pros:

• Best long-term user experience.
• Honest technical model: optimize for direct, recover through relay.
• Lets AeroFTP keep a “prefers direct” posture.

Cons:

• Highest complexity.
• Requires both P2P transport work and relay operations.
• Hardest to reason about from a product and support standpoint.

Assessment:

• Most likely final form if the concept proves valuable.
• Not a suitable first implementation target.

Identity and Trust Requirements
The new local user-management system is not enough by itself. A user-to-user feature needs a separate remote trust model. At minimum:

• User identity: who is the sender or recipient.
• Device identity: which device is participating.
• Key material: long-term identity keys and short-lived session keys.
• Trust bootstrap: invite code, QR, fingerprint verification, or out-of-band confirmation.
• Revocation: what happens if a device is lost or compromised.
• Session approval: explicit accept or reject on the receiving side.
• Metadata policy: what the other side learns before acceptance.

This is the real hard part. The transfer engine is not the bottleneck. Identity and trust are.

Transport Candidates to Evaluate
The transport study should compare four families rather than prematurely picking one:

1. WebRTC DataChannel
   Strong NAT traversal ecosystem, familiar direct-connection model, but introduces browser-style signaling assumptions and complexity in desktop-native Rust/Tauri integration.

2. QUIC-based custom transport
   Good performance and control, modern stack, but you own more protocol design and NAT traversal complexity.

3. libp2p-based design
   Rich ecosystem for identity, transport, and discovery patterns, but potentially too opinionated and heavy for AeroFTP’s product shape.

4. Wormhole-style rendezvous and capability-based transfer
   Very appealing for one-shot secure delivery. Conceptually cleaner for “send this to that person with a code” than a full peer network.

My current bias is that a wormhole-like capability model is the best conceptual fit for a first research spike, even if the eventual production system becomes hybrid.

Security Requirements
Any serious version of this idea should require:

• End-to-end encryption of payloads.
• Mutual authentication or at least recipient verification before send.
• Short-lived session credentials.
• Replay resistance.
• Transfer approval on the receiver.
• Size and quota guards.
• Abuse throttling if any rendezvous or relay exists.
• Clear metadata boundaries: file names, sizes, thumbnails, and sender identity must not leak casually.

Also, “obfuscated” should not be a primary design goal. Strong authenticated encryption and metadata minimization matter more than traffic camouflage.

Product Risks
The main risks are not implementation difficulty alone.

• Product drift: this can turn AeroFTP from transfer client into communications substrate.
• Privacy policy drift: current statements in FTP_CLIENT_GUI/PRIVACY.md would need revision if a relay exists.
• Abuse surface: malware transfer, spam, unsolicited requests, and denial-of-service.
• Support burden: failed NAT traversal looks like a broken app even when the network is the real cause.
• UX complexity: trust prompts, pairing, devices, fingerprints, and failure modes can overwhelm the core product.

Recommendation
Proceed only as a research track, not a roadmap feature.

Recommended research order:

1. Define the exact product shape as one-shot secure handoff, not folder sync.
2. Write a threat model before writing code.
3. Prototype one transport candidate for direct delivery.
4. Measure real success rates across hostile network conditions.
5. Decide whether relayless is viable enough to justify further work.
6. Kill the idea quickly if relayless UX is unreliable and you do not want to run infrastructure.

Go / No-Go Criteria
Green light only if all of these look plausible:

• The pairing and trust UX can be explained in one screen.
• Direct transfer succeeds often enough in real networks to avoid user frustration.
• The design does not undermine AeroFTP’s privacy story.
• The feature can stay clearly scoped and not become an accidental chat or sharing platform.

Stop the track if any of these become true:

• Relay is mandatory for acceptable success rates, but you do not want service operations.
• Trust and abuse controls become heavier than the file-transfer value they unlock.
• The implementation starts competing with more important core transfer work.

Bottom Line
The idea is not crazy. It is actually one of the few “unexpected” directions that could feel genuinely original inside AeroFTP, because the app already has the vault model, transfer engine, and now user partitioning. But it is only good if treated as a new architecture research problem, not as “just another transfer feature.” The decisive question is not whether P2P encrypted transfer is possible. It is whether AeroFTP wants to own identity, trust, and possibly relay semantics as part of its product.

__
Codex

[EhudKirsh]

One word: Syncthing. I'll expand on it later, though I already hinted it at various points 😉

[axpnet]

Follow-up: Direction, transfer-first, iroh spine, with a staged L0/L1/L2 research track

After working through this with the team, here is where I have landed. Thanks @EhudKirsh: "Syncthing" was the right instinct (do not reinvent identity, relay, or NAT), and the Codex RFC correctly identifies identity and trust as the real bottleneck. This post refines the product model, adds the transport candidate the thread was missing, and proposes a staged track.

First, a correction to the product model

Codex read the idea as one-shot (wormhole-style ephemeral send). That is only one layer. The essence is simpler and more on-brand:

A user is an endpoint, exactly like a server. You transfer to a peer the same way you transfer to a remote.

This reverses one of Codex's Non-Goals. He listed "no permanent address book." But if a peer is an endpoint like a server, then a peer address book is desirable, not scope-creep: a contact is just a saved connection that happens to be a person. This maps 1:1 onto iroh's thesis ("IP addresses break, dial keys instead"): a contact equals a saved public-key NodeID, that is, a permanent dialable address.

The layered model

	Model	AeroFTP analog	Precedent
L0, base	Push files to a user	transfer to a server	ICQ "Send File"
L1, +1	Peer exposes a browsable folder; you browse and pull	mount/browse a remote	ICQ "Shared Folder"
L2, novel	Peer as transient E2E gateway to a remote it holds credentials for (S3/SFTP), credentials never exposed	none (does not exist)	none

Historical note worth making: ICQ (RIP, 2024) had a Shared Folder in 2003 that "turned your computer into a mini file server," but it broke behind NAT and firewalls and had no E2E. The idea was 20 years early. Keet/Hyperdrive proves the same idea works today ("turns your computer into a mini file server," verbatim) with DHT hole-punching and signed append-only drives. We are not inventing the shared folder. We are finishing an idea that was imagined in 2003 and only became reliable now.

Transport candidates

Path	Layer	Rust-native	Proven at scale	License	Fit for transfer-first
iroh (n0)	transport	yes	200k concurrent conns	Apache/MIT	best
Hypercore/Holepunch (Keet)	transport plus data model	JS (Pear/Bare); partial Rust port datrs	millions (Keet), Tether-backed	Apache/MIT	strong for L1, heavy
Syncthing/BEP	full folder-sync	Go (C++ port syncspirit)	millions of devices	MPL-2.0	folder-sync only
magic-wormhole.rs	transport	yes	n/a	EUPL-1.2 (caution)	one-shot only

Decision: iroh as the spine. Rationale: our identity is file transfer, secure and reliable, and everything else is accessory. iroh gives dial-by-key identity (NodeID equals Ed25519), production-grade hole-punching, blind relay fallback (self-hostable, preserves our no-server-side-component posture), and iroh-blobs (BLAKE3-verified content-addressed transfer). The commodity-but-brutal connectivity is solved, natively, in Rust. We do not reinvent the tunnel; we innovate on what goes through it.

Keet's Hypercore stack stays as a study base, not a dependency. We take Hyperdrive's append-only signed-drive model for L1 and reimplement the slice we need in Rust over iroh, the same way rclone and rsync were study bases for our existing engine. Interop with the live Hypercore/Pear ecosystem (joining the public Hyperswarm DHT) is appealing but is explicitly an accessory: it would force the heavier Hypercore-in-Rust track, and we will not pay that complexity until transfer is rock-solid first. Note that iroh and Hypercore do not share a wire protocol, so this is a real fork, deferred deliberately.

Reuse story. In the engine, a peer-endpoint and a server-endpoint behave identically, so the DAG transfer engine and rsync-style delta we already own work against a peer with minimal new surface. The peer is "a remote that happens to be another AeroFTP user."

Scope guardrail (chat). Once two peers share a live authenticated channel, chat and voice are nearly free technically, which is exactly the product-drift trap Codex flagged. We are not building a messenger; Keet already does that, superbly. The only in-scope human channel is transfer context: an inline note or comment attached to a transfer or shared drive. "A transfer tool with a human channel," never "a chat that moves files."

Staged track (this is research, not a roadmap commitment)

• Spike, L0. iroh endpoint plus dial-by-key plus send one vault-encrypted, BLAKE3-verified blob between two AeroFTP instances. Days, not months. Retires the number-one risk: does dial-by-key plus hole-punch plus relay actually connect reliably across hostile real-world networks (the exact wall ICQ hit and Codex feared)? Go/No-Go gate here, on measured success rates, before any L1 work.
• L1. Hyperdrive-inspired signed append-only drive in Rust, over iroh. This is where the novel complexity lives, entered only after L0 validates the foundation.
• L2. Peer-brokered remotes, the genuinely original capability, on the same stack.

Honest caveats. iroh is pre-1.0 (API churn), mitigated by it being a replaceable tunnel, not our core logic. datrs is partial and low-activity, which is why it is a study base, not a dependency. Threat model before code (per Codex): E2E via the vault, mutual auth by key, replay resistance, receiver approval, metadata minimization.

Bottom line. Secure, reliable user-to-user transfer first; a peer is just another endpoint. iroh for the tunnel, Hyperdrive's model as inspiration for the shared drive, and everything else (chat, ecosystem interop) accessory and gated behind a working L0. Ehud pointed at the right mountain; this is the Rust-native route up it.

This direction was worked through together with @axpnet in discussion; written up by Claude Opus 4.8 High, Linux station.

[EhudKirsh]

folder-sync only

Did you think of sharing anything P2P other than just folders? Maybe individual files or other data?

[axpnet]

L0 results: it connects. Real cross-network measurements + Go/No-Go

The last follow-up in this thread proposed a staged track and promised an L0 spike: stand up an iroh endpoint, dial a peer by key, send one vault-encrypted, BLAKE3-verified blob between two AeroFTP instances, and put a Go/No-Go gate on measured success rates across real-world networks before any L1 work.

That spike is done. Here is what we measured.

What we built (the L0 instrument)

A tiny, isolated tool (peer-l0-dial) on top of iroh 0.92, kept in its own crate so the modern iroh stack does not touch the main app's dependency graph. It does dial-by-NodeID, hole-punching, and uses a relay only as a fallback. Every transfer is end-to-end encrypted (a pairing-secret stand-in derives an HKDF session key, AES-GCM on the wire) and BLAKE3-verified on arrival, and the receiver sends an application-level receipt ACK only after decrypt + verify both pass, so a reported success is a true end-to-end success.

Getting there meant finding and fixing a handful of real iroh-0.92 issues (the hardcoded production relays reject TLS from our stack, so we use the staging relays; missing discovery; ALPN not advertised; a session-key ordering bug; and a stream-truncation bug that we closed with the receipt ACK). It went from "could not connect at all" to the numbers below.

Real-network tests

The interesting run was across two genuinely different networks:

• a home desktop on fiber (a fixed-line connection), and
• a notebook on a 5G mobile network (behind carrier-grade NAT),

plus a same-LAN positive control. So this is an asymmetric, fixed-to-mobile pair, not a lab loopback.

Results by category

Network	Transfers	Delivered	Path	Notes
Same-LAN, positive control	24	100%	direct	both endpoints on the same LAN
Same-LAN, 4/16/64 MiB ceiling sweep	18	100%	direct	large-blob throughput test
Same-LAN, 100x stability/volume	100	100%	direct	flat latency, no degradation
Home fiber to 5G mobile (RUN3)	~31	100%	mixed	first path-classified series
Home fiber to 5G mobile (RUN4)	20	100%	mixed	both sides agree
Home fiber to 5G mobile, sustained 1-4 MiB (RUN5)	10	100%	mixed	larger blobs over the mobile path
Home fiber to 5G mobile, volume (RUN8 + RUN8b)	70	data 70/70 (100%); receipt 69/70	mixed	one lost return-ACK, no data lost
earlier fiber to 5G (RUN1/RUN2)	~16	100%	mixed	post-ACK-fix
Total	~289	100% data delivered

Throughput

Path	Throughput	Bound by
Direct (same-LAN)	~200 to ~240 MiB/s (1 to 64 MiB blobs)	the engine / crypto ceiling
Home fiber to 5G mobile	~1 to ~2 MB/s	the network (5G uplink + relay)

What the data says

• 100% of payloads were delivered and BLAKE3-verified across ~289 transfers, with sub-second connect times and flat latency over volume (no leak or degradation).
• The only non-success in the entire campaign was a single lost return-receipt on the fiber-to-5G path: the blob arrived and was verified by the receiver, but the sender's ACK did not come back, so the sender recorded a false-negative. No payload was ever lost or corrupted.
• Is a relay mandatory? On the fiber-to-5G pair, every transfer is classified mixed: a direct UDP candidate is found roughly 100% of the time, with the relay held as a backup. So a relay is not proven mandatory for reachability, but iroh 0.92's path reporting is coarse and cannot tell us whether the bytes actually flowed direct or via the relay. We keep a relay as the safe assumption for now.
• The bottleneck is the network, not the code. The same stack does ~200+ MiB/s on a direct LAN path and ~1-2 MB/s over the 5G + relay path.

Verdict: GO (connectivity gate)

The number-one risk from the last post - does dial-by-key + hole-punch + relay actually connect reliably across real networks, the exact wall ICQ hit in 2003? - is retired for the conditions we tested. Against the §8 criteria: direct transfer succeeds often enough (yes, fixed-line to mobile), the pairing/trust UX fits one screen (the L0 stand-in is a pairing secret plus a fingerprint confirmation), and the scope stays "transfer, not chat".

Honest caveats

• We tested one asymmetric pair (home fiber to a 5G mobile link, with the mobile side behind carrier-grade NAT) plus same-LAN. The hardest NAT case - both ends behind carrier-grade NAT (for example 5G to 5G), or double-NAT / corporate, Starlink, cross-continent - is still untested.
• iroh 0.92's mixed classification is too coarse to split direct-vs-relay bytes.
• This is a research spike, not a shipped feature. The code lives in an isolated crate and is not merged into the app.

What's next

1. Relay policy + privacy. Our PRIVACY.md currently states "no relay". The data shows a relay is not strictly mandatory but is still in every cross-network path as backup. The decision (self-host a blind, self-hostable relay / accept staging for research / revisit the privacy statements) comes before any relay ships.
2. Optionally broaden network diversity (a both-ends-CGNAT or double-NAT pair, the harder NAT case).
3. Then L1: the Hyperdrive-inspired signed, append-only drive over iroh - where the genuinely novel work lives.

Thanks @EhudKirsh for being part of the thread as always; the Syncthing instinct (do not reinvent identity, relay, or NAT) lines up with what the data shows. The transport question is answered; the interesting product questions (identity, trust, relay policy) are next.

L0 spike and the cross-network measurement campaign run from the Linux dev stations; written up by Claude Opus 4.8.

[EhudKirsh]

The bottleneck is the network, not the code.

The transport question is answered;

Please test it between your devices disconnected from WiFi, Ethernet, etc, over USB Tethering 🔌, and let's see the real bottleneck.
Please use the fastest USB cable you have, like USB4, and the fastest USB C port on your computer/laptop.
If there's a problem with the home WiFi, or I want to bisync a lot of data like multiple GB of music or video files, I bisync my Android phone and PC via Syncthing over USB Tethering 🔌. I use BasicSync on Android, which is a new and efficient GUI client for Syncthing.

[axpnet]

Thanks @EhudKirsh, that is the right instinct, and we actually already have that number.

The fastest-path measurement in the campaign is the direct, local control (both endpoints controlled, no real network in between): ~200 to 240 MiB/s for 4 to 64 MiB blobs, and flat across those sizes. That rate is above gigabit (125 MB/s) and does not change with blob size, which is the signature of a per-byte processing limit, i.e. the engine / crypto ceiling, not the link. The same code does ~1 to 2 MB/s over the fiber-to-5G path, so when the network stops limiting, the transfer saturates to ~200+ MiB/s. On a fast local path the bottleneck is already the engine, not the wire.

One clarification on USB tethering: the usual setup (a phone sharing its mobile data to a computer over USB) is still the mobile network, so it would land in the same band as our 5G numbers (network-bound, ~1 to 2 MB/s), not a fast local path. The genuinely fast local path is two devices linked directly, which is exactly what this control measures. A direct USB4 link is ~40 Gbps, well above our ~1.6 Gbps engine ceiling, so it would reproduce the ~200+ MiB/s engine bound rather than reveal a new one. Happy to add it as a fourth category for completeness.

When we do want more than ~200 MiB/s, the lever is the transfer engine (parallel streams, larger chunks, pipelining), not the link. That is productization work, and it sits after the layer we are building now: the signed, verifiable drive on top of the transport.

And yes, the Syncthing-over-USB pattern is a great fit for bulk local sync. Our transport would behave the same way on that path (engine-bound), which is rather the point.

[EhudKirsh]

One clarification on USB tethering: the usual setup (a phone sharing its mobile data to a computer over USB) is still the mobile network.

By default, USB Tethering does two things as far as I understand:

1. Shares the phone's WiFi or Cellular Mobile Data internet connection to the PC, one-way.
2. Creates a two-way LAN network essentially between the phone and PC.

I focus here on the 2nd aspect.
The phone and PC can be entirety disconnected from anything else other than each other, and the 2nd aspect will still work.
Think of a phone and a laptop in a Faraday cage connected via USB Tethering with no WAN or any other LAN connection.

By the way, a note on the first aspect: There's an app also coded in Rust called Gnirehtet (Tethering spelt backwards) which completes the 1st aspect to be two-way, or in other words, share the PC's internet connection, such as from WiFi or ethernet, to the phone.

[axpnet]

Spot on, and the Faraday cage is exactly the property I care about. A direct two-way link (USB tethering, the same LAN, a full-cone NAT) is the best case here: the transfer goes straight peer to peer, no relay and no internet. The relay and the DHT only exist for the hard case, two peers behind NATs on the open internet. Offline you still need the initial address exchange, but the share token (or a QR, or mDNS) carries it, so the Faraday-cage run really works: two devices, a cable, bytes moving with zero infrastructure. I want to add exactly that as a gate. Nice pointer on Gnirehtet too.

[axpnet]

Progress update: the RFC is now a working, gated engine

When I opened this RFC I said the goal was not to rebuild something that already exists, but to find the missing link for the suite. Here is where the research stands. It now exists as a working engine on a research branch, validated gate by gate, with real transfer numbers. This is a status report, not a release.

What it is

A "drive" is a signed, encrypted, versioned folder that one user publishes and another verifies and replicates peer to peer, with no account and no central server holding the files.

• Transport over iroh: QUIC, NAT hole punching, a relay only as a fallback for the connection handshake.
• Replicated signed documents (iroh-docs) for the file index, content addressed and verified by BLAKE3. This is the "don't reinvent" call from earlier in the thread: we reused a proven replicated-log layer instead of writing one from scratch.
• An encryption layer on top: a random content key per drive, AES-256-GCM per file, and a manifest that records the plaintext BLAKE3 of each file so integrity is checked after decryption.
• Identity is an Ed25519 key per user (an "AeroFTP-ID"). Read access is granted by sealing the content key to the recipient's public key (X25519 ECDH, HKDF, AES-GCM), carried in a signed token.
• Revocation is a re-key: rotate the content key and re-encrypt in place, so a removed reader cannot decrypt new versions while a re-grant restores access.

Real transfer numbers

A 128 MiB drive (one 128 MiB random blob plus three small files), published by one process and replicated by another, integrity verified on both sides:

RESULTS · peer-to-peer encrypted drive · research branch
========================================================
payload      128 MiB blob + 3 files   (4 entries, 134,217,752 B)
integrity    BLAKE3 on plaintext + SHA-256 cross-check   OK
end-to-end   16.03 s   via public fallback relay
             15.19 s   via a self-run local relay
throughput   ~8 MiB/s  (identical on both relays -> engine bound,
                        not relay bound; whole-file AES-GCM today,
                        streaming is the next optimization)
exit         0

And the live cross-NAT gate, the one that matters most for a real user, with the replicator on a mobile hotspot:

GATE · key path over a mobile carrier (CGNAT) · 5G hotspot
==========================================================
drive        4 files incl a 4 MiB blob   (4,194,339 B)
result       4/4 verified by BLAKE3, blob byte-exact
replicate    ~3 s end-to-end over 5G
revocation   old key -> decrypt fails, 0 files written, non-zero exit
             re-grant -> access restored, 4/4 again

Methodology (technical)

1. Gate driven. Each capability is a named gate with one explicit pass condition; the next gate does not start until the current one passes. A capability that is not gated does not count as done.
2. Fixed harness. Each gate is a reproducible sequence: build the drive set, peer publish --store <dir> on side A, capture the namespace and DocTicket, peer grant --to <AeroFTP-ID> to seal a token, then on side B peer import <token> --from <issuer> followed by peer replicate <ticket> --out <dir>.
3. Integrity at the edge. Every run reports per-file BLAKE3 over the decrypted plaintext and is cross-checked with SHA-256 on both ends. The manifest is the only place plaintext integrity lives; the document entries hash the ciphertext, so transport and content are verified independently.
4. Negative controls. Every security claim is paired with a failure that must occur: wrong content key -> manifest fails to decrypt and zero files are written; revoked key after a re-key -> still syncs the ciphertext but cannot decrypt the new version; wrong issuer on a token -> fails to open before any content is touched.
5. Honest labels. A gate records exactly which networks were on the path, and when a label was overstated we corrected it (below).

The coordination channel was AeroFTP itself

The work ran as two automated engineering sessions on two machines on two networks, one as publisher, one as replicator. They never shared a shell. They coordinated only over AeroFTP's own SFTP transport to a shared NAS, driven by the AeroFTP command line. The tool under construction was also the bus over which it was built.

The protocol, technically:

• A single state file is the token. Fields: NEXT_ACTOR (which side acts), PHASE, NEXT_ACTION, BRANCH_HEAD, LAST_MSG. A session acts only while NEXT_ACTOR names it, then rewrites the file to hand the token back. This is a strict turn lock over a file.
• Numbered inbox messages (NNNN-from-X-to-Y-*.md), append only, record each step and result, so the run is fully replayable from the NAS.
• A heartbeat file is rewritten on every polling cycle for liveness.
• Liveness and handoff are kept by background polling loops: while it is the other side's turn, a session polls the NAS on a fixed cadence (a cat/ls of the state file and the gate folder via the AeroFTP CLI), refreshes its heartbeat, and takes the token the moment the awaited artifacts (a ticket, a token, a result file) appear. During a live gate the publisher process stays alive serving the drive until the replicator advances the phase, then control is handed back.

AeroShare: a user is just another server in My Servers

The product surface for this has a name now: AeroShare. It is the design idea I am most happy with. AeroFTP is already a transfer fabric between endpoints, with a list of saved connections in My Servers and a dual-panel browser. So a friend is not a new app, it is a new kind of connection:

• You add a friend the same way you add a server, by their AeroFTP-ID, and they appear as a card in My Servers next to your FTP, SFTP and cloud connections.
• You click the friend's card to connect, exactly like a server.
• What changes is only what is on the other side of the dual panel: their shared folder, kept in sync locally, browsable and transferable like any remote. Drag from a friend to an S3 bucket, or from an FTP server to a friend, with the same engine.
• If no folder is shared yet, the connection opens a short setup step instead, then the folder appears.

In other words, peer to peer is just a channel in the file manager. It is not a chat. The dual panel is the centerpiece. AeroShare is the GUI layer that exposes all of this, and it is now in progress on the same research branch.

Correcting the record

One cross-NAT gate was first described as a wide-area test. On review, both machines for that run were on the same home router, so the honest label was same network, not wide area. The cross-NAT realism was already proven separately on a mobile carrier, so the conclusion held, but the wording was overstated for that run and we fixed it. Noting it here because a test log is only worth trusting if it also reports the times the first claim was too strong.

The direction that excites me: no operator in the middle

A hard design line: this feature must not depend on infrastructure that I run. The goal is a network where every AeroFTP user is a node. Two further gates show this is reachable. Discovery can run purely over the public BitTorrent Mainline DHT, with no query to any default discovery service: in one gate the replicator was handed only a node identity, no addresses, and still located the publisher and completed the transfer. And relays can be federated: a peer publishes its own relay address to the DHT, another peer discovers it and connects to that relay even though it is not in its own set. A full transfer then runs with discovery on the DHT and a relay you run yourself, with no single operator on the path.

Honest about what is not done

Delivery to a peer who is offline is not solved (both sides must be online for a live transfer, though the replicated copy stays browsable locally). Streaming for very large files is pending, which is why the 128 MiB number above is engine bound rather than link bound. A privacy and threat model writeup, a security review, and translations come before this leaves experimental.

Feedback welcome, especially on the connectivity model (DHT discovery plus federated relays) and on whether "every user is a node" is the right north star to keep this independent.

[axpnet]

are you ready? 🚀

[EhudKirsh]

AeroShare sounds good. It may indeed make sense to give it an E2E badge since its main encryption purpose would be E2EE during transfer as opposed to Crypt at rest, although Syncthing supports the latter as opt-in as well.

Decentralised P2P sharing that can work over LAN is definitely the right move to make.

are you ready? 🚀

Unfortunately, I only have 1 PC to try and need this on. I'll gladly test AeroShare as soon as there will be a phone AeroFTP app.

[axpnet]

On the badge: agreed, and it is already in. AeroShare encrypts the drive content itself end to end under a 256-bit key the local vault custodies, so both the bytes on the wire and the blobs in the replication store are ciphertext, not just the transport. The friend tile carries an "E2E 256-bit" badge to say exactly that. The reconstructed copy on your side is plaintext (they are your files); an at-rest option there, Syncthing-style opt-in, is a fair future addition but separate from the E2E guarantee.

On decentralised LAN P2P: yes, that is the spine. A same-LAN run (or USB tethering, your Faraday-cage case) goes straight peer to peer, BLAKE3-verified, with the relay used only for the initial handshake in the hard NAT case. We just validated the full path end to end, including a share created in the GUI and pulled from the CLI on the other side, nested folders and all.

On "share beyond folders": good question, and it is the scope line we hold. A peer is an endpoint exactly like a server, so you transfer to a friend the same way you transfer to a remote, in the same dual-panel My Servers view. The unit today is a signed, encrypted, versioned folder/drive, and a single file is just the one-item case of that, so individual files are already in. What we deliberately left out is the conversational layer: we looked at text and audio chat and set it aside for now, for complexity and because it would drift AeroFTP from a transfer client into a messaging substrate (the "we are not building a messenger" guardrail). Nothing is permanently excluded, but the rule stays simple: if it is a file or data transfer it is in scope, if it is conversation or presence it is not.

On testing: understood, a phone AeroFTP app is the unlock for you, and it is on the radar. For now AeroShare Phase 1 is a working, gated Beta on the research branch: identity, manual share and receive, read-only replicas, friend cards in My Servers next to your FTP/SFTP/cloud connections.