-
-
The native Mac app starts a disposable guided exchange without setting up a real identity.
-
Real carrier inspection: two missing data shards and two hash-bad parity shards; a fifth erasure was refused.
-
Alice reaches Confirmed after Bob's signed receipt returns; the exported JSON evidence report is unsigned.
Inspiration
What if two computers cannot be online together? UUCP's store-and-forward workflow treated intermittent connectivity as normal: prepare work, carry it when a route becomes available, and process it at the other end. RelayPost reimagines that workflow as a native application for encrypted offline file handoffs. We are entering Resurrection.
A target scenario is carrying a static batch of research files to an offline workstation and returning evidence that it saved the correct bytes. This is a proposed use case, not a claimed field deployment.
Store-and-forward is still useful. NNCP is a modern reference, and PAR2 tools already repair damaged data. RelayPost does not claim to invent those mechanisms or replace NNCP's routing features. Its experiment is to bring a complete one-to-one handoff, repair and confirmation journey into one native interface.
What it does
Two device identities exchange public cards, compare complete fingerprints through a trusted channel, and pin trust. The sender seals static regular files into a recipient-encrypted, signed parcel and exports it to a carrier directory.
The receiver authenticates the sender, checks shard hashes, reconstructs within each group's repair budget, verifies the ciphertext, decrypts and validates the files, then publishes a complete batch without replacing an existing one. Only after that verified save does it create a signed receipt.
Exporting leaves the sender Awaiting Signed Receipt. Even after the receiver saves the files, the sender keeps waiting. Only the expected recipient's verified return receipt makes it Confirmed. That receipt attests to this verified save, not human readership or permanent storage.
The native guided demo creates two disposable identities and two synthetic files totalling 21 MiB. It deletes two data shards and corrupts two parity shards, proves that a fifth erasure causes actual receive refusal without a success receipt, then repairs the remaining four. Both received file hashes must match their sources. The interface shows the real result; the exported unsigned JSON report includes the complete source and received SHA-256 values and refusal evidence. The delivery receipt itself is signed.
How we built it
One Rust core serves a clap CLI and an egui native interface. Existing age and Minisign libraries provide recipient encryption and signatures. SHA-256 identifies content, Reed–Solomon provides grouped erasure repair, and SQLite indexes delivery facts. Verified published files and authenticated metadata authorize recovery. The CLI and native guided demo use the same demo engine.
The public v0.2.0 build comes from commit 10c0de3. Its exact-source CI passed formatting, Clippy, 11 unit tests and 30 integration tests on each of Linux and macOS, real CLI acceptance workflows, and extracted-package checks. All Rust builds and tests ran remotely in GitHub Actions.
How Kiro was used
Actual Kiro CLI sessions inspected the existing code, wrote project steering and requirements/design/tasks, then directly implemented the shared demo engine, CLI command, first-use onboarding and staged native walkthrough. A repository-local custom agent had file read/write tools only.
The strategy was to review the specification before implementation: real five-erasure refusal, separate saved and confirmed states, isolated synthetic profiles, and one shared core. Kiro amended the spec after review, then implemented through existing APIs. This made the user journey and its failure boundary concrete before interface work.
Codex authored the original application, independent acceptance tests, release
tooling, review and final hardening. Some Kiro sessions were interrupted by
service throttling; Codex's final amendments remain credited to Codex. We claim
no unobserved Kiro IDE, Crew, hook, MCP or model use. The
usage record
and session evidence
identify actual writes, interruptions and review changes. Root .kiro/ contains
the agent and specifications used in that work.
Challenges and lessons
Carried, repairable, saved and confirmed are different facts. The difficult part was preventing a plausible progress display or damaged local copy from changing their meaning. Repair precedes authentication of the complete payload; confirmation waits for a receipt that really returns.
The 21 MiB fixture crosses a full 20-data/4-parity group into a smaller tail, making both the per-group budget and four-versus-five refusal boundary visible. It is not a throughput benchmark.
Demo and current scope
The narrated walkthrough uses newly captured footage of the public v0.2.0 native Mac app, with English narration and captions. It shows real preparation, a five-erasure refusal, four-shard repair, matching file hashes, and confirmation only after the signed receipt returns. Native captures are edited with cuts and held frames for explanation; no generated UI outcomes or fabricated processing are substituted. The demonstration runs on one Mac, using two isolated synthetic profiles and a directory carrier. It does not demonstrate physical USB media or a second computer.
The Apple Silicon desktop prototype is ad-hoc signed, without Developer ID signing or notarization. It accepts up to 100 static regular files and 64 MiB per real batch. There is no independent security audit, physical power-loss validation, measured performance result, cloud recovery or remote execution.
The submitted build focuses on the encrypted offline handoff and its actual failure boundary. The public application, source, exact-source CI and Kiro session evidence remain available at the links below.
Source: public MIT-licensed GitHub repository. Try it: working native build and checksums. No runtime AI account or application login is needed.
