Private device networks & file transferPublic field guide
Superlink: selected-device networks and verified file transfer
Superlink connects chosen devices through explicit membership and capabilities. The current replacement is a native Yeho/YUI Windows application with small independent windows, device-code pairing, durable text receipts, and verified binary-file transfer. Broader media, phone, and network scenarios are still being built and qualified.
Start with a practical evaluationThe useful starting point
What Superlink gives your team
A team can inspect when a device is trusted, when a message becomes durable, and when a received file is actually verified rather than merely appearing to finish.
Collaboration-tool developers, internal-platform teams, and researchers studying explicit device trust and recoverable delivery.
- 01
Pair chosen devices
Exchange device codes through an already trusted path.
- 02
Send bounded work
Transfer text or a file under the selected network's permission.
- 03
Verify delivery
Persist receipts and check file content before reporting completion.
Connection is only the beginning of trust
The current pairing flow pins a device certificate fingerprint and checks the session before committing trust. The exchange still needs an already trusted way to identify the other device. A code by itself does not establish who sent it.
Each network selects its members and permissions. Revocation and recovery therefore matter as much as initial connection. The native checkpoint is separate from the older C++/WebView2 reference, whose broader feature inventory should not be treated as the new application's completed scope.
A progress bar is not a delivery receipt
The recipient chooses the destination for an incoming file. Its remote name is display information, not authority to write an arbitrary path. The transfer records progress, verifies content, and preserves existing destination files. A restart follows the durable journal rather than guessing from a partial file's apparent size.
A retained 32 MiB transfer compares every byte between two native local processes. That is useful workload evidence, not qualification for arbitrary file sizes, WAN conditions, phones, or many physical devices. The exact current limits are part of an honest source evaluation.
Current public evidence
Native text and file checkpoint
The Windows native checkpoint proves device-code pairing over pinned encrypted sessions, durable text receipts, binary-file verification, destination-collision protection, and two-process restart recovery. A retained 32 MiB transfer checks every byte with both local processes below 8.2 MB peak private memory. The older C++/WebView2 stack remains a separate reference. Full physical-device, WAN, media, inference, and phone gates remain open; local message history is not encrypted at rest.
Explore the project and its evidenceTry one bounded question
Interrupt a transfer and verify what arrives
A suggested evaluation for your team.
- Use two independent test profiles and the documented trusted pairing ceremony.
- Send a short message and check the durable receipt rather than only the send action.
- Offer a known binary fixture and choose an unused recipient destination.
- Interrupt the documented transfer fixture, restart both sides, and reconnect explicitly.
- Compare every received byte and test a destination collision and membership revocation.
A verified file and durable message behavior across the tested restart, with errors that preserve existing data. Record the exact workload and distinguish local processes from physical-network qualification.
Before you go further
Common questions about Superlink
Does the current native version already support every phone and media feature?
No. Native Windows text and file checkpoints are bounded evidence. Full physical-device, WAN, media, inference, and phone gates have not passed.
Does an encrypted connection mean local history is encrypted?
No. The current Windows device key is sealed for the user, but the documented message and workspace history files are ordinary local files. Connection security and storage protection are different properties.
Does a received filename choose the save location?
No. The recipient selects a writable destination. The current file contract treats the remote name as display metadata and preserves existing files on collision.
From an idea to your first evaluation
Build on what you understand.
Start with Superlink's public evidence. If it fits your team's problem, compare source memberships or tell us what you would like to evaluate.
These guides are free to read. Private source releases follow the membership license. Compare plans and team seats.