| 1 | # Offline data is a separate capability |
| 2 | |
| 3 | The PWA kit lets an installed worker answer failed navigations with a public |
| 4 | offline page. It does not make server-rendered screens usable offline. |
| 5 | |
| 6 | An offline app needs a local model, durable pending operations, and a server |
| 7 | protocol that can reconcile them. Extract those mechanisms from an existing |
| 8 | application only after a second, different application can adopt them. |
| 9 | Eleven and Ocho share ancestry, so their duplicate code alone does not prove |
| 10 | a general data or conflict model. |
| 11 | |
| 12 | Before calling an offline kit reusable, prove these behaviours: |
| 13 | |
| 14 | - Pending operations survive app/worker termination and restart. |
| 15 | - Retrying after a lost response cannot duplicate the server operation. |
| 16 | - Account switching and sign-out cannot reveal or submit another account's data. |
| 17 | - Local schema upgrades and server protocol changes preserve queued work. |
| 18 | - Conflicts, deletes and revoked access have explicit, tested outcomes. |
| 19 | - Synchronisation resumes when the app opens; background execution is optional. |
| 20 | |
| 21 | Encrypted offline storage adds a separate key lifecycle. Define what can be |
| 22 | read while locked, how keys are recovered or revoked, how account removal |
| 23 | clears local material, and what notifications can reveal. Ciphertext beside |
| 24 | an accessible decryption key is not equivalent to a locked vault. |
| 25 | |
| 26 | Reuse Rastrillo's crypto/keyring contracts where compatible and test bytes |
| 27 | across implementations. Do not copy Eleven's thread-key or message policy |
| 28 | into a general storage package. Keep browser and native storage adapters |
| 29 | separate even when their protocol and test vectors are shared. |
| 30 | |
| 31 | No offline sync engine or encrypted vault is shipped by this first kit. |
| 32 | |
amadan