Simple first. Local first.

How SEYFR Sends a File

Your file starts on your device and ends on the receiver's device. The QR code contains no file data—it only carries directions and a 32-byte fingerprint so the receiver can request and verify the right content.

One transfer core, native apps
The same Rust transfer rules power the supported Android, Apple, Windows, and Linux apps.
JFFI Developer Framework (Power of Rust, Charm of Native) macOS (SwiftUI) Android (Compose) Windows (WinUI 3) iOS (SwiftUI) Linux (GTK 4) JFFI & UniFFI Bridge Connects each native app to the shared Rust core Shared Rust Core (seyfr-core) Local storage, content addressing, transfer and file checks Connection Routing Relay helps connect, then steps back when direct works iroh Content-Addressed Blobs 32-byte BLAKE3 address; verified while streaming iroh-blobs
The JFFI Philosophy: Power of Rust, Charm of Native

Use the Right Tools for the Job

SEYFR keeps the complicated parts in one shared Rust core while each platform keeps a familiar native interface.

  • On-device Core: File preparation, local storage, integrity checks, and transfer rules run on the device.
  • Native Screens: Uses the interface technology of each supported platform rather than a shared website wrapper.
  • One Set of Rules: The shared core keeps transfer behavior consistent across supported platforms.
R
NATIVE UI ON DEVICE
Native by design

Familiar on Every Platform

SEYFR uses native interfaces on each supported platform, backed by a shared Rust transfer core:

  • Native Controls: Uses platform-native interface technology instead of presenting the transfer screen as a website wrapper.
  • Shared Core: The same Rust transfer rules are used across supported platforms while each app keeps its platform-specific interface.
  • Platform Fit: Each app follows the conventions of its operating system.
Security First

The Rust Core Vault

Our Rust core applies the same destination and file-handling checks across supported platforms:

  • Destination Path Validation: Uses path_jail to keep received paths inside the destination the user selected and reject traversal attempts.
  • Safer File Handling: Rust memory safety reduces important classes of memory errors; it does not make software immune to every defect.
  • Folder Collection: Walks non-empty folders, skips nested hidden directories and node_modules, and preserves relative file paths.
Firewall Firewall BEST PATH AVAILABLE
Adaptive Delivery

Peer-to-Peer, Direct When Possible

SEYFR does not use a JITPOMI cloud drive. Iroh finds the best available path between the sender and receiver.

  • No File in the QR Code: The ticket carries the sender's connection information, one 32-byte BLAKE3 root hash, and the HashSeq format—not the file or its metadata.
  • Content Address: The root hash identifies a separate sequence of hashes. Those hashes identify SEYFR metadata and the selected file blobs in local storage.
  • Direct When Possible: Iroh attempts NAT traversal and can connect over the local network through mDNS.
  • Direct Path, with Encrypted Fallback: A relay first helps the devices connect. When a direct path works, the relay steps back and the transfer runs directly between them. If no direct path can be established, the stateless relay forwards the end-to-end encrypted transfer without reading or storing the file.
  • Usually Direct: Iroh reports that roughly 9 out of 10 network configurations allow a direct connection. This is not a guarantee for every SEYFR transfer. If a direct path works between two devices, it should keep working while their network setup stays stable. Read Iroh's NAT traversal documentation.
  • Verified Streaming: BLAKE3's tree lets iroh-blobs check streamed data incrementally. With Iroh's documented default, the tree uses 1 KiB chunks.