Commit Graph
3 Commits
Author SHA1 Message Date
Zoltán Papp ab47d2a4bf [client] Apply the file drop mode and destination as one change
FileDropSetSettings committed the mode first, through a Set that persists it
and fires the handler binding the receiver, and only then validated the
destination. A destination the caller may not use returned an error the UI
read as "nothing changed", while the profile had already moved to
auto-accept with the receiver listening, so the next offer from any peer was
taken without a prompt and delivered to the old directory.

Both halves are now settled before either is applied, and applied in the one
Set that already carries them: it validates the mode before touching
anything, so a refusal on either half leaves the policy alone.
2026-09-08 21:18:55 +02:00
Zoltan Papp 50197c7355 [client] Fix file drop delivery and refine the files UI
Seed the delivery directory from the IPC caller when the active profile
carries no username, so the default profile gets a destination instead of
failing every incoming transfer. Deliver text-only offers without requiring
a destination directory at all.

In the UI, drop the status label from the send picker rows, keep the dot,
and give the transfer list per-kind icons: a quote for text, a file with an
up or down arrow for files.
2026-09-05 19:12:43 +02:00
Zoltán Papp 73cffdb702 Add peer-to-peer file drop
Files move directly between peers over the overlay, with no server in the
path. The receiver listens on the WireGuard address only, so the port is
unreachable from outside the tunnel, and every offer is matched to a known
peer before anything is read.

Consent is the default: an offer carries metadata alone, and no payload
moves until the receiver accepts. Policy is per profile and device-local —
off, ask, or auto-accept, with per-sender exceptions on top.

Policy and history live in the profile's preferences, so removing a profile
takes its file drop state with it. Transfers interrupted by a restart are
settled on load; nothing survives to finish them, and left alone they would
sit in the log as permanently pending.

The Android bindings pull payload bytes through a chunk-returning stream:
gomobile copies a []byte argument into a fresh Java array and never copies
it back, so a fill-my-buffer method would hand back the right length with
no data.
2026-08-16 22:04:38 +02:00