1. Create
The author sends markdown content and a policy to the API. The server stores the sanitized note body, any password hash, and the active expiry and access limits.
What actually happens between note creation, reading, and cleanup.
This guide explains the current `notefade` note lifecycle in product language, using the same create, preview, unlock, read, and cleanup flow the backend implements today.
End-to-end flow
From authoring to deletion
The note lifecycle is split across public routes so recipients only see what the API allows at each step.
2. Preview
Anyone with the link can hit the preview route to learn the note policy state, including whether a password is required, without seeing the body itself.
3. Unlock if needed
Password-protected notes require the recipient to post the password to the unlock route. A successful unlock returns a signed read token tied to the note expiry window.
4. Read
The read route returns the stored markdown body. View counts, device counts, and access-event records update during the successful read path.
5. Destroy or expire
A note becomes consumed on destroy-on-read, destroyed when it reaches the last allowed successful view, or expired when the server sees the expiry window has passed.
6. Cleanup
Expired notes and older destroyed-note tombstones are removed later by the scheduled cleanup job instead of being erased instantly inside the request path.
Access rules
- Password protection gates access but does not currently encrypt note content at rest.
- Device limits work by storing a browser-side device identifier when available and matching that identifier on later unlock or read requests.
- View limits only advance on successful reads, so previews alone do not consume a note.
Destruction triggers
- Destroy-on-read means the first successful read consumes the note for future visits.
- If `max_views` is set, the final permitted successful read marks the note destroyed after that read completes.
- If `expires_at` has passed, the API returns an expired state immediately even before the cleanup job deletes the row.
What users should expect
Immediate access blocking is not the same as immediate erasure.
The service is designed to stop access quickly, then let the cleanup job remove expired or long-destroyed records off the request path.
Important distinction
A note can be unavailable to recipients before the row disappears from storage. That is why the privacy and lifecycle pages avoid promising instant deletion at the exact moment a note expires or is consumed.