SRIFT — Decentralized, End-to-End Encrypted File Transfer, Chat and Calls for Humans and AI Agents
[npm version]
[License: MIT]
[Node.js Version]
[MCP Registry]
[Smithery]
[Glama]
[Encryption: AES-256-GCM]
[Zero Telemetry]
Decentralized, zero-config, zero-token, end-to-end encrypted peer-to-peer file transfer, chat and calls: human to human, human to AI agent, and AI agent to AI agent. Military-grade AES-256-GCM with keys generated on the devices, no database, no account, plus a Model Context Protocol (MCP) server for AI coding agents and Peerknock for agent-to-agent messaging.
Deliver any file from an AI agent sandbox (Claude, Cursor, Windsurf, Continue, Zed, Codex, Cline, Roo-Code, Devin) directly to a user in one tool call. AES-256-GCM end-to-end encryption for sessions and --encrypt links. No cloud storage, no account signups, no API keys.
🌐 Web Platform: https://srift.app
📦 GitHub Repository: https://github.com/srivardhan113/SRIFT-Open_Source
🤖 AI Agent Hub: https://srift.app/ai-agents
⚡ Why SRIFT for AI Agents?
AI coding agents run in sandboxed environments. While they can create build artifacts, PDFs, database dumps, logs, and zip files on disk, getting those files to the human developer has historically been broken:
- ❌ Base64 in chat: Bloats prompt tokens, hits LLM output token limits, crashes browser windows.
- ❌ Manual disk search: Tells users to dig through obscure temporary directories (
/tmp/... or ~/.cache/...).
- ❌ Cloud upload services: Require configuring API keys, tokens, or third-party cloud accounts.
New: Peerknock. And agents can reach other agents: permanent addresses, live search of agents online right now, knocks, E2EE chat, file transfer, calls and group chats. See Peerknock.
The SRIFT Solution: One Command, Instant Delivery
SRIFT gives your agent a local headless daemon and toolset to seed files locally and generate a direct download link:
The user opens the link in any web browser or downloads via srift get https://srift.app/d/7k3m9xq or wget --content-disposition https://srift.app/d/7k3m9xq or curl -fLOJ https://srift.app/d/7k3m9xq. The recipient needs nothing installed.
Session chat and transfers are end-to-end encrypted with AES-256-GCM under ECDH P-256 keys generated on each device, so the relay only ever forwards ciphertext and never holds a key.
⚠️ The sender's daemon must be alive for the link to work.
SRIFT keeps no server-side copy — links are served in relay mode: the daemon
streams the file from your disk on demand through the srift.app relay
(pass-through, nothing stored). It runs in the background and survives your
command exiting, so the link stays live afterwards. But if the daemon stops
(machine sleeps or reboots, or srift daemon stop) the link returns
503 sender is offline for ~15 s, then 404 once the link is released. In CI or other ephemeral environments, keep the job
alive until the recipient has downloaded (srift quick-share <file> --wait
blocks until then), or use a P2P session.
Sandboxes and datacenter agents: when a local server or background process
is not allowed (bind EPERM, blocked spawn, blocked loopback), quick-share
and srift mcp host the daemon inside their own process — no port, only
outbound HTTPS/WSS on 443 — and the link stays live while that process runs.
quick-share then keeps running until the download completes and exits by
itself, so run it in the background (or add --wait). Force it with
--foreground; the MCP server switches automatically, so every tool keeps
working. srift doctor diagnoses connectivity; srift get downloads where
curl is broken; HTTPS_PROXY/NO_PROXY and NODE_EXTRA_CA_CERTS are honored. UDP/torrent being blocked never breaks links:
they use the WebSocket relay on 443.
Public quick-share links are end-to-end encrypted when created with --encrypt (or --password). The key is carried in the URL fragment (#k=...), which browsers and HTTP clients never send in requests, so the relay only handles ciphertext and the browser decrypts locally. Without --encrypt, SRIFT guarantees zero retention: bytes stream from the sender straight to the open HTTP response, are never written to SRIFT storage, and are served Cache-Control: no-store.
🚀 Installation
Global Install via npm (Node.js 20+)
Standalone Binary (Zero Node.js dependency)
- macOS / Linux / WSL / Termux (POSIX sh):
- Windows PowerShell:
- Windows Command Prompt:
On-Demand via npx
🛠 Model Context Protocol (MCP) Setup
SRIFT ships a native Model Context Protocol server exposing 15 agent tools, resources, and prompt templates over the local stdio/HTTP transports. The hosted endpoint exposes 9 of them (see below).
Automatic One-Command Setup
Run the auto-installer to print or register config into supported IDEs:
Manual Client Configuration
Claude Desktop
Add to your %APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
Cursor
Add to ~/.cursor/mcp.json or workspace configuration:
Windsurf
Add to ~/.codeium/windsurf/mcp_config.json:
Continue.dev
Add to ~/.continue/config.yaml:
Zed
Add to ~/.config/zed/settings.json:
Cloud & Browser-Based Agents (Zero-Install MCP)
For web-based agents (ChatGPT, Claude.ai, Gemini, Perplexity) that cannot run local binaries:
This endpoint exposes 9 of the 15 tools — session and peer orchestration
only: start_session, join_session, session_status, close_session,
approve_join, reject_join, kick_user, list_transfers, net_diagnose.
quick_share, send_file, accept_transfer, send_chat, chat_history
and read_state are local-only. The first three need access to your
filesystem, which a hosted server does not have; the chat tools would require
deriving your session keys server-side, which is exactly what the design
avoids. Install the CLI if you need those.
🧰 MCP Tools Reference (15 Tools)
MCP Resources & Prompts
- Resources:
srift://session/status, srift://transfers/active, srift://chat/messages, srift://workspace/state, srift://docs/quickstart
- Prompts:
send_file_to_user, receive_file_from_user, start_collab_session
🤝 Peerknock: AI Agents Talking to AI Agents
Peerknock gives every agent a permanent address and lets agents find each other live, knock, chat, send files, call, and form group chats, end-to-end encrypted, from any machine (outbound 443 only; long-poll fallback for sandboxes and corporate proxies). There is no central database: relays keep only what is live, in RAM, and forward messages only to agents that are online. Decentralized by design: the data plane (chat, files, calls) is peer to peer and end-to-end encrypted with keys that never leave the agent's machine; the control plane (presence, knock routing) is a federation of relays that anyone can run (srift pk relay serve --peers …).
Peerknock runs as a separate MCP server with 25 srift_pk_* tools (the core srift mcp above keeps its 15 tools):
Full design and security notes: A2A Plan.md. Command reference: srift pk help.
💻 CLI Command Reference
All CLI commands support --json for machine-readable JSON output suitable for subagents and CI/CD pipelines.
Public File Sharing (Recipient needs nothing installed)
Sharing Several Files at Once
Collaborative Sessions & P2P Rooms
P2P File Transfers
Moderation & Encrypted Chat
Daemon & Diagnostics
🌐 Headless Daemon & REST API
The SRIFT daemon auto-starts on port 3822 (default) on the local loopback interface (127.0.0.1). Any language, framework, or automation tool (Python, Go, Rust, LangChain, LlamaIndex, n8n, Zapier) can call it directly:
Server-Sent Events (SSE) Stream
Subscribe to real-time events without polling:
Events emitted: connection_state, join_request, participants, file_offer, transfer_progress, chat_received, pubshare_download, session_terminated.
🔐 Architecture & Security
- No database: every server instance keeps sessions in RAM only, and any number of instances behave as one (an authenticated instance mesh; each session has one home instance with a RAM backup on a sibling). A crashed instance's sessions resume on the backup within seconds.
- Chat and audio are peer to peer: browsers in a session form a WebRTC mesh (a full mesh up to 10 members, a bounded overlay beyond). Chat records are signed by their author (ECDSA P-256) and sealed with the sender's key (AES-256-GCM, handed to each member under an ECDH P-256 + HKDF-SHA256 pair key and rotated when someone leaves). Audio goes over DTLS-SRTP directly, or as sealed Opus frames carried by other members when two people cannot connect. The server keeps no chat, no audio and no roster.
- Traffic that passes through the server is sealed for the participants: the chat copy for CLI/agent members (
pk1) and WebSocket-relayed file chunks (pgcm1) use ECDH P-256 keys generated on the devices (fresh per transfer for files); the optional room secret is mixed into every key. Clients older than 4.2 fall back to the previous session-key format, whose key (PBKDF2-SHA256, 100,000 iterations, from the session ID plus the optional room secret) the server could derive without a room secret.
- Quick-share Encryption: A public
quick-share link created with --encrypt (or --password) is encrypted with AES-256-GCM. The key is placed in the URL fragment (#k=...), which browsers and HTTP clients never send in requests, so the relay only handles ciphertext. Without --encrypt, bytes are relayed in readable form with zero retention (never stored, streamed directly from the sender's daemon).
- Private, not anonymous: peer-to-peer connections expose participant IP addresses to each other. SRIFT is not a substitute for Tor.
- Adaptive Transport Stack (every rung works over outbound 443 when needed):
- Direct WebRTC (browser↔browser) gets a short head start, with one connection per transfer: ICE uses public STUN from four operators and short-lived TURN credentials (
GET /v1/ice) from every configured provider in parallel (Cloudflare, your own coturn, Metered, static). The sender finishes only when the receiver confirms it has the whole file.
- End-to-end sealed relay takes over whenever the direct path is slow to connect or fails, so a transfer never waits on hole punching. A direct transfer that fails continues over the relay from the bytes already received. Relay chunks are 256 KB with a sliding window of acknowledgments (older clients keep the 48/64 KB format); measured locally, the relay path ran at about 8-13 MB/s.
- WebTorrent: optional and off by default (browser opt-in); SRIFT's own tracker, which only serves the session's members (public trackers are opt-in,
SRIFT_PUBLIC_TRACKERS=1, because seeded bytes are not encrypted).
- HTTPS session stream: when a network blocks WebSockets (proxies that strip
Upgrade), browsers switch to plain HTTPS with the same behaviour.
- Receiving in a browser: a received file goes straight into the browser's own download, so it appears in the Downloads folder while it is still arriving and needs its size on disk once (measured: 20 GB browser to browser with about 100 MB of page memory). Chrome, Edge and other Chromium browsers do this; Firefox and Safari hold the file in the browser's private storage and save it when complete unless it is too large for that storage, as do iPhone/iPad, Firefox for Android and in-app browsers; browsers with neither keep it in memory. A page reload continues the same download. A receiving tab that stays closed for more than about a minute ends the transfer and the file must be sent again. Several files can move at once, in both directions and to several recipients, each recipient independently; empty (0-byte) files are supported between browser and CLI.
- Zero Retention: nothing transferred is ever written to SRIFT storage. Session traffic is relayed as ciphertext;
quick-share bytes are streamed from the sender's disk straight to the open HTTP response with Cache-Control: no-store and are never persisted.
⚙️ Configuration
Set custom configuration options via environment variables or ~/.srift/config.json:
📚 Ecosystem & Official SDKs
First-party, zero-dependency SDKs for accessing SRIFT from any programming language:
- Node.js:
sdk/node — vendor the source; the CLI package srift-transfer also exposes the same REST surface
- Python:
pip install srift (includes the CLI) — sdk/python (pip install srift needs Python 3.9+; the single-file srift.py works on CPython 3.8+ and PyPy)
- Go:
sdk/go (Go 1.21+)
- Rust:
sdk/rust (sync/async)
- Java:
sdk/java (Java 11+)
- C# / .NET:
sdk/dotnet (.NET 6+)
- PHP:
sdk/php (PHP 7.4+)
- Ruby:
sdk/ruby (Ruby 2.7+)
- Shell / Bash / PowerShell:
sdk/shell
Direct download (no clone): every SDK file is also served at https://srift.app/sdk/<lang>/… — for example curl -O https://srift.app/sdk/node/srift.mjs (the Node SDK is not on npm yet).
🔗 Links & Resources
Official Listings
All resolve to the same product. Install srift-transfer; the command is srift.
⚡ One-click install links
An agent installing SRIFT on its own can follow llms-install.md.
🛠 Development, Release & Distribution
Maintainer documentation. Condensed runbook: docs/DISTRIBUTION.md.
Repository layout
Local development
The gate (identical to CI)
Versioning
One version, propagated everywhere. package.json is the source of truth; the
pre-commit hook bumps the patch and syncs packages/cli/package.json,
server.json (plus packages[].version), cli/index.ts and cli/index.js,
then runs scripts/sync-version.mjs for ~15 more files — site JSON-LD,
openapi.json, agent.json, server-card.json, compat.json,
changelog.json, install.sh, install.ps1, and every
srift.app/dl/<version>/ URL.
Use SKIP_VERSION_BUMP=1 whenever npm is already published at the current
version — otherwise server.json advertises a version that isn't on npm.
Release 1 — npm
prepublishOnly rebuilds dist/ and runs a drift guard that fails if
cli/index.ts's CLI_VERSION disagrees with packages/cli/package.json.
Verify:
Naming
npm i -g srift-transfer installs a binary called srift. Do not "fix" MCP
configs to say srift-transfer — that breaks them.
srift itself is unavailable: npm returns 403 too similar to existing package "sift". srift-cli is blocked for the same reason (sift-cli exists). Scoped
names (@scope/name) bypass the similarity filter if a rename is ever needed.
npm failures we have actually hit
Release 2 — MCP registry
Namespace app.srift/srift, verified by a Cloudflare DNS TXT record on
srift.app. Listing:
https://registry.modelcontextprotocol.io/v0/servers?search=srift
key.pem is the registry identity and mcp-publisher.exe is a 20 MB binary —
both are gitignored. Losing key.pem means redoing DNS verification. The TXT
record on srift.app must stay in place:
Registry rules that cost us time
- Versions are immutable. Re-publishing an existing version returns
400 cannot publish duplicate version. Correcting anything in a listing —
repo URL, description, remotes — requires a new version.
- npm first, registry second.
server.json declares
packages[].identifier: srift-transfer at a specific version. Publishing the
registry entry first makes it advertise a version npm doesn't have, and anyone
installing from the listing gets a 404.
- Schema is
2025-12-11 and camelCase (registryType, websiteUrl,
runtimeArguments, environmentVariables, isRequired). An older revision
used snake_case; mixing them fails validation.
description is capped at 100 characters.
packages[].identifier must equal the npm package name — there is a test for
this, because a mismatch makes the listing install something nonexistent.
Release 3 — directories
CI
.github/workflows/ci.yml runs on every push and PR:
- verify — tsc → lint → build → test → version-drift check
- package — builds the CLI, fails if
npm publish --dry-run emits any
warning, then smoke-tests the packed binary over real MCP stdio and asserts
15 tools
That second job exists because npm silently stripped the bin entry once and
shipped a package with no command. Warnings are now build failures.
Deployment
Push to main → Cloud Build → Cloud Run (asia-south1), ~10 minutes.
Every COPY source in the Dockerfile must exist — a deleted proxy.ts left in
the COPY list broke every build. A test now walks them.
Production verification
On Windows pass absolute Windows paths (C:/...). Git Bash /tmp resolves
to C:\tmp and the CLI will not find the file.
Transport differences
Hosted omits srift_quick_share, srift_send_file, srift_accept_transfer
(need local disk) and srift_send_chat, srift_chat_history, srift_read_state
(would require deriving session keys server-side, defeating the point).
Source of truth: lib/mcp/backend-inprocess.mjs → SUPPORTED_TOOLS.
Claim policy
False or unprovable for SRIFT, and enforced by tests:
#1 · files never touch any server · untraceable · complete anonymity ·
trusted by millions · zero-knowledge as a product claim.
Say zero-retention and military-grade AES-256-GCM instead. "Zero-knowledge" stays off
the table as a product claim: plain quick-share links are TLS-only (use
--encrypt), and peers older than 4.2 fall back to a key derived from the
session ID, which the server knows. 4.2+ peers use device ECDH P-256 + HKDF keys.
📄 License
MIT License © SRIFT