Re: Temporal Stack

On Sat, 8 May 2021 at 03:26, Timothy Holborn <timothy.holborn@gmail.com>
wrote:

> cheers...
>
> a bit of digging led to:
> https://www.madmode.com/2012/bake-fry-frozen-flask.html which then led
> to:  http://www.aaronsw.com/weblog/000404
>

DanC had a lot of good ideas when he was active and I believe was part of
the input to "Paper Trail"

His comment here:

"Using a database-backed, through-the-web blogging tool was a big change
for me, after over a decade of using version-controlled static files at W3C"

Version control has come a long way since he wrote that in 2012.
Especially with git based systems and web based git systems.  The immersive
read write experience with version control seems a step closer

But there's a sight paradox.  And that is while git is designed to be
decentralized, github is has become used as a semi-centralized way of doing
things.

You make a change on the web or on your file system, and then you write and
commit it to git locally, and usually you push that change to github etc.

What is needed is web scale version control

This would allow reading and writing to the web, and browsing the history,
without it being controlled by one silo, one archival service or one website


>
> On Sat, 8 May 2021 at 03:28, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On Fri, 16 Apr 2021 at 17:42, Sebastian Samaruga <ssamarug@gmail.com>
>> wrote:
>>
>>> 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.
>>>
>>
>>  I was rereading lately Paper Trail:
>>
>> https://www.w3.org/DesignIssues/PaperTrail
>>
>> Generalized form:
>>
>> Generalizing for formal protocols
>> The concept of a paper trail is common in conventional administration,
>> but the model can also be applied to well-defined computer protocols.
>>
>> Model
>> The model is that a protocol P defines a status sn as a function of a
>> message m and a previous state sn-1, and the time t.
>>
>> sn= P(mn, sn-1, t)
>>
>> or for that matter as a function of all the messages to date
>>
>> sn= P'({mi}i=1..n)
>>
>>
>>
>>>
>>>
>>> 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
>>>>
>>>>
>>>