TetherBay 0.2.563

Published 2026-08-22 · Updated 2026-08-22

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

Highlights

• Your transfer list now says what became of each file you sent.

  Delivered, declined, withdrawn, waiting and expired all used to read the same word — "sent" — which was nearly true when the only destination was your own device, and stopped being true the moment you could send to a person. A file someone refused looked exactly like one that arrived.

• Taking a file back no longer tells the other person it "expired".

  Withdrawing an offer was recorded as an expiry, so someone pressing Accept a moment too late was told they had been too slow, when in fact the sender had changed their mind. The two are now different events with different words.

• Transfers use the name you gave a contact.

  A row could show a raw account id for somebody your Contacts page names perfectly well, because it used the name that person set for themselves rather than the one you chose for them.

• Send-to-a-contact no longer disappears until you restart the app.

  If the relay ever answered "not available" — an older relay, or the feature switched off at that moment — the app remembered that answer for the rest of the session, even after you pointed it at a relay that does offer it. The answer is now remembered per relay.

• An invitation emailed to an address can no longer get stuck retrying.

  When the folder behind it had lost its owner, the claim re-ran on every contacts poll for the invitation's whole lifetime and re-added both people to each other's contacts each time. Nothing is written now until the claim can actually succeed, and a claim that has to wait backs off instead of retrying every 30 seconds.

• Re-adding a contact can no longer quietly undo a block.

  Re-adding a contact can no longer quietly undo a block.

Fixes

• Your transfer list now says what became of each file you sent. Delivered, declined, withdrawn, waiting and expired all used to read the same word — "sent" — which was nearly true when the only destination was your own device, and stopped being true the moment you could send to a person. A file someone refused looked exactly like one that arrived.
• Taking a file back no longer tells the other person it "expired". Withdrawing an offer was recorded as an expiry, so someone pressing Accept a moment too late was told they had been too slow, when in fact the sender had changed their mind. The two are now different events with different words.
• Transfers use the name you gave a contact. A row could show a raw account id for somebody your Contacts page names perfectly well, because it used the name that person set for themselves rather than the one you chose for them.
• Send-to-a-contact no longer disappears until you restart the app. If the relay ever answered "not available" — an older relay, or the feature switched off at that moment — the app remembered that answer for the rest of the session, even after you pointed it at a relay that does offer it. The answer is now remembered per relay.
• An invitation emailed to an address can no longer get stuck retrying. When the folder behind it had lost its owner, the claim re-ran on every contacts poll for the invitation's whole lifetime and re-added both people to each other's contacts each time. Nothing is written now until the claim can actually succeed, and a claim that has to wait backs off instead of retrying every 30 seconds.
• Re-adding a contact can no longer quietly undo a block.
• 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 d13154c37f95e185d17bcb2e968a36eb48c3e5a84c6e102dee6f258065084537
• osx-arm64 — Download 644c2a782ecc6cb0ae9d4f23bb4e69b4e544e99587e607272e3fca9b114d67e1
• osx-x64 — Download f5edd546f95f0d29a1c4dfbd99b2f5379d310db047207bf82bfa6beb63c8c6eb
• linux-x64 — Download 579004d677eba3ea02e8eb4df5b41f43f6b19de7fc7c554d6c5ced7be7fea601
• linux-arm64 — Download 0968c5c1224a7757a147b5c8df35210f358c0e6e32503b5a0841084df79ba0ef
• android — Download b9a94fd196b330f583e55b66d379a37f17d34021b37f93346b5e9f3bbee61230
• ios — pending

Verification

• Download page
• Release page