# Koch Laboratory — Czas jako uzgodniona jednostka i jako dowód (BeatTime) · Forschungsportfolio / Portfolio badawcze / Research Portfolio

> **Zasada publikacji.** Kontrakty formatów (preimage, format kotwicy) są jawne z założenia — dowód, którego nie da się odtworzyć bez pytania autora, nie jest dowodem. Wstrzymane pozostają wyłącznie materiały klucza podpisującego i szczegóły operacyjne infrastruktury.
> **Zasada uczciwości.** Rdzeń czasu, publiczny log stempli i kotwiczenie są wdrożone i działają publicznie; warstwy aplikacyjne (mobile, wear) są w budowie i tak oznaczone. Granice każdego dowodu podane są wprost — łącznie z tym, czego nie dowodzi.

---
---

# 🇵🇱 WERSJA POLSKA

## Koch Laboratory — czas jako uzgodniona jednostka i jako dowód

Ten kierunek zaczął się od pytania praktycznego: dlaczego uzgodnienie jednej chwili między dwiema osobami w różnych strefach czasowych wymaga tłumaczenia, a nie odczytania. Skończył się na pytaniu trudniejszym: czym musi być usługa czasu, żeby jej wskazanie miało wartość dowodową dla kogoś, kto nie ufa ani nam, ani naszemu serwerowi.

**Metodyka.** Jak w reszcie laboratorium: problem → hipoteza → falsyfikowalne kryterium → metoda → wynik z warunkami brzegowymi. Statusy są jawne: „wdrożone" znaczy działające pod publicznym adresem, „prace projektowe" znaczy brak wyniku pomiarowego.

### 1. Kierunek 1 — jednostka czasu, którą da się wypowiedzieć bez kontekstu
**Pytanie badawcze.** Czy da się podać chwilę tak, aby odbiorca nie musiał znać ani strefy nadawcy, ani własnej — bez utraty odwracalności względem UTC?
**Dlaczego to trudne.** Strefy czasowe nie są funkcją geografii, tylko decyzji politycznych: zmieniają się z roku na rok, obejmują przesunięcia półgodzinne i sezonowe, a baza reguł jest ruchoma. Każda notacja lokalna wymaga więc dodatkowego stanu, żeby ją zrozumieć — a stan bywa nieaktualny.
**Stan techniki (publikowany).** ISO 8601 i UTC (poprawne, ale wymagają przeliczenia po stronie odbiorcy); Swatch Internet Time z 1998 — jednostka bez stref, ale zakotwiczona w BMT (UTC+1, czas siedziby firmy) i bez otwartego interfejsu; TAI i czas uniksowy jako podstawy techniczne, nieprzeznaczone do wypowiadania.
**Kryterium sukcesu.** Konwersja UTC↔jednostka odwracalna, pokryta testami, bez jakiejkolwiek zależności od bazy stref; jednostka na tyle gruba, by wypowiedzieć ją w rozmowie (1/1000 doby = 86,4 s), i na tyle precyzyjna, by umówić się co do minuty.
**Wynik.** Potwierdzony w zakresie kryterium: kotwica w UTC/Greenwich zamiast BMT, otwarte API (`now`, `convert`, `sync`, `health`), rdzeń konwersji jako czysty, otestowany moduł. Warunek brzegowy: jednostka nie zastępuje ISO 8601 w rekordach maszynowych — jest warstwą wypowiadalną, nie formatem zapisu.
**Status:** wdrożone.

### 2. Kierunek 2 — zegar, który tyka bez pytania serwera
**Pytanie badawcze.** Czy publiczny zegar może działać bez ruchu sieciowego w trakcie działania — a więc bez telemetrii i bez kosztu skalowania — zachowując dokładność wystarczającą dla przyjętej jednostki?
**Dlaczego to trudne.** Zegar odpytujący serwer co tyknięcie jest jednocześnie licznikiem odwiedzin: każde tyknięcie zostawia adres IP w cudzym logu. Zegar liczony wyłącznie lokalnie dziedziczy natomiast błąd zegara urządzenia, którego nie kontrolujemy i o którym nic nie wiemy.
**Stan techniki (publikowany).** SNTP/NTP jako model jednorazowej synchronizacji offsetu; zegary webowe zwykle odpytujące serwer cyklicznie.
**Kryterium sukcesu.** Zero zapytań sieciowych po starcie; jawny pomiar i publikacja własnego błędu zamiast milczącego założenia poprawności.
**Wynik.** Potwierdzony: klient pobiera offset raz i tyka lokalnie (model SNTP), działa offline. Do tego zadanie okresowe mierzy odchyłkę zegara hosta względem NTP i wystawia ją w `/api/health` — **usługa czasu publikuje własny błąd**, zamiast go ukrywać. Warunek brzegowy: dokładność po stronie klienta pozostaje ograniczona zegarem urządzenia; dla jednostki 86,4 s jest to nieistotne, dla zastosowań dowodowych — nie, i dlatego dowód czasu (kierunek 3) nigdy nie opiera się na zegarze klienta.
**Status:** wdrożone.

### 3. Kierunek 3 — publiczny log stempli: istnienie bez ujawniania treści
**Pytanie badawcze.** Czy da się wykazać, że dany dokument istniał w danym tygodniu, bez ujawniania jego treści i bez zaufania do operatora usługi?
**Dlaczego to trudne.** Operator, który może dopisać wpis wstecz, jest bezużyteczny jako świadek — a sam podpis operatora tego nie wyklucza. Log musi więc być zamknięty w czasie i weryfikowalny przez kogoś, kto nie ma dostępu do bazy; jednocześnie żadna weryfikacja nie może wymagać okazania dokumentu.
**Stan techniki (publikowany).** RFC 3161 (TSA — wiarygodność sprowadzona do zaufania do urzędu), Certificate Transparency (drzewa Merkle z dowodami inkluzji), OpenTimestamps.
**Kryterium sukcesu.** Rejestrowany jest wyłącznie SHA-256; korzeń tygodnia zamrażany po jego zakończeniu i podpisywany Ed25519; dla dowolnego skrótu odtwarzalna ścieżka inkluzji, sprawdzalna bez dostępu do systemu.
**Wynik.** Potwierdzony: tygodniowe drzewo Merkle, zamrożenie korzenia po zamknięciu tygodnia, podpis Ed25519, ścieżka inkluzji per digest, deduplikacja jako „pierwsze widzenie". Warunek brzegowy: ziarnistość dowodu to tydzień — usługa dowodzi „nie później niż", nie „dokładnie o".
**Status:** wdrożone.

### 4. Kierunek 4 — kotwica w rejestrze, którego operator nie kontroluje
**Pytanie badawcze.** Czym zakotwiczyć korzeń tygodnia, żeby dowód przetrwał utratę zaufania do usługi — i żeby nie zależał od jednego, wybranego przez nas świata technicznego?
**Dlaczego to trudne.** Kotwica musi trafić do rejestru datowanego przez stronę trzecią, odpornego na wsteczną zmianę, taniego i powtarzalnego co tydzień przez lata. Blockchain spełnia trzy pierwsze warunki, ale wprowadza zależność od jednego ekosystemu i od jego kosztu; publikacja w prasie (klasyczne rozwiązanie Surety z lat 90.) jest droga i trudna do automatyzacji.
**Stan techniki (publikowany).** OpenTimestamps z zakotwiczeniem w Bitcoinie; historyczne publikowanie skrótów w ogłoszeniach prasowych; komercyjne urzędy znacznika czasu.
**Kryterium sukcesu.** Co najmniej dwa niezależne kanały kotwiczenia, z których żaden nie jest kontrolowany przez operatora usługi, a każdy weryfikowalny osobno.
**Wynik.** Potwierdzony: kanał pierwszy to OpenTimestamps. Kanałem drugim jest **tytuł przelewu bankowego** — korzeń tygodnia zapisany jako `MROOT <ROKWnn> <8 grup po 8 znaków hex>` (85 znaków, mieści się w polu tytułu o limicie 140), zaksięgowany przez instytucję regulowaną, która prowadzi własną, niezależną od nas ewidencję czasu i nie ma powodu jej dla nas zmieniać. Warunek brzegowy: kanał bankowy ma ziarnistość księgowania (dni robocze) i wymaga ręcznego potwierdzenia referencji; jest tani i całkowicie niezależny od kryptowalut, ale nie jest natychmiastowy.
**Status:** wdrożone.

### 5. Kierunek 5 — losowanie, którego nie kontroluje nikt, łącznie z nami
**Pytanie badawcze.** Czy da się wyprowadzić publiczną wartość losową z materiału, którego operator nie może dobrać pod z góry ustalony wynik?
**Dlaczego to trudne.** Każde losowanie po stronie serwera jest niesprawdzalne, a każde „losowanie z ziarna" jest sterowalne, jeśli ziarno wybiera ten, kto ogłasza wynik. Rozwiązania oparte na commit–reveal wymagają dyscypliny i kolejnej rundy zaufania.
**Stan techniki (publikowany).** Publiczne beacony losowości (m.in. drand, beacon NIST), schematy commit–reveal, wyprowadzanie losowości z nagłówków bloków.
**Kryterium sukcesu.** Wynik odtwarzalny przez każdego z materiału już opublikowanego i już podpisanego, bez żadnego stanu po stronie serwera.
**Wynik.** Częściowy — i to jest wynik wart opublikowania. Wartość dnia liczona jest jako funkcja korzenia **ostatniego zamkniętego tygodnia** i daty (`beattime-thebeat-v1|<korzeń>|<data>`, SHA-256, pierwsze 6 bajtów mod 1000). Uzyskana własność to **niesterowalność i pełna weryfikowalność**: operator nie może dobrać wyniku, bo korzeń był zamrożony i podpisany, zanim padła data. Uzyskaną własnością **nie jest nieprzewidywalność** — korzeń jest publiczny, więc każdy może policzyć wartości na cały nadchodzący tydzień z wyprzedzeniem. Deklarujemy to wprost, ponieważ mylenie tych dwóch własności jest najczęstszym błędem w tej klasie rozwiązań.
**Status:** wdrożone, z jawnie ograniczoną własnością.

### 6. Kierunek 6 — dowód współstemplowania chwili bez tożsamości stron
**Pytanie badawcze.** Czy dwie osoby mogą wspólnie utrwalić jedną chwilę tak, aby dowód był weryfikowalny publicznie, a usługa nie dowiedziała się, kim są?
**Dlaczego to trudne.** Naturalne rozwiązania (konta, numery telefonów, listy kontaktów) rozwiązują problem tożsamości przez jego przeniesienie na operatora — i tworzą dokładnie ten rejestr, którego chcemy uniknąć. Bez tożsamości znika jednak wiązalność: nie da się odróżnić „ta sama osoba piąty raz" od pięciu obcych.
**Stan techniki (publikowany).** Protokoły dowodu bliskości (BLE, dźwięk), podpisy Ed25519, C2PA jako standard poświadczania pochodzenia.
**Kryterium sukcesu.** Usługa przechowuje wyłącznie dwie losowe sole i wynikowy skrót; żadna ze stron nie mogła wytworzyć skrótu samodzielnie przed spotkaniem; ciągłość klucza zastępuje imię.
**Wynik.** Potwierdzony: skrót powstaje z obu soli i czasu nadanego przez serwer, wersja v2 wiąże go dodatkowo z surowymi kluczami publicznymi obu stron, a posiadanie kluczy jest dowodzone podpisem. Opisy „z kim" nie istnieją poza telefonami. **Granica dowodu, podana wprost:** dowód wykazuje, że dwie strony współstemplowały tę samą chwilę — nie wykazuje fizycznej bliskości; ten sam protokół można wykonać zdalnie i tak też należy go czytać.
**Status:** wdrożone (v1 i v2).

**Status kierunku.** Rdzeń czasu, publiczny log, kotwiczenie i protokół współstemplowania działają publicznie; warstwy aplikacyjne (Android, wear, rozszerzenie, SDK) są w budowie. Najbliższy krok badawczy: poświadczanie pochodzenia treści (C2PA) jako warstwa nad istniejącym logiem — dokładana jako warstwa, nigdy jako fundament.

---
---

# 🇩🇪 DEUTSCHE FASSUNG

## Koch Laboratory — Zeit als vereinbarte Einheit und als Beweis

Diese Richtung begann mit einer praktischen Frage: Warum verlangt die Verständigung über einen einzigen Zeitpunkt zwischen zwei Personen in verschiedenen Zeitzonen eine Übersetzung statt einer Ablesung? Sie endete bei einer schwierigeren Frage: Was muss ein Zeitdienst sein, damit seine Angabe Beweiswert für jemanden hat, der weder uns noch unserem Server vertraut?

**Methodik.** Wie im übrigen Labor: Problem → Hypothese → falsifizierbares Kriterium → Methode → Ergebnis mit Randbedingungen. Der Status ist offen ausgewiesen: „umgesetzt" heißt unter einer öffentlichen Adresse in Betrieb, „Projektarbeit" heißt ohne Messergebnis.

### 1. Richtung 1 — eine Zeiteinheit, die ohne Kontext aussprechbar ist
**Forschungsfrage.** Lässt sich ein Zeitpunkt so angeben, dass der Empfänger weder die Zone des Absenders noch die eigene kennen muss — ohne die Umkehrbarkeit gegenüber UTC zu verlieren?
**Warum schwierig.** Zeitzonen sind keine Funktion der Geografie, sondern politischer Entscheidungen: Sie ändern sich von Jahr zu Jahr, enthalten halbstündige und saisonale Versätze, und die Regelbasis ist beweglich. Jede lokale Notation braucht daher zusätzlichen Zustand, um verstanden zu werden — und dieser Zustand ist mitunter veraltet.
**Stand der Technik (veröffentlicht).** ISO 8601 und UTC (korrekt, aber Umrechnung beim Empfänger); Swatch Internet Time von 1998 — zonenfreie Einheit, jedoch in BMT verankert (UTC+1, Firmensitz) und ohne offene Schnittstelle; TAI und Unixzeit als technische Grundlagen, nicht zum Aussprechen gedacht.
**Erfolgskriterium.** Umkehrbare, testgedeckte Konvertierung UTC↔Einheit ohne jede Abhängigkeit von einer Zonendatenbank; die Einheit grob genug, um im Gespräch ausgesprochen zu werden (1/1000 Tag = 86,4 s), und fein genug für eine Verabredung auf die Minute.
**Ergebnis.** Im Rahmen des Kriteriums bestätigt: Verankerung in UTC/Greenwich statt BMT, offene API (`now`, `convert`, `sync`, `health`), Konvertierungskern als reines, getestetes Modul. Randbedingung: Die Einheit ersetzt ISO 8601 in maschinellen Datensätzen nicht — sie ist eine aussprechbare Schicht, kein Speicherformat.
**Status:** umgesetzt.

### 2. Richtung 2 — eine Uhr, die ohne Serveranfrage tickt
**Forschungsfrage.** Kann eine öffentliche Uhr im Betrieb ohne Netzverkehr auskommen — also ohne Telemetrie und ohne Skalierungskosten — und dabei für die gewählte Einheit hinreichend genau bleiben?
**Warum schwierig.** Eine Uhr, die pro Tick den Server fragt, ist zugleich ein Besucherzähler: Jeder Tick hinterlässt eine IP-Adresse in einem fremden Log. Eine rein lokal gerechnete Uhr erbt dagegen den Fehler der Geräteuhr, die wir weder kontrollieren noch kennen.
**Stand der Technik (veröffentlicht).** SNTP/NTP als Modell einmaliger Offset-Synchronisierung; Web-Uhren, die typischerweise zyklisch den Server abfragen.
**Erfolgskriterium.** Null Netzanfragen nach dem Start; ausgewiesene Messung und Veröffentlichung des eigenen Fehlers statt stiller Korrektheitsannahme.
**Ergebnis.** Bestätigt: Der Client holt den Offset einmal und tickt lokal (SNTP-Modell), auch offline. Zusätzlich misst eine periodische Aufgabe die Abweichung der Hostuhr gegenüber NTP und weist sie in `/api/health` aus — **ein Zeitdienst, der seinen eigenen Fehler veröffentlicht**, statt ihn zu verschweigen. Randbedingung: Die clientseitige Genauigkeit bleibt durch die Geräteuhr begrenzt; für eine Einheit von 86,4 s ist das unerheblich, für Beweiszwecke nicht — deshalb stützt sich der Zeitbeweis (Richtung 3) nie auf die Uhr des Clients.
**Status:** umgesetzt.

### 3. Richtung 3 — ein öffentliches Stempel-Log: Existenz ohne Offenlegung des Inhalts
**Forschungsfrage.** Lässt sich nachweisen, dass ein Dokument in einer bestimmten Woche existierte — ohne seinen Inhalt offenzulegen und ohne dem Betreiber des Dienstes zu vertrauen?
**Warum schwierig.** Ein Betreiber, der rückwirkend eintragen kann, taugt nicht als Zeuge — und seine eigene Signatur schließt das nicht aus. Das Log muss also zeitlich geschlossen und von jemandem prüfbar sein, der keinen Datenbankzugriff hat; zugleich darf keine Prüfung die Vorlage des Dokuments verlangen.
**Stand der Technik (veröffentlicht).** RFC 3161 (TSA — Glaubwürdigkeit auf das Vertrauen in die Stelle reduziert), Certificate Transparency (Merkle-Bäume mit Inklusionsbeweisen), OpenTimestamps.
**Erfolgskriterium.** Erfasst wird ausschließlich SHA-256; die Wochenwurzel wird nach Ablauf der Woche eingefroren und mit Ed25519 signiert; für jeden Hash ist ein Inklusionspfad rekonstruierbar, prüfbar ohne Systemzugang.
**Ergebnis.** Bestätigt: wöchentlicher Merkle-Baum, eingefrorene Wurzel nach Wochenabschluss, Ed25519-Signatur, Inklusionspfad je Digest, Deduplikation als „erstmals gesehen". Randbedingung: Die Beweisgranularität ist die Woche — der Dienst belegt „nicht später als", nicht „genau um".
**Status:** umgesetzt.

### 4. Richtung 4 — Verankerung in einem Register, das der Betreiber nicht kontrolliert
**Forschungsfrage.** Womit verankert man die Wochenwurzel, damit der Beweis den Verlust des Vertrauens in den Dienst übersteht — und nicht von einer einzigen, von uns gewählten technischen Welt abhängt?
**Warum schwierig.** Der Anker muss in ein Register gelangen, das von Dritten datiert wird, gegen rückwirkende Änderung resistent, günstig und über Jahre wöchentlich wiederholbar ist. Eine Blockchain erfüllt die ersten drei Bedingungen, schafft aber eine Abhängigkeit von einem Ökosystem und dessen Kosten; die Veröffentlichung in der Presse (die klassische Surety-Lösung der 1990er) ist teuer und schwer zu automatisieren.
**Stand der Technik (veröffentlicht).** OpenTimestamps mit Verankerung in Bitcoin; historische Hash-Veröffentlichungen in Zeitungsanzeigen; kommerzielle Zeitstempeldienste.
**Erfolgskriterium.** Mindestens zwei unabhängige Ankerkanäle, von denen keiner vom Betreiber kontrolliert wird und jeder für sich prüfbar ist.
**Ergebnis.** Bestätigt: Der erste Kanal ist OpenTimestamps. Der zweite Kanal ist der **Verwendungszweck einer Banküberweisung** — die Wochenwurzel als `MROOT <JAHRWnn> <8 Gruppen zu 8 Hexzeichen>` (85 Zeichen, passt in das auf 140 Zeichen begrenzte Feld), gebucht von einem regulierten Institut, das eine eigene, von uns unabhängige Zeitführung betreibt und keinen Anlass hat, sie für uns zu ändern. Randbedingung: Der Bankkanal hat Buchungsgranularität (Werktage) und verlangt eine manuelle Bestätigung der Referenz; er ist günstig und vollständig unabhängig von Kryptowährungen, aber nicht sofortig.
**Status:** umgesetzt.

### 5. Richtung 5 — eine Auslosung, die niemand kontrolliert, wir eingeschlossen
**Forschungsfrage.** Lässt sich ein öffentlicher Zufallswert aus Material ableiten, das der Betreiber nicht auf ein vorab festgelegtes Ergebnis hin auswählen kann?
**Warum schwierig.** Jede serverseitige Auslosung ist unprüfbar, und jede „Auslosung aus einem Seed" ist steuerbar, wenn den Seed derjenige wählt, der das Ergebnis verkündet. Commit-Reveal-Verfahren verlangen Disziplin und eine weitere Vertrauensrunde.
**Stand der Technik (veröffentlicht).** Öffentliche Randomness Beacons (u. a. drand, NIST-Beacon), Commit-Reveal-Schemata, Ableitung von Zufall aus Blockheadern.
**Erfolgskriterium.** Das Ergebnis ist von jedermann aus bereits veröffentlichtem und bereits signiertem Material nachrechenbar, ohne jeden serverseitigen Zustand.
**Ergebnis.** Teilweise — und das ist ein veröffentlichenswertes Ergebnis. Der Tageswert ist eine Funktion der Wurzel der **letzten abgeschlossenen Woche** und des Datums (`beattime-thebeat-v1|<Wurzel>|<Datum>`, SHA-256, erste 6 Bytes mod 1000). Erreicht sind **Nichtsteuerbarkeit und vollständige Prüfbarkeit**: Der Betreiber kann das Ergebnis nicht wählen, weil die Wurzel eingefroren und signiert war, bevor das Datum feststand. **Nicht erreicht ist Unvorhersagbarkeit** — die Wurzel ist öffentlich, jeder kann die Werte der kommenden Woche im Voraus berechnen. Wir sagen das ausdrücklich, weil die Verwechslung dieser beiden Eigenschaften der häufigste Fehler dieser Lösungsklasse ist.
**Status:** umgesetzt, mit ausdrücklich begrenzter Eigenschaft.

### 6. Richtung 6 — Beweis der gemeinsamen Stempelung ohne Identität der Beteiligten
**Forschungsfrage.** Können zwei Personen einen Zeitpunkt gemeinsam festhalten, sodass der Beweis öffentlich prüfbar ist und der Dienst nicht erfährt, wer sie sind?
**Warum schwierig.** Die naheliegenden Lösungen (Konten, Rufnummern, Kontaktlisten) lösen das Identitätsproblem, indem sie es dem Betreiber übertragen — und erzeugen genau das Register, das vermieden werden soll. Ohne Identität entfällt allerdings die Verknüpfbarkeit: „dieselbe Person zum fünften Mal" ist nicht mehr von fünf Fremden zu unterscheiden.
**Stand der Technik (veröffentlicht).** Näherungsbeweise (BLE, Ton), Ed25519-Signaturen, C2PA als Standard für Herkunftsnachweise.
**Erfolgskriterium.** Der Dienst speichert ausschließlich zwei Zufallssalze und den resultierenden Hash; keine Seite konnte den Hash vor der Begegnung allein erzeugen; die Schlüsselkontinuität ersetzt den Namen.
**Ergebnis.** Bestätigt: Der Hash entsteht aus beiden Salzen und der vom Server vergebenen Zeit; Version v2 bindet zusätzlich die rohen öffentlichen Schlüssel beider Seiten ein, und der Schlüsselbesitz wird per Signatur nachgewiesen. Beschreibungen („mit wem") existieren nur auf den Telefonen. **Ausdrücklich benannte Grenze:** Der Beweis zeigt, dass zwei Seiten denselben Zeitpunkt gemeinsam gestempelt haben — er zeigt keine physische Nähe; dasselbe Protokoll lässt sich aus der Ferne ausführen und ist so zu lesen.
**Status:** umgesetzt (v1 und v2).

**Status der Richtung.** Zeitkern, öffentliches Log, Verankerung und Ko-Stempel-Protokoll sind öffentlich in Betrieb; die Anwendungsschichten (Android, Wear, Erweiterung, SDK) befinden sich im Aufbau. Nächster Forschungsschritt: Herkunftsnachweise für Inhalte (C2PA) als Schicht über dem bestehenden Log — als Schicht ergänzt, nie als Fundament.

---
---

# 🇬🇧 ENGLISH VERSION

## Koch Laboratory — time as an agreed unit and as evidence

This direction started from a practical question: why does agreeing on a single moment between two people in different time zones require a translation rather than a reading? It ended at a harder one: what must a time service be for its statement to carry evidential value for someone who trusts neither us nor our server?

**Method.** As in the rest of the laboratory: problem → hypothesis → falsifiable criterion → method → result with boundary conditions. Statuses are stated openly: "implemented" means running at a public address, "design work" means no measured result.

### 1. Direction 1 — a unit of time that can be spoken without context
**Research question.** Can a moment be stated so that the recipient needs to know neither the sender's zone nor their own — without losing reversibility against UTC?
**Why it is hard.** Time zones are not a function of geography but of political decisions: they change from year to year, include half-hour and seasonal offsets, and the rule base is a moving target. Every local notation therefore needs extra state to be understood — and that state is sometimes out of date.
**State of the art (published).** ISO 8601 and UTC (correct, but conversion happens at the recipient); Swatch Internet Time from 1998 — a zone-free unit, but anchored in BMT (UTC+1, the company's own seat) and without an open interface; TAI and Unix time as technical foundations, never meant to be spoken.
**Success criterion.** Reversible, test-covered conversion UTC↔unit with no dependency on any zone database; the unit coarse enough to be spoken in conversation (1/1000 of a day = 86.4 s) and fine enough to agree on a meeting to the minute.
**Result.** Confirmed within the criterion: anchored in UTC/Greenwich rather than BMT, an open API (`now`, `convert`, `sync`, `health`), the conversion core as a pure, tested module. Boundary condition: the unit does not replace ISO 8601 in machine records — it is a speakable layer, not a storage format.
**Status:** implemented.

### 2. Direction 2 — a clock that ticks without asking the server
**Research question.** Can a public clock run without network traffic while it runs — hence without telemetry and without a scaling cost — and stay accurate enough for the chosen unit?
**Why it is hard.** A clock that queries the server every tick is also a visitor counter: every tick leaves an IP address in someone else's log. A purely local clock, on the other hand, inherits the error of a device clock we neither control nor know.
**State of the art (published).** SNTP/NTP as the model of one-off offset synchronisation; web clocks that typically poll a server on a cycle.
**Success criterion.** Zero network requests after start-up; explicit measurement and publication of our own error instead of a silent assumption of correctness.
**Result.** Confirmed: the client fetches the offset once and ticks locally (the SNTP model), working offline. In addition, a periodic task measures the host clock's drift against NTP and exposes it in `/api/health` — **a time service that publishes its own error** rather than hiding it. Boundary condition: client-side accuracy remains bounded by the device clock; for a unit of 86.4 s that is irrelevant, for evidential use it is not — which is why the proof of time (direction 3) never rests on the client's clock.
**Status:** implemented.

### 3. Direction 3 — a public stamp log: existence without disclosing content
**Research question.** Can one demonstrate that a document existed in a given week without revealing its content and without trusting the operator of the service?
**Why it is hard.** An operator who can insert entries retroactively is useless as a witness — and the operator's own signature does not rule that out. The log must therefore be closed in time and verifiable by someone with no database access; at the same time, no verification may require producing the document.
**State of the art (published).** RFC 3161 (TSA — credibility reduced to trusting the authority), Certificate Transparency (Merkle trees with inclusion proofs), OpenTimestamps.
**Success criterion.** Only SHA-256 is recorded; the weekly root is frozen once the week has ended and signed with Ed25519; for any hash an inclusion path is reconstructible and checkable without access to the system.
**Result.** Confirmed: a weekly Merkle tree, a root frozen at week close, an Ed25519 signature, an inclusion path per digest, deduplication as "first seen". Boundary condition: the granularity of the proof is a week — the service proves "no later than", not "exactly at".
**Status:** implemented.

### 4. Direction 4 — anchoring in a register the operator does not control
**Research question.** What should the weekly root be anchored in so that the proof survives the loss of trust in the service — and does not depend on a single technical world of our own choosing?
**Why it is hard.** The anchor must land in a register dated by a third party, resistant to retroactive change, cheap, and repeatable weekly for years. A blockchain satisfies the first three conditions but introduces a dependency on one ecosystem and its cost; publication in the press (the classic Surety solution of the 1990s) is expensive and hard to automate.
**State of the art (published).** OpenTimestamps anchored in Bitcoin; the historical practice of publishing hashes in newspaper advertisements; commercial timestamping authorities.
**Success criterion.** At least two independent anchoring channels, neither controlled by the operator of the service, each verifiable on its own.
**Result.** Confirmed: the first channel is OpenTimestamps. The second is **the reference line of a bank transfer** — the weekly root written as `MROOT <YEARWnn> <8 groups of 8 hex characters>` (85 characters, fitting the 140-character reference field), booked by a regulated institution that keeps its own record of time, independent of us, and has no reason to alter it on our behalf. Boundary condition: the banking channel has booking granularity (business days) and requires a manual confirmation of the reference; it is cheap and entirely independent of cryptocurrencies, but it is not immediate.
**Status:** implemented.

### 5. Direction 5 — a draw nobody controls, ourselves included
**Research question.** Can a public random value be derived from material that the operator cannot select towards a predetermined outcome?
**Why it is hard.** Any server-side draw is unverifiable, and any "draw from a seed" is steerable if the seed is chosen by whoever announces the result. Commit-reveal schemes require discipline and another round of trust.
**State of the art (published).** Public randomness beacons (drand, the NIST beacon among others), commit-reveal schemes, deriving randomness from block headers.
**Success criterion.** The result is recomputable by anyone from material already published and already signed, with no server-side state whatsoever.
**Result.** Partial — and worth publishing as such. The value of the day is a function of the root of the **last closed week** and the date (`beattime-thebeat-v1|<root>|<date>`, SHA-256, first 6 bytes mod 1000). What is achieved is **unsteerability and full verifiability**: the operator cannot select the outcome, because the root was frozen and signed before the date came around. What is **not** achieved is **unpredictability** — the root is public, so anyone can compute the whole coming week's values in advance. We state this explicitly, because conflating the two properties is the most common error in this class of solutions.
**Status:** implemented, with an explicitly bounded property.

### 6. Direction 6 — proof of co-stamping a moment without the parties' identity
**Research question.** Can two people jointly record a single moment such that the proof is publicly verifiable and the service never learns who they are?
**Why it is hard.** The obvious solutions (accounts, phone numbers, contact lists) solve identity by transferring it to the operator — and create exactly the register we want to avoid. Without identity, however, linkability disappears: "the same person for the fifth time" becomes indistinguishable from five strangers.
**State of the art (published).** Proximity proof protocols (BLE, audio), Ed25519 signatures, C2PA as a provenance standard.
**Success criterion.** The service stores only two random salts and the resulting hash; neither party could have produced the hash alone before the meeting; key continuity replaces the name.
**Result.** Confirmed: the hash is derived from both salts and the time issued by the server; version v2 additionally binds the raw public keys of both parties, and possession of the keys is proven by signature. Descriptions of "with whom" exist only on the phones. **A boundary stated openly:** the proof shows that two parties co-stamped the same moment — it does not show physical proximity; the same protocol can be run remotely, and it should be read that way.
**Status:** implemented (v1 and v2).

**Status of the direction.** The time core, the public log, the anchoring and the co-stamping protocol are running publicly; the application layers (Android, wear, extension, SDK) are under construction. Next research step: content provenance (C2PA) as a layer above the existing log — added as a layer, never as a foundation.