AlterSend: peer-to-peer file transfer with a join code instead of a cloud inbox
Send files directly between devices over the internet - no cloud storage, no size limits.
At a glance
- What is it?
- AlterSend sends files directly between devices over Hyperswarm, with a relay fallback for NAT-bound peers. Here is how the join code works, how to install it, and where the design runs out of road.
- Who is it for?
- AlterSend fits people who move very large files between their own devices, or to a recipient who will open a browser link once, and who would rather not create an account on a storage service. It is the wrong tool when the recipient is offline, when a corporate network blocks non-HTTP traffic, or when a policy requires an auditable server-side record of every transfer.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 26 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem AlterSend removes: the upload step
Most file transfer tools insert a server between two people. You upload, the service stores the bytes, the recipient downloads, and the file sits on someone else's disk until a retention policy deletes it. That model imposes two costs at once: a size ceiling tied to a storage plan, and a copy of your data outside your control.
AlterSend's answer is to delete the middle step. The README states the app is for sending files directly between your devices, with no cloud storage and no uploads, and that files transfer P2P with no size limit. The stated audience is anyone who would otherwise reach for WeTransfer, Dropbox or Google Drive to move a file to a specific person. The project lists no accounts, no signup and no email address as features, which matters if the recipient is a one-off contact you do not want to onboard into a service.
The second audience is narrower and more technical: people who move files between their own machines. A pairing feature lets you pair a device once and then send to it without scanning a code each time, which turns AlterSend into a personal transfer channel rather than a per-file ritual.
How the join code becomes a direct connection
The mechanism is a Kademlia distributed hash table, specifically Hyperswarm. The README describes four steps. Each transfer generates a random 32-byte key with crypto.randomBytes(32), and the 64-character hex string of that key is the join code you share. Both peers then compute a discovery key, a BLAKE2b hash derived from the join code, and join the DHT on that hash. The raw key is never published; only its hash goes out.
Public bootstrap nodes are the only entry point. They get peers onto the DHT, and after that no central server participates in discovery. Peers connect over a Noise-encrypted socket. The sender reads each file off disk in chunks and hashes every chunk with BLAKE2b.
The fallback path is the part worth understanding before you rely on it. When a direct connection cannot be established, usually because both peers sit behind symmetric NAT such as two VPN users, the transfer falls back to a relay that forwards the already-encrypted stream without seeing file contents. The README says the relay is on by default and can be turned off in Settings, under Relay. That is a real trade-off: the relay cannot read your files, but it does learn that two peers are transferring, and it carries your bandwidth. If your threat model includes traffic analysis rather than content disclosure, turning the relay off means transfers fail in exactly the NAT configuration it exists to rescue.
Installing AlterSend on macOS, Linux and Windows
The README points to altersend.com/download and a table of platform builds: a signed Microsoft Store listing and an EXE installer for Windows, DMG builds for Apple Silicon and Intel on macOS, AppImage and Flatpak for Linux, Google Play and an APK for Android, and an App Store listing for iOS.
On macOS, Homebrew installs the cask:
brew install --cask altersendThe Linux Flatpak path is a build-from-manifest route rather than a published remote. The README notes it needs flatpak-builder, and clones the repository first:
git clone https://github.com/denislupookov/altersend.git && cd altersend
flatpak-builder --user --install --install-deps-from=flathub --force-clean build-dir flatpak/com.altersend.AlterSend.yamlArch users have two AUR packages, altersend-bin for official release binaries and altersend-git for the latest Git changes compiled from source:
yay -S altersend-bin
yay -S altersend-gitFor a first transfer, the README's four steps are the whole flow: open AlterSend on both devices, one device shows a join code or QR, the other scans or types it, and files transfer directly. The recipient does not need the app at all if they open a share link at app.altersend.com and download straight from the sender. That browser path is the feature that decides most adoption questions, because it removes the install negotiation with the other person.
Building from source and the workspace layout
The repository is an npm workspace monorepo with packages/* and apps/* as the two workspace roots. The root package.json is private and licensed Apache-2.0. The scripts reveal the intended order of operations: build:libs compiles packages/drive, packages/core, packages/locales, packages/domain and packages/components in sequence, and every app script depends on it.
npm run build:libs
npm run desktop:devThe desktop entry point is desktop:dev, which runs build:libs and then npm start in apps/desktop. There is a desktop:dev:peer2 script for running a second peer, which is the practical way to exercise a transfer on one machine. Mobile follows the same shape with mobile:setup and mobile:start. Lint runs eslint across apps and packages with --max-warnings=0, and formatting is enforced by prettier through format:check, including docs/*.md. A knip.json at the root suggests unused-export checking is part of the tooling.
One caveat about the developer path: the README's setup and prerequisites sections were truncated in the repository listing shown here, so the exact Node version and any native toolchain requirements are not something I can quote. Check the Prerequisites heading in the README before running the scripts above. The build:libs step is not optional, and skipping it is the most likely cause of a failed first run.
Where AlterSend is the wrong tool
The design assumes both sides are online at the same time. There is no store-and-forward: the README describes files going directly between devices and nothing being uploaded or stored on a server. If the recipient is asleep, on a plane, or in a different time zone, the transfer does not queue. That is the single biggest operational difference from a cloud drive, and it is a deliberate one, not an oversight.
The second constraint is network policy. Discovery depends on reaching public bootstrap nodes and on the DHT, and the transport is not plain HTTPS to a well-known host. Networks that allow only web traffic through a proxy will break the direct path, and the relay is the only recovery. If the relay is disabled in Settings, that recovery is gone.
The third is that peer-to-peer transfers need both endpoints to stay awake and connected for the duration. A 500 GB archive, which the README cites as an example alongside a 100 MB photo, is a long-lived connection. A laptop that sleeps, or a phone that switches from Wi-Fi to cellular mid-transfer, is a failure mode the README does not document. There is no described resume behaviour, and the README does not document rollback either. Treat a large transfer as an uninterrupted session until the project says otherwise.
AlterSend against Syncthing and against cloud drives
Syncthing is the closest open source comparison, and the difference in approach is fundamental. Syncthing synchronises folders continuously between devices you have permanently paired, using its own device IDs and a long-running daemon. It is built for a steady state: the same folders stay in sync, and transfers happen whenever both ends are reachable. AlterSend is built for a discrete act. You generate a join code for one transfer, the key is random per transfer, and the recipient can be a stranger who opens a browser link. Syncthing has no equivalent of that one-off browser recipient, and AlterSend has no equivalent of a folder that stays mirrored.
The cloud-drive comparison is simpler. WeTransfer, Dropbox and Google Drive give you an offline recipient and a durable link, at the cost of an upload, a storage quota and a server-side copy. AlterSend trades those away for immediate, direct transfer. The README frames this as the reason to choose it over those services, and that framing holds as long as the recipient is online and the network permits it.
Maintenance, releases and what the licence file actually says
The repository is not archived, and the last push was on 2026-08-23. Recent releases are v2.0.0 on 2026-08-21, v1.8.0 on 2026-08-01 and v1.7.0 on 2026-07-22, which is a steady cadence across roughly a month. For an upgrade decision, the practical signal is the v2.0.0 bump: a major version usually means the desktop and mobile apps need to move together, and the README gives no compatibility statement about mixed versions between peers. Upgrade both ends if a transfer fails after one side updates.
The licence situation needs a caveat. The repository metadata reports the licence as NOASSERTION, while the README badge says Apache-2.0 and the root package.json carries "license": "Apache-2.0". A NOASSERTION result from automated licence detection usually means the tool could not match the LICENSE file to a known template, which can happen with added notices or appended text. Read the LICENSE file at the repository root yourself before you redistribute anything. I am not giving legal advice, and the badge is not the licence.
Maintenance cost for a user is low, since the app updates through the platform store or the package manager you installed it with. The cost that is not low is the relay: it is a piece of shared infrastructure the project operates, and the README does not state who runs it or what its capacity is.
Editorial conclusion
AlterSend fits people who move very large files between their own devices, or to a recipient who will open a browser link once, and who would rather not create an account on a storage service. It is the wrong tool when the recipient is offline, when a corporate network blocks non-HTTP traffic, or when a policy requires an auditable server-side record of every transfer. Before relying on it, verify the relay setting in Settings, confirm the licence file in the repository matches the Apache-2.0 badge, and check the release page for the platform build you need, since the desktop, mobile and Flatpak paths are built separately.
Frequently asked questions
What are the best file sharing sites in 2026?
The repository does not publish a comparison against other services. It positions AlterSend against WeTransfer, Dropbox and Google Drive on one axis only: those services require an upload and store a copy, while AlterSend sends files directly between devices with no cloud storage.
How can I encrypt files for file transfer?
With AlterSend you do not configure encryption separately. The README states peers connect over a Noise-encrypted socket, the sender hashes each chunk with BLAKE2b as it reads the file off disk, and only your devices can read your files.
What is a file sharing platform?
In AlterSend's case it is not a platform in the storage sense. The README describes a peer-to-peer app with no accounts and no server-side storage, where one device shows a join code or QR and the other scans or types it to start a direct transfer.
Community notes