Known limitation (v1 trade-off)
The time-lock on a capsule relies on the device's local clock. Because of this, rolling the device clock forward past unlockAt will cause a capsule to unlock early, without waiting for the real elapsed time.
Why this is the case in v1
Reframe is on-device only — no cloud, no account, no server. There is no trusted time source other than the device clock, so the lock is computed as unlockAt = createdAt + preset.duration and compared to DateTime.now(). This keeps the app simple, offline, and private.
Future work — clock-tamper resistance
Possible approaches to make the lock harder to bypass:
- Bind unlock eligibility to a monotonic clock / uptime where possible, so a wall-clock change doesn't advance it.
- Detect large backward-then-forward clock jumps and refuse to unlock until real time has visibly progressed.
- Persist the last-known real time and compare against it on the next open.
- Optionally offer a "trusted time" mode that verifies against network time (NTP / a timestamp service) before unlocking, at the cost of requiring connectivity.
This is tracked as future work, not a regression. Discussion and PRs welcome — please keep any solution consistent with Reframe's offline, no-account philosophy.
Known limitation (v1 trade-off)
The time-lock on a capsule relies on the device's local clock. Because of this, rolling the device clock forward past
unlockAtwill cause a capsule to unlock early, without waiting for the real elapsed time.Why this is the case in v1
Reframe is on-device only — no cloud, no account, no server. There is no trusted time source other than the device clock, so the lock is computed as
unlockAt = createdAt + preset.durationand compared toDateTime.now(). This keeps the app simple, offline, and private.Future work — clock-tamper resistance
Possible approaches to make the lock harder to bypass:
This is tracked as future work, not a regression. Discussion and PRs welcome — please keep any solution consistent with Reframe's offline, no-account philosophy.