Teaching the Web object permanence

[BigBlueHat]

Current browsers provide primarily ephemeral storage in the form of caches and disposable key/value databases (i.e. localStorage, IndexedDB). None of these are sufficient for "keeping" a publication.

There is a Storage API at the WHATWG that intends to wrap the various storage related APIs (i.e. localStorage, IndexedDB, etc) into "buckets." That document specifies a navigator.storage.persist() which does outline how to request that storage be persisted.

Some issues:

• The request is per-origin, and is currently specified to only ask the user's acceptance once per origin. For example, if the user deny's example.com's ability to persist storage while reading one publication then it will have already been determined for all other example.com publications.
• Users can remove persisted storage (in a similar fashion to the current clear data options) and that too is scoped to a [schemeless origin] label (i.e. all publications from example.com would be removed).

The current available browser technology, therefore, is insufficient for providing "keep-ability" of a publication with any expectation of "object permanence."

Consequently, we need to look toward crafting APIs that provide a system for "object permanence" which:

• is less ephemeral than the current storage options
• persists beyond the longevity of a rented origin label (i.e. a domain name)
• remains identifiably distinct alongside its originating URL (to prevent re-rented domain/URL collisions over time)
• is retrievable by the user regardless of network availability

Some of these needs may map to the Packaged Web Publication needs, though the requirement to prepackage the publication (by the publisher) should not be a requirement--though it may be the method used within the browser for providing for this "keep-ability."

[iherman]

I am not sure whom you refer to as "we" in:

Consequently, we need to look toward crafting APIs that provide a system for "object permanence" which:

Do you mean that this WG should craft an API for that purpose? If that is what you meant than I think this is (way) beyond what we should and even are able to do. It is general OWP issue. If what you mean is that we could keep an eye on that evolution to see if it is in line with what WP implementations may need, then that is of course fine. (Though I am not sure who in the group have the technical baggage to do that...)

[BigBlueHat]

Close as out of scope for this group. Possibly record as "a thing the Web should do for publishing (writ large)."