Arkadiusz Fal ccf5c51460 Keep an automatic repair from ever reaching the server
A repair carries the timestamp of the selection it replaced, which is what
stops it outranking a deliberate choice made elsewhere — but it also makes
every ordering comparison read it as that choice. A fetch holding the
selected account's tombstone and an older server context applied them in
that order: the tombstone repaired the selection, and the older context
then lost to it, so the "the server holds the stale copy" path marked the
repair dirty and uploaded an automatic fallback under the deleted choice's
timestamp, over an explicit choice. The stored context now remembers
whether it is a repair, and a repair that wins an ordering pushes nothing
back: the server's context stands remotely, the fallback stays local, and
the next explicit choice on any device re-converges everyone. The bit is
persisted with the context, or a relaunch would forget and publish it on
the first stale record it read.

Three more from the same trace:

- The repair prefers a signed-in login on the same server, decided off
  statuses, and it commits — once the selection no longer names the deleted
  account there is nothing left for a later status to move. Foreground
  activation refreshes statuses ahead of it, but a deletion delivered by a
  silent push arrives outside that sequence, and a credential that reached
  this device over iCloud Keychain while it was in the background announces
  nothing. The refresh is now asked for by the repair itself, which closes
  every entry point rather than each fetch trigger having to remember one.

- A device that meets a tombstone before the account it kills cannot record
  which instance that account lived on, and the account record arriving
  afterwards was discarded — with the only copy of that fact still in it.
  Every later repair of a context naming it then fell to local past a
  usable sibling. The association is kept as the record is dropped.

- Removing an orphaned account deleted its credential before recording the
  deletion, so a crash in between brought the account back on the next
  launch as one nobody can sign into, owing no deletion to any device. The
  outbox goes first, here and in the sign-out and instance cascades; the
  scoped credential key needs only the account's ID, and the store is
  resolved through the instance before anything is removed.
2026-09-05 23:06:10 +02:00
2026-04-18 20:37:24 +02:00
2026-08-23 11:04:21 +00:00
2026-04-18 20:37:24 +02:00
2026-04-18 20:37:24 +02:00
2026-04-18 20:37:24 +02:00
2026-04-18 20:37:24 +02:00
2026-04-18 20:37:24 +02:00
2026-04-18 20:37:24 +02:00
2026-04-18 20:37:24 +02:00
2026-04-18 20:37:24 +02:00
2026-08-23 12:46:11 +02:00
2026-04-23 15:45:49 +02:00
2026-04-18 20:37:24 +02:00
2026-04-18 20:38:00 +02:00
2021-11-10 00:25:38 +01:00
2026-07-18 17:38:43 +02:00

Yattee logo

Yattee

Privacy oriented video player for iOS, tvOS and macOS

AGPL v3 GitHub issues GitHub pull requests

Discord

Yattee 2 is in the works! A new version of the app is being built with a refreshed experience. It pairs with the new Yattee Server — a self-hosted backend powered by yt-dlp that supports 1000+ sites. Join the TestFlight beta to try early builds, and check the new documentation site at docs.yattee.stream for guides, roadmap and changelog.

Features

  • Native user interface built with SwiftUI with customization settings
  • Player queue and history
  • Player component with custom controls, gestures and support for 4K playback
  • Fullscreen, Picture in Picture and background audio playback
  • SponsorBlock, configurable categories to skip

License

Yattee and its components is shared on AGPL v3 license.

Description
Privacy oriented video player for iOS, tvOS and macOS
Readme AGPL-3.0 344 MiB
Languages
Swift 96.9%
Ruby 2.7%
C 0.3%