Re: operating-system or co-operating systems? Re: Coherent (modern) definition of RWW

On Wed, 19 May 2021 at 09:55, Henry Story <henry.story@bblfish.net> wrote:

>
>
> > On 19. May 2021, at 07:36, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
> > [snip]
> >
> >>
> >> Hi Timothy,
> >>
> >> FWIW -- A Read-Write Web is simply an Entity Relationship Graph (Graph
> for short), constructed from hyperlinks, that supports Create, Update, and
> Delete operations -- in one form or another.
> >>
> >> Fundamentally, you can add, alter, and remove parts from said graph.
> >>
> >> Web 1.0, 2.0, and 3.0 themed technologies have offered the above in
> various forms with associated consequences re:
> >>
> >> 1. Interaction Flexibility & Inflexibility  via Application or Service
> Experience
> >>
> >> 2. User Privacy
> >>
> >> 3. Society at large .
> >>
> >> Personally, I don't fixate on perfect definitions or "one size fits
> all" world views. I prefer to simply get stuff done by implementing
> relevant open standards are various Super Set oriented entry points (*
> which may not always be obvious initially *).
> >>
> >> In conclusion:
> >>
> >> Let's crack on with getting stuff done since we have all the open
> standards and specs in place. Basically, write stuff, share it with others
> to test interop.
>
> +1000 to learning by practice.
> These sometimes though do lead people to stumble on philosophical or
> mathematical problems
>
> >
> > The more the do that the better for item #3 which I know you care a lot
> about :)
> >
> >
> > So I think you could view the web as a giant state machine.  And writing
> to the web is changing that state machine
>
> So here you have to be very careful. It may be a lot more correct to state
> that the web is an open ended set
> of state machines in communication with one another. This moves you to the
> actor model of computation.
> Carl Hewitt who developed that model wrote up a very readable history
> which I link to from here
> https://twitter.com/bblfish/status/1358103100104572930


Interesting link, thanks for sharing


>
>
> > So the potential of a read write web is to create a web scale operating
> system, which is something we've not yet seen
>
> Operating Systems tend to be thought of as systems to control 1 machine -
> a computer, phone, watch, etc…
> When dealing with many machines I think it is therefore better to think
> not of an operating system but
> instead of co-operating systems.
>

When we launched solid, timbl was asked by the BBC as to its goal.  And he
said something along the lines of an operating system for the web.  I think
he has made inroads in creating a web scale file system (modeled on the
UNIX file system).  Take a look at some of the functions of system V IPC

https://www.oreilly.com/library/view/understanding-the-linux/0596005652/ch19s03.html

Some things like inter process communication, having a clock, semaphores,
sync, sending messages, are arguably under developed

Calling the web an OS is partly a metaphor, partly a mental model, possibly
some branding, but ultimately drilling down into protocols we could make,
and use cases we could solve


>
> > I may be wrong here, but I think that all operating systems rely on a
> clock
> >
> > Now imagine if the clock was internal to any one process (think server),
> that would not make sense for an operating system
>
>
> You can indeed also have synchronized clocks.
> The If-Modified-Since and If-Unmodified-Since http headers rely on that.
>
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since


Intuitively, if-modified-since, could be a very important piece of the
puzzle as we tie together a read write web, with temporal aspects, and
expose it RESTfully to clients


>
>
> >
> > An external clock that you can hook into brings us one step closer to an
> read write, standards based, operating system for the web.  This could be
> done both with server side apps, which now become just agents, and also
> with client side apps, you could imagine a user interface changing
> dynamically over time, perhaps evn democratically.  Lots of nice
> side-effects drop out of this
> >
> > It goes without saying that all of these changes should be 100%
> backwards compatible with what exists, so that it augments, rather than
> replaces
>
> Synchronised clocks are an indeed important part in all read-write web
> protocols for HTTP from WebDav, Atom to LDP.
> So that is already how the RWW works.
>
> The danger of thinking in terms of Operating Systems is that it leads you
> to the dreams of global consensus.
> But as we see with bitcoin, the selection of the next state of the bitcoin
> state machine, is extremely
> costly in energy. As a result over 50% of bitcoin mining is now going on
> in China, and is very far from
> the decentralised dream people had 10 years ago.
>

Decentralization is an 'axiom' of the web, or of 'the web done right',
perhaps.  But it's never black or white, more a spectrum.  The word
decentralized never appears in the bitcoin white paper, but distributed
appears multiple times.  It has worked impeccably as a timestamp server for
over a decade

You can create low energy solutions on top of this time stamp server, and
bring the cost down many orders of magnitude

https://blockstream.com/liquid/

Is an example, which has a slightly different trust model, is much cheaper
and provides a regular heartbeat, and adds more features at an almost zero
energy cost, yet with almost the same security assurances.  This would be a
perfectly good, unimpaired, candidate for creating working prototypes with
strong assurances


>
> Furthermore not every application lends itself well to such a state
> machine, It can work for purely
> mathematically based systems like currencies where the whole state can be
> verified by everyone, but
> it gets a lot more complicated for empirical statements, where semantics
> becomes important. I wrote
> some thoughts on that up here:
>
> https://medium.com/cybersoton/identity-as-a-graph-or-a-chain-f15940beec81
>
> The blockchain is distributed but not decentralised: it requires one view
> of the truth.
>
> In democracies we need to take into account the multi-perspectival nature
> of reality.
> There may be one truth - as an ideal - but that can only be attained by
> discussions among
> incompatible, often contradictory views of reality. That is why a
> multi-agent system
> is the right place to start thinking about these things. Local consensus
> first, global consensus
> later, perhaps and only if needed.
>

Multi perspective nature is definitely the aim.  Totally agree to local
consensus first, then global consensus

However, I have built dozens of prototype agents using local consensus.  I
have found that you hit walls early, and often without something external
from those agents to coordinate them.  I would much rather have an agent
driven by an external public heart beat.  As this can prevent tie breakers,
race conditions, and become byzantine fault tolerance.  These properties
have the nice side-effect that it has been shown that the agents could then
be suitable for payments or even to pay for things themselves (in small
amounts), in turn, leading to new use cases

Local consensus and global consensus together, I agree.  Tie both together
with hyperlinks / URIs.

I think we're agreeing that we want to see co-operating agents, and
co-operating systems.  These are ultimately metaphors which approximate to
what can become use cases and protocols to power them ...


>
>
>
> Henry Story
>
> https://co-operating.systems
> WhatsApp, Signal, Tel: +33 6 38 32 69 84‬
> Twitter: @bblfish
>
>