TetherBay 0.2.562

Published 2026-08-20 · Updated 2026-08-20

TetherBay 0.2.562 packages the latest documented beta improvements across relay resilience, network fallback, storage, and encrypted sync.

Highlights

• You can now send a file to a contact, not just to your own devices.

  Pick a file, pick a person, send. Their app shows it as an offer waiting for a decision, and nothing lands on their disk until they accept — one of their devices then downloads it into its Received folder. You can withdraw an offer until it is claimed, and you always see what happened: waiting, accepted, declined, or expired. Files sent this way are encrypted in transit and at rest but are not end-to-end encrypted — the Send screen and the encryption page both say so; put it in a synced folder i

• The encryption page now lists one-off Sends.

  Its "what is and isn't end-to-end" table covered synced folders, clipboard and browser links but silently omitted device-to-device Send, which has never been end-to-end.

• Accepting a shared folder no longer starts with a trip through your file system.

  Pressing Accept opened a folder picker immediately, so a folder someone shared with you could not arrive until you went and found — or created — a location on your own disk. It now proposes your incoming folder (TetherBay Incoming/<folder name>), shows you the exact path before anything is downloaded, and keeps the picker behind "Change location…" for the times you want it somewhere else. "Not now" leaves the invitation waiting in Contacts, and backing out of the picker returns to the choice ins

Fixes

• You can now send a file to a contact, not just to your own devices. Pick a file, pick a person, send. Their app shows it as an offer waiting for a decision, and nothing lands on their disk until they accept — one of their devices then downloads it into its Received folder. You can withdraw an offer until it is claimed, and you always see what happened: waiting, accepted, declined, or expired. Files sent this way are encrypted in transit and at rest but are not end-to-end encrypted — the Send screen and the encryption page both say so; put it in a synced folder if you need end-to-end. Neither side ever learns anything about the other's devices. The relay operator enables this per deployment.
• The encryption page now lists one-off Sends. Its "what is and isn't end-to-end" table covered synced folders, clipboard and browser links but silently omitted device-to-device Send, which has never been end-to-end.
• Accepting a shared folder no longer starts with a trip through your file system. Pressing Accept opened a folder picker immediately, so a folder someone shared with you could not arrive until you went and found — or created — a location on your own disk. It now proposes your incoming folder (TetherBay Incoming/<folder name>), shows you the exact path before anything is downloaded, and keeps the picker behind "Change location…" for the times you want it somewhere else. "Not now" leaves the invitation waiting in Contacts, and backing out of the picker returns to the choice instead of deciding for you.
• A folder shared without a link can now actually be read. An encrypted folder's key only ever travelled inside an invite link, so anyone brought in another way — shared with as a contact, or claiming an invitation sent to their email — became a full member of a folder they could not decrypt: every file failed its integrity check, silently, with nothing shown to either side. The owner's app is now told when a member is waiting for the key and seals a copy for them, which the member's app collects on its own. Only the owner can do this, only for people who have already accepted, and the relay still cannot read any of it.
• A folder invitation sent to someone's email now finds them after they install the app. Sharing with a person who has no TetherBay account yet mails them a link, and until now that link was the only way in: someone who installed TetherBay and signed in with the very address the invitation was sent to saw no invitation anywhere, because none existed for their account to report. Signing in with an invited address now claims the invitation and shows it with Accept/Decline, and an invitation that arrives later reaches an already-signed-in recipient on the next refresh. It still grants nothing until they accept. Device-link invitations are deliberately excluded, and only an address the account has verified counts.
• The invitation email and the join page now say what to do after installing. Both previously assumed the reader already had the app — "open the invite", or "paste this link" — advice that does not survive an install, since the installer does not carry the link the recipient arrived from. Both now name the address to sign in with.
• Windows Setup no longer aborts an install over legacy-updater cleanup. Setup still stops and removes the obsolete auto-updater, but a cleanup step it cannot verify through WMI or Task Scheduler is now logged and the installation continues, instead of ending in a restart-and-retry message a clean machine could not act on.
• Beta upgrades now reach the permanent Paddle Sandbox checkout. The production relay and desktop client accept the official tetherbay.com pricing handoff when the server explicitly reports Sandbox mode, while temporary tunnel URLs remain restricted to loopback QA relays. Beta testers keep real email-backed accounts and durable entitlements; only the Paddle transaction uses test money.
• Fresh Windows installs no longer fail a legacy-updater check. Setup now treats an absent legacy scheduled task as the normal state without depending on a version-specific Task Scheduler error identifier. A detected enabled legacy task or a still-running updater continues to block installation.
• Windows upgrades no longer fail on harmless legacy cleanup leftovers. Setup checks only the named legacy scheduled task instead of enumerating every task on the machine, accepts a task that is already disabled, and treats a locked obsolete LocalAppData application tree as recoverable after proving that no legacy updater is running. An active updater or enabled legacy task still blocks the upgrade.
• RecruitLead release artifacts remain readable after atomic activation. The mirror publisher now normalizes every staged download to mode 0644 before moving it into Caddy's document root, so a restrictive SSH umask cannot turn a hash-verified release into public HTTP 403 responses.
• Windows setup now retries transient legacy-tree file locks. After stopping the obsolete updater, both Setup and the one-line installer retry removal of its LocalAppData application tree for up to 15 seconds. A short-lived archive or process handle can no longer turn a successful updater shutdown into an immediate restart-required installation failure.
• RecruitLead download instructions no longer depend on the primary domain. Pages reached through the CIS mirror now show mirror-hosted one-line installer URLs, and /get.ps1 plus /get.sh default their release-feed requests to that same mirror ingress and use the mirror artifact URL returned by the feed. Mirror deployment and release verification reject either script if it contains a primary-domain dependency.
• Windows upgrades now retire even an already-running legacy beta updater. Setup disables and removes the old scheduled task, terminates its active PowerShell/VBS process tree, verifies the scheduled task is absent or disabled, and makes a best-effort removal of the obsolete LocalAppData application copy. This closes the race that could restore and launch an old beta one second after a successful Program Files installation while preserving settings and synced folders.
• Windows one-line upgrades now complete cleanly over running beta clients. The PowerShell flow downloads a recognisably named installer, closes existing launcher and agent processes, waits for setup to finish, verifies the installed binary version, and explicitly opens the matching launcher from Program Files. The release packager also rejects stale launcher or agent payloads whose FileVersion does not match the installer version, so a current filename cannot conceal old application bytes.
• Sync server no longer slows down as the total number of synced files grows. The relay's metadata store became database-authoritative: per-write work is now proportional to what actually changed (indexed point/range queries) instead of the whole dataset, and the server no longer loads all records into memory at startup — so boot time and memory stay flat as the service grows.
• One busy account can no longer degrade everyone else. Write contention is now keyed per folder/account behind a new lock manager (opt-in sharded mode), with a fair-share soft throttle that *slows* an over-active tenant rather than blocking it, and per-tenant lock metrics on /metrics. Closes the single-account denial-of-service path that could previously wedge the whole relay.
• PostgreSQL is now a supported metadata backend for the relay (selectable by configuration), alongside the existing SQLite store which remains the default for local and self-hosted use. Includes a one-shot SQLite→Postgres data migration tool with row-count reconciliation.
• Cloudflare R2 (S3-compatible) blob storage is production-ready. The relay can store encrypted blobs in R2 with presigned zero-egress downloads, a live storage health/deep-probe check, and a global storage-cap safety valve; switching is a configuration change. Verified end-to-end against a real S3 server.
• Server startup no longer waits on the boot-time storage maintenance pass. The audit that repairs/cleans staged and orphaned blobs now runs after the server is listening instead of before it binds, so health checks come up immediately even on an object-store backend where that pass can take minutes. Controlled by TETHERBAY_STARTUP_AUDIT_MODE (background default, off to skip at boot, blocking for the legacy pre-bind behavior).
• End-to-end encryption for synced folders and clipboard. File contents are encrypted on the sending device with AES-256-GCM (framed streaming AEAD) before upload; folder keys are shared device-to-device via sealed ECDH envelopes and never reach the relay. Clipboard items are sealed per-event with the account key. The relay stores ciphertext only and has no decryption path. Rollout is fail-closed — uploads are held rather than sent in the clear if any device in a folder cannot yet support E2E, so every device in a folder must be updated before content flows again. Clipboard E2E defaults ON since 2026-06-15.
• Remote file access hardened alongside folder encryption.

Known issues

• macOS beta packages are unsigned and not notarized; follow the documented Gatekeeper first-launch steps.

Availability

• win-x64 — Download 2ffd69e7f6c5b89f3385d6320ea68749127a52bebb93fcbb74d888c50ad5580e
• osx-arm64 — Download 71aa14b98e8fb064824cc56796d734085396f89b3fdd78228d88b60194bad6a5
• osx-x64 — Download 86bb6f8b4be35726349709c69ce50e97c7690fbfa2ab9bc9b0b48989fb5a2e76
• linux-x64 — Download 4e448a6713cbbc81e5fcb4a1e257bcbb8c2751243e2b7cace1e12f315570c07d
• linux-arm64 — Download ca021717dcca622fb47d6087d7118d48d60b84c1a82e85bc90db7942c9424aaa
• android — Download c5a0a8c80247a16e28128087566fbfdd7cfbd78b9b657970fa50ee66d3c8e093
• ios — pending

Verification

• Download page
• Release page