The Clique Space(TM) Client Device is a Lie Detector

Everything is a device in Clique Space. Agent Devices (those devices that make the Clique Space system) and Client Devices (any other device, including the administrator Client Device being developed in parallel to the Agent Device) are simply different devices to Clique Space. Agent Devices, being mere devices, are subject to the same control mechanism as any other device. This point is an important designed intention.

Agent Devices establish Connections amongst themselves through a process of engagement. The product of this process is something I have come to call a synapse - seeing as it appears remarkably similar to one of these.

Client Devices establish one or more Connections with one or more Agent Devices through a slightly different process, and although this process yields something similar to what the product for the Agent Devices is, the fact that the Client Device can engage with multiple Agent Devices (there is no real reason to say that a Client Device cannot engage a single Agent Device more than once, but I have yet to test such a scenario) allows the user of the given Client Device (should it be equipped with a View adapted to some medium) to detect lies.

Lie detection... how does this happen?

Well, the Client Device can't tell you who is doing the lying, but it can tell you that one or more of the Connections to the (serving) Agent Devices are sending information relating to one or more Elements that is inconsistent with one or more of the same Elements sent from one or more other of the serving Agent Devices; indeed, a form of lie detection. So, how does this work?

Summarily, Elements are sent from an Agent to a Client Device through tokens, and each token is kept by the Client Device until the token's serving Agent Device tells the Client Device to remove it. An Element is recreated as a composite of the different tokens. Hence, the term that I use to describe the exchange of a token: "projection" makes each token a little bit like a light beam projecting an image on to a screen. The more light sources one has, the more accurate one might expect the image to be.

Lies can be detected in two basic ways: 1. token inconsistency; should the details of any set of tokens describing an Element differ in ways that another set of tokens describe the same Element, then that Element is "token-inconsistent". 2. Element inconsistency; relating to the inter-Element relationships between two or more Elements, "Element-inconsistent" relationships become apparent when these relationships (say, between an Affiliation and its component Account) are found to contradict through Elements only once they are assembled. In the case of the Affiliation - Account relationship, this element inconsistency will become obvious if, when composing the Affiliation from its tokens, one or more of these tokens discloses a differently identified Account than the Account assembled from its tokens which is stating that it points to the given Affiliation.

In the case of the Element-inconsistent Affiliation - Account relationship, these relationships only become evident at the time of the Elements' assembly within the Client Device to which the tokens have been projected.

Such contradictions could point to some problem with the serving Agent Devices, but yet again, they probably also point to nefarious intent of the operators of the serving Agent Devices. So, if you're a Clique Space user, and you don't trust the opinion of the person operating a singular serving Agent Device, seek a second (or perhaps a third or a fourth) opinion and ensure safety in consensus through simultaneous Connections to multiple serving Agent Devices; preferably ones which each are operated by different individuals. No serving Agent Device's operator would (nor should they) ask that you only connect to a single Agent Device, or only restrict your connection to those Agent Devices operated by a given individual. If they do ask you, then just lie and say "of course I am".

Clique Space(TM) Progress Report. Another possible milestone... perhaps.

Evolution.

My prototype Agent Device appears to have many of the functional attributes it needs to set itself up, project Elements to connected Client Devices (capable of viewing Elements), and respond to commands from an administrator's Client Device, itself capable of viewing Elements albeit currently only through console output. Very nice.

I have often likened programming to crochet; sure as I am are the similarities between a nicely crafted algorithm and a nice lace doily. Clique Space, however, is a veritable Persian carpet.

What use the Active Affiliation?

I've been pondering whether the Active Affiliation serves any specific purpose for some time, having talked briefly about this subject before.

The Active Affiliation Element was intended as a kind of state-object that connected devices would acquire to indicate that the connection was authenticated. Devices that possess a View would then use their Active Affiliation to form a Clique with their serving Agent Device. Other devices that did not receive View information from the serving Agent Device would acquire Participants when engaged with relevant other devices in Clique Space, otherwise devices would possess a lone Active Affiliation when not engaged with other devices in any collaboration.

Now that I'm developing the concept, my understanding of the relevance of each of the pieces shifts and one consequence of this appears to be that I'm being drawn to the conclusion that the Active Affiliation is redundant, and the Participant can take on the intended 'authentication' purpose of the Active Affiliation implying that media spines might only have three vertebrae: the Media Profile, Connection, and Participant Elements. The serving Agent Device's Participant and the bipartite Clique in which both Participants exist, is generated for all devices -- the mode of which differs with the type of device and what state information it exchanges with the serving Agent Device through which the device is connected to the Clique Space in question.

All this leads more directly to the convenience, or rather, the very point of Clique Space: Cliques model collaborations. And because every device has to "collaborate" with a serving Agent Device, at a minimum every device must form a Clique with its serving Agent Device before any View or log-based device can observe this collaboration and discover other collaborations this device might be involved in which are being modelled (and possibly controlled) by the Clique Spaces over which their Cliques span.

Now, my proof-of-concept has been evolving for some time. While the removal of the Active Affiliation from the core data model will ultimately simplify the implementation, this procedure is to going to be messy. Obviously, I'm going to consider this issue for some time yet while other issues are worked through.

Clique Space(TM) administrator Client Device command grammar.

After committing my last revision (I think it was 478) which has seen a stable implementation of the Agent Device disengage process, I decided it would be a good idea to map the assortment of commands available to the Client Device in a reasonably formal grammar.

The notation I have ascribed to is my own, developed as I put the grammar together; it should be fairly easy to work out, and although the elements "schema:label" form may lend itself to a meta-notation, I have not given such a schema the little consideration required beyond this because I don't currently care to.

Here it is:

command:=

command-clause:without-delegate|

{keyword:with value:delegate-identifier command-clause:with-delegate}

command-clause:without-delegate:=

command-clause:disband|

{keyword:list command-clause:list-without-delegate}|

command-clause:connect|

command-clause:show-or-hide-Clique-Space|

keyword:help|keyword:exit

command-clause:list-without-delegate:=

command-clause:list-Clique-Space|

command-clause:list-structure|

command-clause:list-Clique-without-delegate|

command-clause:list-Element-without-delegate|

keyword:rmi|

keyword:tokens|

keyword:cliques|

keyword:cliquespaces|

keyword:elements

command-clause:list-Clique-Space:=

keyword:cliquespace value:Clique-Space

command-clause:list-structure:=

keyword:structure keyword-clause:Element-type value:Element-identifier

command-clause:list-Clique-without-delegate:=

keyword:clique [value:Clique]

command-clause:list-Element-without-delegate:=

keyword:element keyword-clause:Element-type value:Element-identifier

command-clause:connect:=

keyword:connect value: Agent-Device-name

[keyword:accountprofile value:Account-Profile-name]

[keyword:cliquespace value:Clique-Space-name]

command-clause:show-or-hide-Clique-Space:=

keyword:show|keyword:hide value:Clique-Space-name

command-clause:with-delegate:=

command-clause:Particpant-adapter|

command-clause:Active-Affiliation-adapter|

command-clause:Connection-adapter

command-clause:Participant-adapter:=

command-clause:list-with-delegate|

command-clause:disband|

command-clause:join|

command-clause:leave|

command-clause:deactivate-other|

command-clause:form-other|

command-clause:activate-other|

command-clause:disconnect-other|

command-clause:create|

command-clause:destroy|

command-clause:Active-Affiliation-adapter

command-clause:Active-Affiliation-adapter:=

keyword:deactivate|

command-clause:form-self|

command-clause:Connection-adapter

command-clause:Connection-adapter:=

keyword:disconnect|

{keyword:activate command-clause:activate-self}

command-clause:list-with-delegate:=

keyword:list command-clause:list-Clique-with-delegate|command-clause:list-Element-with-delegate

command-clause:list-Clique-with-delegate:=

keyword:clique delegate-token:Participant-adapter value:Clique-name

command-clause:list-Element-with-delegate:=

keyword:element delegate-token:Connection-adapter keyword-clause:Element-type value:Element-identifier

command-clause:disband:=

keyword:disband [value:Clique-name]

command-clause:join:=

keyword:join value:Clique value:Clique-Space value:Active-Affiliation-identifier*

command-clause:leave:=

keyword:leave value:Participant-identifier*

command-clause:deactivate-other:=

keyword:deactivate value:Active-Affiliation-identifier

command-clause:form-other:=

keyword:form value:Clique-name value:Clique-Space-name value:owner-Active-Affiliation-identifier

value:member-Active-Affiliation-identifier*

command-clause:activate-other:=

command-clause:activate-self value:Connection-identifier

command-clause:disonnect-other:=

keyword:disconnect value:Connection-identifier

command-clause:form-self:=

keyword:form [keyword:clique value:Clique-name] [keyword:cliquespace value:Clique-Space-name]

value:Active-Affiliation-identifier*

command-clause:activate-self:=

value:Active-Affiliation-identifier

command-clause:create:=

keyword:create

{keyword:account value:user-identifier}|

{keyword:accountprofile keyword:name [value:Account-Profile-identifier*]}|

{keyword:affiliation value:Account-identifier value:Account-Profile-identifier}

command-clause:destroy:=

keyword:destroy keyword-clause:non-spinal-Element-type value:Element-identifier

keyword-clause:Element-type:=

keyword-clause:non-spinal-Element-type|

keyword:mediaprofile|

keyword:connection|

keyword:activeaffiliation|

keyword:participant

keyword-clause:non-spinal-Element-type:=

keyword:account|

keyword:accountprofile|

keyword:affiliation

I believe this grammar discloses a lot about my concept. Although perhaps disclosure of this detail is fraught with intellectual property hazard, I hope it might stand as proof to some that what I am doing is of realisable value, and that some day, a society might actually pay me recognition for this value. These are the motivations for publishing.

Clique Space(TM): A disengaging development.

Earlier this afternoon, and although perhaps a bit rough, I can now get two Agent Devices to disengage. The engage/disengage process has a wonderful parallel to the notion of the Agent Collaboration. This is because, like the Agent Collaboration (a manifestation of a Clique Space), a relationship being formed in the engage process and destroyed in the disengage process between two Agent Devices can be modelled as a Clique. As I have said before, this product, representing precisely two conjoined Agent Devices, appears to me to necessarily mirror the function of a synapse.

Because Clique Space should be able to model any collaboration between (or even within) a device, Clique Space should be capable of modelling collaborations between its own components. Hence, this means modelling collaborations at two levels: 1; at the level of the engage/disengage Agent Device Clique Space's synapse, and 2; at the level of form/join/leave/disband Agent Collaboration Clique Space's Clique.

Now, it appears that I still have one substantial obstacle to realising a minimally functional prototype: the Agent Collaboration's pulse message. At this time, functional specifics of a pulse are very sketchy, and much more thought than has been the case up until now will be directed to this pulse thing. While I deliberate, I will revisit the Client Device with the hope of simplifying its command syntax. This will hopefully 1; make a demonstration easier to understand, and 2; allow me to add commands in a more orderly manner, which will hopefully simplify the introduction of commands concerning the pulse message.

The Client and Agent Devices are co-evolving components; a significant observable property of Clique Space's development process is how development alternates, and at times goes on simultaneously, between the Agent and Client Devices.

Clique Space(TM) Progress Report.

Most of my time has been taken up by coding my proof-of-concept, and hence, I haven't been generating as many of these web log entries this year. That's no bad thing because I can't keep talking without an implementation. This implementation continues to evolve, although very slowly; such is the pace set by the capricious, somewhat bone lazy, wandering endeavour of one individual.

Anyway, a sufficient interface between the Agent and the Client Device appears to have been implemented, and so, most time of the near to medium term will now concentrate on what goes on between Agent Device instances: the Agent Device's and Collaboration's Clique Space. There is still much work to be done here.

Nose to the grindstone (or something like that)...

Coming together...

I can really see the pieces of Clique Space(TM) come together. I've completed the Agent Device engagement process, the projected Element contains tokens thing, and I've been retrofitting a class that manifests an Element's identifier (ElementIdentifier) to see if I can architect a way to discriminate between different identifiers so I can (inter alia):

• indicate an Element's serving Agent Device through its EngagerParticipantIdentifier.
  
  
• prevent an errant (or nefarious, or even perhaps merely a narcissistic) user from giving an identifier a specific value; an identifier's value has no inherent meaning beyond its ability to uniquely identify an Element, and each Element is assigned an identifier who's value is currently a 40 character randomly generated upper-case alphanumeric string when the Element is created on it's serving Agent (or, indeed, Client) Device.
  

Other things like the co-evolution of the Agent and Client Devices, the growth of the number and variety of the Elements and the growth of the complexity of the interactions between the Agent and Client Devices continue to inject increasing functionality into the implementation. As the system's complexity evolves, I observe the data model moving from a simple implementation to a more abstract and generic one. I introduced Java generics about a year ago, and this move has (hopefully for the better) proven indispensable in expressing the relationship of the Agent and Client Device's specific use and manifestation of the generic data model.

Just yesterday, I completed the projected Element's existential life-cycle by coding a method that "unprojects" Elements given an Element's identifier, and the delegate identifier of the serving Agent Device through which the given Element token has been obtained. It works. I can remove any Element describing any part of a projected Client Device's structure from any Client Device through which the command to unproject is issued. I am entirely confident that implementing a robust identity/anonymity mechanism using this ability to unproject any projected Element is not far away.