“Private” and “encrypted” are not synonyms, and “public” and “indexed” are not synonyms either. Inpages.me models those distinctions as separate states. That makes the system less magical, but it gives each promise an enforceable boundary instead of asking one visibility flag to carry several meanings.
The state model
Every Memory has a protection state and a visibility state. A Standard Memory is server-readable but begins private to its owner. A protected Memory stores selected fields and files as browser-generated ciphertext and is always private. A public Memory must be Standard so Rails can render it for an anonymous reader.
| State | Anonymous access | Server-readable content | Search eligibility |
|---|---|---|---|
| Standard + private | No | Yes | No |
| Encrypted + private | No | No protected plaintext | No |
| Standard + public, Publisher mode off | Yes | Yes | noindex |
| Standard + public, Publisher mode on | Yes | Yes | Canonical URL in sitemap |
This model deliberately leaves out an “encrypted + public” state. A public browser cannot decrypt with the owner's Master Key, and handing that key to every reader would destroy the protection boundary. Encrypted memories cannot be published.
The protected boundary
When a Memory moves to Encrypted writing & files, the browser transforms its title, rich-text content, external-link values, keepsakes, and inline-image bytes. Rails validates and stores the resulting ciphertext. The transition also forces the Memory to private and clears server-derived summary and context fields.
That last step matters. It would be inconsistent to encrypt the source while retaining a plaintext summary derived from it. The same rule applies to new server-side features: search, AI assistance, previews, and analysis cannot quietly consume protected content merely because their output would be useful.
Protected does not mean metadata-free. Hashtags and operational records remain outside the encrypted set. It also does not protect an unlocked browser from malicious same-origin JavaScript, extensions, screenshots, or a compromised device. The end-to-end encryption threat model names those limits in detail.
Publication as an explicit command
Visibility does not change through ordinary autosave. Publishing uses a dedicated authenticated command with the editor's latest acknowledged timestamp. Rails locks the Memory, rejects a stale request, checks that the content is Standard, requires a nonblank title and body, changes the status, and synchronizes search eligibility with Publisher mode.
Keeping publication outside autosave prevents a malformed field update from accidentally turning a draft public. It also gives the interface a moment to explain the consequence: writing, external links, and keepsakes become available to anyone with the public URL. Search discovery is handled separately.
Unpublishing uses another explicit command and removes the page from search eligibility. A later publication follows the owner's current Publisher mode while preserving any Inpages moderation exclusion. The public boundary follows the current record, not the historical slug or a cached interface state.
Public access and search indexing are separate decisions
A newly published Memory can be read by anyone who has its URL. It renders with noindex while Publisher mode is off; when the owner deliberately turns Publisher mode on, current and future public Memories become eligible for search immediately.
Search eligibility remains narrower than public access. The model's shareable scope requires public status and Standard protection. Its search_indexable scope also requires Publisher mode and no moderation exclusion. Controllers use the first boundary for anonymous reading; sitemap and public discovery eligibility use the second.
Editing search-facing content, attachments, or external links keeps the page synchronized with Publisher mode. An Inpages moderation exclusion persists across those edits. Google documents that noindex blocks a crawled page from Search, while sitemap submission helps discovery but does not guarantee indexing.
One canonical public route
A public Memory can appear under a Journal route when the Journal itself is public, or under a direct message route when the Journal remains private. The application selects one canonical URL for the current state. A duplicate direct route redirects to the nested route when the Journal is public.
Only the canonical address enters the sitemap, and internal sharing helpers produce that same address. Google's canonical URL guidance recommends consistent canonical annotations and internal links; its sitemap guidance says to include the fully qualified canonical URLs a site wants in search results.
Canonicalization is not authorization. Both public routes still resolve only Memories that satisfy the shareable boundary. A guessed slug for a private or encrypted Memory does not become readable merely because the route shape exists.
How boundaries constrain features
The clearest product choices follow directly from the state model. A protected Memory must return to Standard protection before publication. That reverse transition decrypts fields and files in the browser, replaces their stored representations, and remains private until a separate publish command succeeds.
A public Journal or profile also stays out of search while Publisher mode is off or when visible child content has an Inpages exclusion. Public aggregate responses expose public counts rather than private or encrypted totals. External links in published content receive defensive relationship attributes. These rules prevent surrounding discovery features from becoming side channels around the Memory boundary.
The cost is additional state and fewer convenient shortcuts. The gain is language that maps to behavior: private means owner-only access; protected means selected plaintext is unavailable to Rails; public means anonymous access; Publisher mode means those public pages may be discovered through search. The user-facing workflow for turning private experience into public writing is covered in share a journal entry without oversharing.