Re: Temporal Stack

Isn't this HTTP E-Tag header purpose? (Versioning / Cache handling)

And "If-modified-since" header could also come of use, if we talk about
state (representation) of the same HATEOAS (REST) entity preserving its
identifier (the immutable part in a domain).

Also, a previous post in the public-webapps and other lists: "A less
ephemeral web" states things that could benefit onto what you propose.


On Sun, Mar 21, 2021, 9:37 AM Timothy Holborn <timothy.holborn@gmail.com>
wrote:

> had a think.  thought i'd post it.
>
> IMO there's cause to build into WWW / HTTP a method to support temporal
> lookups, other than simply using archive.org.   i imagine this would
> eventually require ICANN, IETF (etc) support; amongst other implications.
>
> The functional outcome would be an ability to look up a page at a
> particular date.   This may involve differences in who owned the domain
> name at that time (vs. who may own it later on), amongst many other
> implications.  There would have to be a 'format' of 'standards' around how
> to achieve it, for long-term support.
>
> Foundational requirements, prior to more easily engaging CMS providers
> such as Wordpress / automattic, drupal, etc.  would be to define a simple
> concept that could be built upon to do it.  I imagine it may take some
> years to do, and i'm not entirely sure i'm up for it - historically no
> funding for work by civics persons (civilians, working independent of
> contract / employment revenue) for doing W3C works; maybe, with new changes
> that might be reviewed; but regardless,
>
> cost of storage, etc. has been dropping.  I'm not sure what the economic
> model for it would be, but i can think of a variety of ways a solution that
> attends to the economic implications could be forged.  I also think, an
> evaluation may lead to an outcome where it's able to be understood how to
> do it at a lower energy cost than simply employing DHTs / Blockchains
> ("DLTs"), although the file-system layer may be considered independently,
> atm, idk; and don't really want to make the point any more complicated than
> it needs to be for now.
>
> Timothy Holborn
>
>