This commit is contained in:
@@ -203,6 +203,10 @@ To recover a lost transfer key, obtain a read-only copy of the corresponding `<r
|
||||
|
||||
Recovery applies only to new records carrying recovery data. Old backups cannot be retroactively recovered without their original key. Expired or deleted backups are not recoverable through this workflow. Retain older private keys when rotating the public key; new keys cannot recover records encrypted for a previous key. No live data migration is required.
|
||||
|
||||
The next service update records the creating connection's IP address alongside the creation time. It trusts forwarding headers only from configured proxy peers; the public proxy must overwrite or append the actual client address. The IP represents the observed connection (possibly a VPN/NAT exit), not a verified device identity. IP metadata shares the backup's retention and deletion lifecycle and is not returned by the public restore endpoint. The client stores the creation response's IP in its local key list and displays it next to the creation time. Older backups without this metadata show an unknown IP; historical addresses are not inferred.
|
||||
|
||||
Append `--details` to the offline recovery command to write `22.09.2026 - 14:30 | IP: 203.0.113.10 | MHU2-...` instead of only the key. Detailed timestamps use Europe/Berlin. Paste only the `MHU2-...` part into the uploader. Without the flag, the output remains directly importable. This IP extension is not yet deployed. It introduces stored record version 4; the updated server still reads versions 1–3, but an older server cannot read new version-4 records. Do not roll back the server binary after creating such records without a data-preserving compatibility plan.
|
||||
|
||||
Treat the generated key like a password: anyone with it can restore the encrypted settings. Creating a new key does not invalidate older keys.
|
||||
|
||||
### Other network activity
|
||||
|
||||
Reference in New Issue
Block a user