LAN Share

LAN Share transfers files and complete folders directly between Okytes devices on the same network. It does not upload content to Okytes, a cloud drive, or a relay service.

Using LAN Share

Both computers run the Okytes daemon with a peer listener. Nearby devices appear through DNS-SD when discovery is enabled. A manual IP address and port can be used on networks that block multicast.

Pairing and transfer approval are separate decisions. Pairing pins the other installation's complete certificate fingerprint. Every connection must then complete mutual TLS 1.3 authentication against that exact certificate. An incoming file offer still waits for the receiver to inspect it, choose a destination, and accept or reject it.

To send content from the desktop application:

1. Open LAN Share and pair the other device by comparing its complete fingerprint.
2. Select one or more nearby paired devices, or enter a paired device ID and address.
3. Choose files or a folder.
4. Review the selection and receivers, then confirm the transfer.
5. The receiving user chooses a destination and accepts the request.

The transfer list reports durable bytes, completed files, current speed, estimated remaining time, state, and failure details. Active transfers can be paused or cancelled. Paused, interrupted, or failed transfers can be retried from their durable checkpoints. Completed inbound transfers can open their destination folder.

The local browser interface can inspect and control existing LAN Share requests. Browser sessions cannot pair devices, change trust, or select arbitrary sender filesystem paths. Those operations remain on the native desktop and CLI surfaces.

How transfers work

The sender recursively enumerates the selected regular files and directories and builds a sorted, bounded manifest. Absolute source paths never cross the network. Symbolic links, reparse-like unsupported objects, unsafe relative paths, Unicode/case collisions, and oversized manifests are rejected.

The peer protocol uses a dedicated TLS 1.3 connection with the okytes-peer/1 ALPN identifier. JSON control frames are length-delimited and bounded. File payloads use bounded binary chunks. The receiver acknowledges a chunk only after writing it, synchronizing it to disk, and committing the new offset through the existing serialized SQLite profile writer.

Received data stays under a request-specific staging directory. Okytes verifies each file's declared size and SHA-256 digest before publishing the completed directory atomically. Partial content is never exposed under the final transfer name. A resumed sender rebuilds the source manifest and refuses to continue if the source changed after the offer was created.

Outbound source authority, receiver destinations, lifecycle revisions, durable offsets, and sanitized failure messages survive daemon restart. Terminal transfers remove resumable outbound source records. Trust revocation is checked during operation, so a revoked device cannot continue receiving new application-level authority.

Resource and security boundaries

• Discovery records are untrusted address hints. Only the pinned certificate proves device identity.
• The daemon limits simultaneous accepted peer connections and sender tasks.
• Manifests, paths, control frames, chunk sizes, trust slots, request history, and API bodies have fixed limits.
• TLS validation cannot be disabled.
• Unknown devices cannot silently send files.
• A paired device does not receive general filesystem access.
• Desktop notifications contain bounded transfer metadata and never expose source paths.

Firewalls, guest Wi-Fi isolation, VLAN boundaries, and disabled multicast can prevent discovery or direct connections. Configure the peer listener in the host firewall and use the manual address field when DNS-SD is unavailable.

Main implementation files

• crates/core/src/peer.rs defines manifests, commitments, protocol frames, limits, and legal lifecycle transitions.
• crates/persistence/src/peer.rs stores trust, offers, durable offsets, recovery authority, destinations, and failures through the profile writer.
• apps/daemon/src/peer_identity.rs owns persistent device credentials and pinned mutual-TLS configuration.
• apps/daemon/src/discovery.rs advertises and discovers _okytes-peer._tcp services.
• apps/daemon/src/peer_transfer.rs enumerates sources and provides crash-safe receiver staging and publication.
• apps/daemon/src/peer_session.rs implements the authenticated control and payload session.
• apps/daemon/src/server.rs exposes the scoped daemon API and restarts recoverable outbound work.
• apps/desktop/src/PeerShare.tsx provides pairing, discovery, send, approval, progress, history, and lifecycle controls.

Protocol details and threat-boundary decisions are maintained with the M10 engineering records under the repository's private .agents/docs directory.