This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.
What I Built
A freelancer can spend days preparing a beautiful deliverable and lose the client's confidence in the final thirty seconds. The file is too big for the attachment, the client doesn't want another login, the compressed version looks terrible, or a document arrives without a clear explanation of what needs reviewing. We tend to treat each of those failures as a reason to buy another cloud service. I wanted to find out whether the handoff itself could become a small, useful product.
I built File Ferry, a local-first packaging and recipient-briefing workbench for independent designers, consultants, contractors, and other people who regularly hand clients project files. The promise is deliberately narrow: choose a file, select your own per-attachment size budget, decide whether you want exact preservation or a clearly labeled derivative, and prepare an honest package. File Ferry never pretends it sent the files. It prepares them for a delivery channel the user controls and gives the recipient a separate tool to check what arrived.
If the original fits, the exact bytes are preserved. If it doesn't, File Ferry divides the original into numbered parts, calculates an individual SHA-256 hash for each, and produces a manifest that travels with those parts. The recipient can open the companion reassembly workbench, select the manifest and pieces, and verify the reconstructed file. For photographs, there's an explicitly lossy WebP route. For supported text, there's a local compression route. These alternatives never quietly masquerade as the original. The most interesting lane is a recipient-focused AI evidence brief: rather than dumping an unstructured document on the client, the sender can ask, for example, “What needs approval and when?” and have an open embedding model select relevant, unaltered sentences from the local source text.
That makes this a plausible side hustle in two directions. A freelancer could use it to make every handoff more professional without giving a third-party AI API their clients' documents. Alternatively, the tool itself could be offered as a small paid utility for people who repeatedly prepare client deliverables. A possible starting hypothesis is a modest monthly convenience subscription for branded handoff workflows, not a claim that anyone has paid us yet. We have no verified paying customer or real-client delivery for this prototype. A useful next experiment is to put it in front of a working freelancer, ask them to complete a real but permissioned handoff, and find out which step still causes friction.
Demo
Live interactive demo: Open File Ferry. Recipient verification page: Open File Ferry Reassemble. Both pages have been fetched publicly. No login is required, and exact packing does not need a model download. For local reproduction, serve the repository with python3 -m http.server 8765 and open index.html. The optional AI pathway starts only when someone taps the model-load button.
For a reproducible integrity example, I generated a synthetic 4 MiB packet and set a 0.5 MiB per-part budget. The algorithm produced eight numbered parts, reconstructed all 4,194,304 bytes, and reproduced the exact SHA-256 checksum: 187588e5836f3f214237366d9bf52b0505477ef2b08898c4f87b17d61a85781c. A one-byte alteration was rejected. That is a local, automated data-integrity test, not an email or recipient-delivery receipt. The proof can be regenerated with node tools/reproduce-proof.mjs docs.
The eight existing automated tests pass, covering exact reassembly, missing or duplicate part rejection, hash mismatch detection, size-budget semantics, and embedding-ranking logic. The public front end and recipient page respond successfully, and the automated data-integrity tests pass. Remaining limit: actual open-model weight downloading and a full browser end-to-end AI inference run have not been independently verified. The AI path refuses to claim readiness until actual 384-dimensional inference completes in the user's browser. This technical boundary still needs an independent live-device check.
Code
Public MIT-licensed Week 2 source: File Ferry on GitHub (isolated public release branch). The implementation is plain HTML, CSS, and JavaScript ES modules with automated Node.js tests. Only the File Ferry source tree is included on this release branch, and the existing repository's main branch was not modified. The source includes an MIT license from Evercraft LLC. The application does not include or license other private Evercraft systems.
How I Built It
File Ferry separates routing, transformation, evidence, and delivery rather than letting one success message blur them together. The core module classifies a user-selected file and chooses a route based on its real size, a bounded user-chosen budget, and whether byte-for-byte preservation is required. Lossless packing slices the original into bounded pieces, hashes each piece, and writes a strict manifest. Recipient-side reconstruction rejects absent files, duplicates, unexpected sizes, modified bytes, and incomplete totals. For originals up to 32 MiB, the final byte sequence is checked against a whole-file SHA-256 digest; larger files have individual part hashes without a falsely labeled full-file digest.
The AI side is intentionally extractive. File Ferry uses Transformers.js and the open-weight Xenova/all-MiniLM-L6-v2 sentence-embedding model. The browser downloads the runtime and weights only after the user requests AI. Then the recipient's question and each candidate source sentence are embedded locally. A cosine-similarity ranker selects the most relevant unaltered sentences and produces an evidence brief. That brief is visibly marked as a derivative. It isn't a substitute for the source, an independently verified summary, or a promise that the selected text captures every important fact. The model's usefulness is testable and contestable precisely because this is an inspectable local pipeline, not a hidden API response.
The front end intentionally has no account registration, billing dependency, delivery API, or platform-specific upload promise. Source files remain on the sender's device while File Ferry prepares local output. The runtime and model do require a first-time download, so I won't claim a fresh browser can perform AI inference with no internet. Nor do SHA-256 checks protect against malware or prove who sent a file. Those distinctions matter because trust is part of the product, not a decorative label.
Why Does Open Innovation Matter?
I don't think freelancers should have to feed private client material through a proprietary remote model merely to tell a customer what to review. Open-weight local embeddings change the cost and control structure. The sender can see how a brief is assembled, keep the source on their own machine, and modify the ranking or swap the model without rewriting the packaging engine. After the necessary runtime and model are cached, the inference happens on-device rather than depending on a paid inference endpoint for every brief. The file-splitting and verification paths are separate and use browser-native primitives, so a temporary AI problem doesn't destroy the original handoff.
Open source also exposes the failure modes. Someone can inspect whether a manifest is actually checked, reproduce the synthetic byte test, or notice that a derivative has lost detail. A hidden service could claim a file was “handled”; this tool can show exactly what was prepared, and explicitly say what still needs to be delivered. For a small business trying to earn trust, that difference is more valuable than an impressive success animation.
The next version would test the model on real permissioned handoffs, add a user-approved batch download or archive route, and record a genuine recipient acceptance event. Those are goals, not completed features. File Ferry currently demonstrates that reliable client handoffs and useful local AI can be assembled without turning an ordinary attachment into another opaque dependency.
Top comments (0)