Data model.

I've decided to disclose a data model for Clique Space. This has come about because of a discussion I had with someone who advised me to provide some pictures that help the reader understand the Jericho document I disclosed in my last post.

If Clique Space(TM) is a thing that is good, I want it to be known that I came up with it. Hence, this entry is me making a pre-emptive claim to this concept.
Although this isn't a full disclosure, perhaps the disclosure that I do provide is enough for someone else who has more money than myself to take and make even more money from. Perhaps such a person doesn't wish to let this world know that they have taken my ideas and claimed them as their own.

I know... I'm perhaps a bit paranoid. I think I'm dealing with it. Let Clique Space be mine or let it be no one's. If it is any good, what good would it do to continue to keep it away from this world.

Jericho Identity Commandments.

I have been trying to find a way to express my concept to others who might be thinking of similar things. I did some research recently and found this site and this site refer to a list of use-cases that people would generally like to see in a system that conveys identity.

I made general enquiries to these groups and someone from the second group got back to me. They directed my attention to the Jericho Identity Commandments and invited me to answer this wish list with solutions as I saw them in terms of Clique Space.

You can view my answers here.

Note also that I'm going to try to publish newer versions of this document when (or if) I receive constructive feedback from people who read it. That feedback could be from you. Your name could end up in the table of changes, or I will certainly honour your wish not to publish your name. Let me know.

Pulse

In deliberating how Clique Space(TM) aware devices (Agent Devices(TM) and other Client Devices(TM) capable of generating viscera Participants), I had to entertain the communications method (synchronous/asynchronous) by which knowledge of state is spread amongst a subset of all Client Devices which are members (or subscribers) to any given subscription.

I have arrived at the notion that a subscription needs both synchronous and asynchronous communication.

A cluster of devices comprising a subscription dynamically grows and shrinks, but any given subscription is managed by a single device known as the given subscription's possessor device. The possessor may cede its authority to another device (this is theoretically though not currently possible), but for any subscription to maintain a stable existence, a subscription must have a single possessor which is known to be the possessor by all other subscribers.

A subscription grows by acquiring subscribers and shrinks by discarding subscribers. The possessor is the first member of a newly created subscription, and the last member of a subscription before it is destroyed. In having this special position in a subscription, the possessor is also responsible for coordinating the synchronous component of the subscription - its pulse.

At set intervals, an instance of the possessor's "pulse motor" emits a pulse message that spreads first to the possessor's nearest subscribers (those with whom the possessor shares synapses with). This pulse message is then relayed in turn to further distant subscribers until every subscriber is informed of the pulse. The pulse contains information about the state being subscribed to, the subscription's membership, and the length of time to wait for the next pulse.

As soon as a subscriber relays its pulse message, it sends a pulse reply. Each pulse reply reverberates around the subscription so every subscriber device knows that every other subscriber device has received the pulse message. This information helps every subscriber device determine whether they want to remain in the subscription or whether they wish to invite or remove other devices.

Updating the subscription's membership is the asynchronous component because any subscriber can assert the addition of any non-subscribing device, or the removal of any currently-subscribing device at any time. These messages, called "assertions" are remembered for between one and two pulse intervals.

The possessor decides whether an assertion will succeed. If this happens, the subscriptions membership will be updated. If the assertion was a member addition, the given subscriber will receive the next and subsequent pulses unless or until another assertion to have it removed succeeds. If the assertion was the removal of a member, the subscriber relating to the assertion will not receive the next or subsequent pulses unless or until another assertion to have it added succeeds.

So, subscriptions have both a synchronous and an asynchronous component, and both these components are vitally important to maintaining a stable cluster of devices which are observing some phenomenon.

Chasing... no following leads.

That's what thinking is about.

When you are searching your mind, when you are finding a solution to a problem, when you are thinking about anything, you are moving through the landscape of facts following leads which appear interesting.

I've created a structure; an abstract class called Lead which is extended into two final classes: PrincipleLead and LimitingConstraintLead. Both classes implement a variation of the verb "to follow": PrincipleLead::follow(Class<q>qualeType) and LimitingConstraint::follow().

Very interesting... Although I wanted to get CliqueSpace(TM) to function in this way, I didn't have any leads on how this might be done in 2004. I've followed many leads since then.

Does it work yet?

Ooh ahhh!

About 4 minutes ago, I just believe I finalised the architecture that is used to engage an administrator client, and have hence, all but filled out the body for the same architecture to enable two Agent Devices to engage.

There is still much to resolve around co-ordinating message transmissions, but I believe this is a very important milestone in the implementation.

It all cometh together right here?

With the following line in LimitingConstraintMessage::addAfterReceive...

• lc.addSourceSubscriber(su,subscriber);

I wonder if Clique Space(TM) is reaching some level of robustness. Although not tested, this line currently promises to remove the final clouds of mystery from a practical realisation of the concept.

An in-principle solution for robust device agnostic engagement.

I think I have been pondering this for several years since I dreamt up the "subscriber" mechanism as being a solution that will facilitate the establishment of "synapse" channels between Clique Space aware devices.

Today, I formalised what I think is a robust mechanism that uses structures developed over this time. The mechanism was seen through murky waters until I had finally developed the necessary data structures to carry it.

It is summed up by the diagram below.

 

The diagram shows two Clique Space aware devices (Client Devices - I'm beginning to saunter up to an earlier nomenclature that seems to have recently become more appealing, but possibly more on that in a later post).

The initiator, labelled as the upper rectangle and the respondent, labelled as the lower rectangle. The initiator can be any Agent Device. The respondent can be any Client Device (a Clique Space aware device that can participate in viscera, including Agent Devices and administrator clients).

Furthermore, the diagram shows how these Client Devices engage; how they establish their synapses; how they establish and communicate the Participants within each synapse.

The diagram can be further summed up by this slightly more formalised list, indicating which Participant is created at each stage of the process. The numbers coincide with each of the circled numbers in the diagram above.

1. Initiator : Owner : Inbound : Create.
2. Respondent : Owner : Outbound : Reconstituted from 1 as parameter.
3. Respondent : Owner : Inbound : Create.
4. Initiator : Owner : Outbound : Reconstituted from 3 as parameter.
5. Initiator : Non-Owner : Outbound : Create.
6. Respondent : Non-Owner : Inbound : Reconstituted from 5 as return.
7. Respondent : Non-Owner : Outbound : Create.
8. Initiator : Non-Owner : Inbound : Reconstituted from 7 as return.

The Owner/Non-Owner distinction signifies the role that a given participant plays in the synapse being modelled in a bipartite Clique. The Clique is bipartite because it is modelling an engagement between two Client Devices.

The Inbound/Outbound distinction signifies the perspective each device has to the two channels. If, for example, a Client Device A is engaged with Client Device B, then the Inbound channel on A is the Outbound channel on device B. In this way, the synapse Cliques model directionality of both synapses between the two devices.

In all instances where the two engaging devices are both Agent Devices, Participants which are created by a device are possessed by the device. In instances where an Agent Device is engaging an administrator client (I'm thinking about calling this an administrator device), all Participants are possessed by the Agent Device.

So, the device initiating the engagement (possibly, but not exclusively through the engager server's "engage" method), firstly creates the Owner of its inbound channel. The process that completes an engagement as a respondent is then called by the initiating device on the responding device where the respondent first reconstitutes the owner of its outbound channel using the signal given to it by the initiator, and then creates the owner of its outbound channel. Next, the respondent asks the initiator to complete its engagement. The initiator first reconstitutes the owner of the outbound channel from the signal given to it by the respondent, and then creates the non-owner of the same channel. When the engager finishes, the respondent reconstitutes the non-owner of its inbound channel using the signal that is returned, and creates a non-owner for its outbound channel before the respondent process completes whereby control is returned back to the initiator. Finally, the initiator reconstitutes the inbound channel's non-owner using the signal that is returned.

Now, to implement...

Robust disengagemt? Hmmm...

As of about one and a half hours ago, I've been able to disengage one administrator client from one Agent Device. The question now is: is this operation sufficiently generic to disengage more than one administrator client from one Agent Device, and furthermore, is this operation sufficiently generic to disengage two Agent Devices.

The first answer is: yes! It appears that an Agent Device can engage and disengage multiple administrator clients. It does not appear to matter whether these engagements are simultaneous. Additionally, one administrator client is able to simultaneously engage and disengage with more than one Agent Device. All of this is an intention designed from conception in mid-2004 to make Clique Space(TM) useful.

The larger question of engaging two Agent Devices should be answered in the next revision. It is hoped that once two Agent Devices can robustly engage and disengage, then the proposition of constructing neural clusters of Agent Devices might be seriously considered.

It works?

A Clique Space(TM)  device appears almost to function as a quasi-autonomous agent. There is, however, one obstacle: the disengagement operation.

I've discussed this subject before in past blog entries. Any two devices that engage must necessarily disengage, but disengagement is not engagement in reverse. Instead, the process by which two devices engage each other is a process whereby structures that synchronise both (two synapses, two corresponding postsynaptic subscribers) are created; disengagement is a process where these structures are destroyed. There is no symmetry beyond this obvious necessity.

In the creation of a synapse, the two devices must synchronise the state of each other's postsynaptic subscribers created for this engagment, and this synchronisation must continue until both devices have disengaged whereupon these postsynaptic subscribers are destroyed.

I believe I have a fairly robust solution for engagement. Although the same cannot be said of the disengagement, maybe I am almost there...

Generic beauty.

I think I did something today that I might just label the "end of the beginning" for development activity on the CliqueSpace(TM) core implementation.

Something appeared finally to vault the generic structure: I discarded the notion of a "root" profile. Instead, I made the Participant implement the Media and Mode Profile's interfaces.

Many problems appeared to dissolve... perhaps.

It Works! Part 1.

Finally, after 6.5 years of coding, Clique Space(TM) works... kind of.

But that's right... it does indeed do something non-trivial. An Agent Device will now engage and disengage one or more administrator clients. I just got it working... not more than 20 minutes ago.

The synapse: works.
The service: works.
The subscriber: works.
The subscription: works.
The context: works.
The payload: works.
The transmitter: works.
The device: works.
The signal: works.
The Element: works.
The principle: works.
The root profile: works.
The Participant: works.

These components comprise most of the implementation of Clique Space's real-time manifestation mechanism. This mechanism (for Agent Device - administrator client engagements only): works.

Now, I've gotta get two or more Agent Devices to engage themselves over a Sovereign's Clique Space. That is, I've got to get Agent Devices to form neural clusters based on a secret that is never shared between devices called "That Which is Sacred"(TM... perhaps?) - the Clique Spaces that manifest Sovereigns, modelled in a Clique(TM) called the Viscera(TM).

After that, I'll:

1. try and get two or more Agent Devices from different Sovereigns to engage each other in a "Congressional(TM) (formerly known as an Agent Collaboration) Clique Space.
2. try to make devices more robust and able to reconfigure engagements in adverse environmental conditions.

I think that the real-time reconfiguration under adversity is really going to take some time to nut out.

To the viscera and beyond...

.. gotta love all this TM'ing. Well, it is mine, so mits off!