Text archives Help


Re: [projectvrm] Welcomer's approach to distributed identity


Chronological Thread 
  • From: Adrian Gropper < >
  • To: Kevin Cox < >
  • Cc: James Pasquale < >, Doc Searls < >, ProjectVRM list < >
  • Subject: Re: [projectvrm] Welcomer's approach to distributed identity
  • Date: Sat, 19 Sep 2015 17:10:35 -0400

The brain analogy cuts both ways. It can obscure what's actually going on "in there" and makes definitive predictions of future behavior more difficult. I don't understand Welcomer well enough to do a security or privacy analysis. 

How will we do a security or privacy audit on a Deep Learning system?

Adrian

On Saturday, September 19, 2015, Kevin Cox < "> > wrote:
Yes James P that is exactly what is happening.  It is not a complete accident as I spent a lot of time twenty five years ago building algorithms that mimic natural processes - e.g. Genetic Algorithms, Optimisation algorithms based on ant behaviour, and searching based on similarity.  I am very fond of Welcomer because it looks like the start of a model of the evolution of the mammalian prefrontal cortex.  That is where the idea of "reorganisation of links during periods of inactivity" comes from.  Welcomer will busily reorganise and makes sense of what has happened while it is asleep.  It also gives a way to forget by silos being disassociated from the Network.

Kevin

On Sat, Sep 19, 2015 at 11:47 PM, James Pasquale < ');" target="_blank"> > wrote:
FWIW:

This is a nice break through, whose architectural approach use mimics Natures Natural acts of Spontaneous Order. 

Technology mimicking real life in the natural order of things.

After all imitation is the greatest form of flattery…

Nicely done Mr. Cox and Team nicely done



Doc,

The key idea to make deployment "easy" is very simple.  It took us two years to realise how to do it but now that we know I ask myself why did it take so long?

The key implementation idea is that if we have two silos of information and we want to move a data value from one silo to the other then both silos have to have a place to put the "same" data.  So moving data is a problem that can be solved - before wanting to move data - by specifying a way for the same data elements to be linked.  Hence we have the specification side of Welcomer and then the creation of the links at run time.

Everything else follows from this idea but people understand it and I do not think they will be freaked out by it.  It will show itself to most people when they fill out a form by having access to the data they previously entered on a Welcomer Enabled data silo. That is they will see a drop down list of all previous values of this data item they have agreed to show in other applications. 

Implementation of this is simple when we have one physical data silo broken into many different organisational silos as we have with WelcomeAboard.  The challenge is to scale it to data silo's kept on different servers.  This is where the ideas of CloudOS are needed.  We started with CloudOS with the Welcomer links implemented as picos.  We have changed to doing the same thing but using Akka and Actors because the software is more mature and better known. This has also taken us a long time to work out how to do it and we are not there yet.

The most interesting part of the project is the meta data on the meta data.  That is, the new things that arise by putting other data objects into Welcomer itself and not into the data silos.  For example, the concept of Identity arises from the connections and can be made real by having a UniqueID known only to Welcomer modules that fits together connections made by a particular person.  In practical terms this creates a distributed ledger (or distributed index).

Adding value to transactions is another practical example of metadata on metadata.  I am working on Welcomer Credits as a way of recording the transfer of value for actions taken where the identities are involved in connections that result in the exchange of value. Money can be viewed as property of the transfer of things of value between different parties. We work for someone and they give us some money.  We promise someone something and they issue us credit. This has the potential for each of us being responsible for issuing our own money up to some limit for our basic needs because we will be able to record the money we issue in a distributed ledger.  This is how we can pay for education.

I made a very brief mention of these possibilities when I likened Welcomer to an early stage prefrontal cortex.  The prefrontal cortex links the silos of sensations and data from different sensors in our bodies.  This gives rise to memory and the ability to change behaviour depending on the environment.  This is in contrast to the reptilian like applications based around a single data silo and the repetition of behaviour.  Welcomer may be a possible model for the prefrontal cortex. 

It all makes for an interesting time and I hope others will join in and investigate the approach or point me to others who are doing the same or similar things.

I am planning on setting up a system where we will pay for the ongoing development of the open source software by charging fees for copies of the software that are used by other trusted parties.    Welcomer has an identity and we can say that the software with this identity is used by X, Y and Z. If you wish to use software with a particular identity then funds must be paid in Welcomer Credits to the developers and maintainers of Welcomer.  I am hoping in the long term Welcomer will be owned by "the crowd". The payments for use can be enforced by building the concept into the Welcomer application.  If we can do it for Welcomer then we can do it for other applications.  This means people will be able to get money from the continued use of the applications because it is built into the applications.

Kevin







On Sat, Sep 19, 2015 at 7:53 AM, Doc Searls < ');" target="_blank"> > wrote:
Check out Kevin Cox’s 5-minute video here: <Welcomer>.

I’m impressed. It’s deep, clever, and do-able, I think. Open source too.

Doc



--
Contact 0413961090




--
Contact 0413961090


--

Adrian Gropper MD

RESTORE Health Privacy!
HELP us fight for the right to control personal health data.

DONATE: http://patientprivacyrights.org/donate-2/




Archive powered by MHonArc 2.6.19.