Arkadiusz Fal 5abd314c88 Let an incoming context settle what a repair cannot argue with
A repair is a fallback, not a choice: it borrows the timestamp of the
selection it replaced so that a later choice still beats it, and it is
never published. But that borrowed rank also won arguments it had no
business winning. An incoming explicit context stamped at the same instant
that loses the `DataContext.tieBreakKey` tie was neither adopted — the
repair was not outranked — nor pushed back, because a repair pushes
nothing. Neither side moved, and the fallback stood against the server's
explicit value indefinitely. The tie is not theoretical: migrated contexts
are all stamped at the epoch, and a repair keeps the timestamp of whatever
it replaced, so two migrated-era values meet as equals.

A stored repair now never outranks an incoming context — it is replaced by
whatever arrived, older or tied, and nothing is ever enqueued for that.
Adopting is safe whatever the incoming value names: one naming an account a
tombstone dominates has already been turned back into a repair before the
comparison, so it stays unpublished and lands on the same target this
device's repair did.

Two more from the same trace:

- Staged records are applied by category, and contexts already come last so
  that a repair reads the accounts and the instance a dominated record left
  behind rather than falling to local past a signed-in sibling. That
  ordering was load-bearing and unremarked; it is now written down, along
  with what it does not cover — a context applied in an earlier batch than
  the account record that says where the deleted account lived still
  repairs without it, which the next explicit choice anywhere settles.

- An install that repaired its context before the repair bit existed reads
  back as having chosen it, so that one repair can still be published once.
  Accepted and documented at the load site: no shipped release ever
  persisted a data context, the window is interim builds only, and the next
  explicit choice heals it.
2026-09-05 23:30:40 +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%