Friday, November 24, 2017

Is the Realm necessary?

Changes pursuant to implementing the concept of the Clique Space trinity from the last post have led me to a contradiction that I believe can be completely resolved by doing away with any explicit reference to an Element's Realm via a principle.

As I can recall, Realms were once known as Clique Spaces. I re-named them in part because they could conflict with the use of Clique Space as a trademark. I assert that Clique Space is a trademark to this day. However, the implementation of the Realm concept as a property that can be held in thought as a distinct quale in a principle and communicated as a surrogate in a signal has been looking a little artificial for some time.

This artificiality has been lingering because a while back, I noted in an earlier blog entry the need for one Client Device to be able to communicate to another a sacred quality of belonging to an individual. If the other Client Device was from the same individual, that other Client Device would be able to sense that the communication was from self; representing a unit of cognition from the individual manifest. This was handled by an (as yet currently unimplemented mechanism) where a signature was steganographically embedded in the containing Element's identifier. To a pair of co-sovereigned Client Devices, this signature would be plainly evident while to a pair of contra-sovereigned Client Devices, each would be speaking to the other about quale contained in Elements that, if they even possessed some type of signature mechanism, this mechanism encoded its messages using an unknown cypher.

When, as described in my previous entry, three singletons became one, the Sovereign became the Sovereign's Realm and hence a member of the Realm's viscus; a visceral Participant. However, the Client Device nature of this singleton "trybrid" also acts as a synapse's Participant. A Client Device creates two new synapse Participants every time it engages with another as an initiator; it assigns one Participant to itself as the Owner of the synapse, and the other to its interlocutor as the non-Owner.

So, what is it going to be? Is the Sovereign going to be a Realm and generate a realm surrogate to communicate this fact, or is the Sovereign going to be a Client Device and create synapse Participants every time it engages? Clearly, it cannot be the latter which goes.

The Realm (as Clique Space) was an observation I made about my ideas soon after they were conceived in 2004. I observed that my ideas described the interactions of individuals, and these individuals each had a sphere of influence (a Clique Space or a Realm). At the time I conceived the idea, I also noticed that each individual may bare an Affiliation to one or more collective entities, and I also thought that a degree of collectivism could be expressed in the notion of Realms. All of this was still very opaque; I had conceived a mechanism in addition to Realms that had two hierarchies: one composed of Media Profiles that describe physical aspects of devices (including Client Devices) through Connections and another composed of Mode Profiles that describe assertions through Affiliations. The Affiliations and their constituent Mode Profiles have been removed. It looks like the realm as an explicitly named component of the implementation should go too.

So, time and continued application of effort have seen an evolution of the concept where whole structures have dissolved. A single hierarchy can be used to describe not only physical characteristics of devices, but can also be used to assert membership to and function within organisations. Realms are removed from the implementation because the phenomenon of the manifest individual is realised through the steganogaphically signed Element identifier.

Thursday, November 23, 2017

The "holy" trinity.

This entry is primarily about how I have observed a pattern in the code, and the re-factoring I have done as a result, but it might also perhaps be an observation in how religion (Christianity in this instance) makes chew toys out of similar patterns.

I have observed that the Sovereign's Realm, the Client Device, and the Sovereign itself all exist as singleton objects. Hence, I have simplified the implementation by aggregating them all into the same singleton. It is a simplification that was not apparent to me in 2004 when I conceived Clique Space (TM), but it is apparent to me now, and so this record stands as testament to the models evolution.

I liken this Clique Space trinity to the "father" (the Sovereigns Realm), the "son" (the Client Device) and the "holy ghost" (the Sovereign), although there is probably no significance in this relationship because religion is fairy tale used by people to temper their fear of living in a capricious universe of unfathomable complexity.

Perhaps the Identity is the son, but I guess the correlation is trivial; perhaps others will be in a better position to explain this apparent coincidence if there is anything to be explained.

Tuesday, November 7, 2017

What is the singular term for "glia"?

I am entertaining a dilemma which I will answer conclusively in this posting.

As Clique Space(TM) continues to evolve, the necessity for delineating between neurons and other related cells (I have called them glia in previous posts because of what seems to be a structural necessity that for as aware of neuroscience (no spell check - not pseudoscience) as I am not, seem to be similar to glial cells.

My code-base consists of five projects. One of these five projects is called "GlialDevice". I don't like this - it's too long and clashes with another project (the base project) called "ClientDevice". Being that I am designing GlialDevice to encapsulate all the necessary behaviour of any glial device, I want this project and the common behaviour it represents to stand as an idealised Client Device.

There is a need, however and especially within the Neuron project, to refer to a specific glial device without having to be concerned about the specific glial device's function. Hence, I need a label (indeed an abstract noun) that allows me to indicate that I am talking about a specific glial device even though I am not concerned with what that device specifically does.

I have decided the following: this project's name will remain the same. However, when I need to refer to a specific glial device instance (an example is when a Neuron is engaged by a glial device), I will use the term "glion". Now at least one publication has protested the use of this term; but I am not concerned. I am going to henceforth use the term "glion" to describe an abstract instance of a glial device, and such a label will be used in my code whenever such a need arises.

So, some examples of the use of this label are: 1. a Neuron will be engaged by a glion, 2. a glion can act as an initiator in an engagement, and 3. a glion can observe, but cannot participate in cognition.

Sunday, September 24, 2017

Refactoring and some name changes.

I've decided to change more names.

The Agent Device is now known as the Neuron. The capitalisation is intended to convey that all that has happened here is that an existing concept in the patent has merely been given a different name because after some deliberation over these years, I have finally decided to run with my intuition and give this beast the name I think is obvious.

The administrator client (without capitals because I believe the mechanism wasn't an accurately described part of the original patent) has actually been split into two projects. The first, called the "glial device", is believed to have function similar to what neuroglia in our nervous system possess. These type of Client Devices can receive messages and send challenges (explained in a previous blog entry somewhere), but cannot themselves contribute to the cognitive function of a given Clique Space(TM) because they cannot send messages and receive challenges. These Client Devices are rather more observers to the activity which is primarily mediated by the Neurons. The glial device is abstract; it contains the engagement logic necessary to behave like a glial cell should.

The second project is tentatively called the "renderer" does what it might suggest to the reader: it renders all the Clique Space components (Elements and Cliques) in a nice graphical context known in the patent as the View. Although very little has been implemented, recent thoughts directed to the presentation seem to have kept the original intentions largely intact with one current exception: a Clique and its collection of Participant Chips will not (currently at least) have a bounded ellipse. The implementation of a bounded ellipse turns out to be out of my capability. I don't know too much about matrices or coefficients or parametric equations to really make sense of the bounded ellipse; I thought a bounded circle (which I had found an algorithm that worked) would be something I could use, but then I just thought that having an unbounded tessellation of Participant Chips itself indicate the Clique to which they belong would be enough for now... maybe this will be enough for ever but I'm going to see how things work with this idea before I commit to any measure of permanency.

Oh, I'm still here... yay!

Saturday, April 8, 2017

Agent Devices are neurons and Administrator Clients are glia.

I'm still here. Doing Clique Space (TM). Drip drip drip.

The pattern seems almost too obvious to actually use, but I suppose I am reaching a state of comfort that might permit another name change.

Agent Devices manage, coordinate, and ultimately implement the dissemination of state within and between Realms. Agent Devices create two synapses when two instances of an Agent Device engage each other. Agent Devices can send and receive message and challenge signals. Agent Devices must be neurons.

Administrator Clients observe the flow of state. Administrator Clients create a single synapse between themselves and the one or more Agent Devices with which they are engaged. Administrator Clients can only receive message signals and send challenge signals. Administrator Clients must be glia.

If usage of the terms Neuron and glia become common place in future blog entries, this will have been because they have replaced the terms Agent Device and administrator client respectively. Neuron will always be a proper noun while glia will be common and therefore will not be capitalised when used in a sentence anywhere else than as the first word.

Glia represent undifferentiated support cells and hence my usage of the term is in this sense, even though administrator clients are a specific type of glial cell. The term administrator client may still have use when I have to craft glial cells that serve other purposes. Maybe the term administrator client has outlived its usefulness; I think I might instead opt for a single monosyllable like "probe" being that I seem to be gradually crafting this Client Device (I might yet keep that term in reference to both glia and Neurons) to provide real-time information on a Clique Space neural cluster.

Maybe the best I can hope for is to put this on GitHub, but I haven't come to that conclusion yet.

Wednesday, November 23, 2016

Even More Robust Engagement

This morning, I managed something that I hope will be somewhat significant. When two Client Devices engage each other, each Client Device creates something called a synaptic channel. Client Devices use these channel structures to send messages to and receive messages from each other.'

Up to now, I had two message types: 1. a channel's message which was sent between two co-engaged Client Devices to let each other know that they are still interested in maintaining the engagement (one device has to send a channel message to the the second one before a cycle interval lapses, or the second assumes the first has lost interest in remaining engaged and hence destroys its channel) and 2. a subscriber's message which allows co-engaged Client Devices to communicate general state information. The second of these two message types had yet to be used.

I didn't like the channel's message. It separated the process of keeping channels open from the communication of state, and I didn't like this fact because the Client Device engagement is state information, and having the notion of engagement handled by a separate message was a complication that obstructed the implementation of an efficient way to relay state through a cluster of Client Devices. The channel's message was a good stop-gap way to get the Client Devices to work in a way that would be analogous to they way they would finally work while some of the background necessary to this final behaviour had yet to be developed. Now that the background has been developed, the time to remove the channel's message is upon me.

By removing the channel's message and using the subscriber's message for channel mechanics as well as general device state, I think I have come up with a near-final overall system for the representation and the communication of state. Hence, sate information as well as channel mechanics should now be handled by a single message - the subscriber message. Furthermore, the subscriber message can now be known merely as the message.

To make this feat possible, there is a very complicated structure and mechanism that culminates in the exchange of delegate Connection Limiting Constraint signals as the final part of the Client Device activation process. The channel of each of the two Client Devices currently in the process of engaging is finally activated when these signals are first exchanged, and continues until one of the devices detects that the other has not sent a signal before the channel's cycle interval lapses.

The code below, is a selective quote of the subscription's subscribe method. Limiting Constraints extend subscriptions, so this method applies to Limiting Constraints by virtue of this extension.

public final void subscribe(PostsynapticChannel channel,OutboundConnection subscriber)throws CliqueSpaceException{

    /*Uninteresting code removed.*/

    SynapseOwnerParticipant pIn=channel.getInboundSynapse().getOwner();
    LimitingConstraint lcIn=pIn.getLimitingConstraint(ClientDeviceMediaProfile.DELEGATE_CONNECTION);
    boolean cycleIn=this==lcIn;
    SynapseOwnerParticipant pOut=channel.getOutboundSynapse().getOwner();
    LimitingConstraint lcOut=pOut.getLimitingConstraint(ClientDeviceMediaProfile.DELEGATE_CONNECTION);
    boolean cycleOut=this==lcOut;
    OutboundConnection c=channel.getOutboundConnection();


            throw new Subscribe_FirstCycleSubscriberNotOutboundConnection();

        /*Uninteresting code removed.*/

    }else if(cycleOut&&c==subscriber){
        ChannelAdviser ca=channel.getChannelAdviser();
            throw new Subscribe_ChannelAdviserDoesNotExist();

        int ci=channel.getDrive().getCycleInterval();
            throw new Subscribe_CycleIntervalNotSet();

                throw new InterruptedException("Cycle interval exceeded; other Client Device is probably unresponsive.");
        }catch(InterruptedException ex){
            throw new Subscribe_CurrentAdviserHasBeenInterrupted(ex);


The method starts by ascertaining whether this subscription is a delegate Connection's Limiting Constraint to the synapse Owner Participant of either the given channel's inbound or outbound synapse, and sets cycleIn or cycleOut to capture the result of this interrogation. Next, the given subscriber is added to the set of subscribers known to have expressed an interest in this subscription.

The if statement combines the values of the earlier defined flags with the role the host is playing in the engagement process to determine whether or not the channel needs to be activated. To clarify the necessity of requiring the channel's methods isInitiator and isRespondent, the following code snippet shows how these methods work.

public boolean isInitiator()throws CliqueSpaceException{
    boolean isInitiator;


    return isInitiator;

public boolean isRespondent()throws CliqueSpaceException{
    boolean isRespondent;


    return isRespondent;

When the two devices are engaging (before the channels have been activated) each device is assigned a role; the device that started the engagement process is known as the initiator and the device that is responding to the initiator's engagement request is known as the respondent. These methods will return true for a particular associated role while the two devices are in the process of engaging. They will return false regardless of which role a host took in the engagement process after the engagement process has finished (when the channel has been activated), and the two devices are merely cycling the delegate Connection's Limiting Constraint messages so to keep the channel open.

Hence, the if part in the first code snippet will only be executed once on each Client Device for a given engagement process. One observes the call to the given channel's activate method, a call that is made once only for each engagement. The activate method sets the channel's isInitiator field to null.

In the else if block of the fist code snippet, one can observe that the previous adviser thread (a thread which advises the co-engaged Client Device of this host's interest in keeping the channel open) is retrieved. The first adviser's thread is created and started in the given channel's activate method. The current thread only has to wait for the cycle interval to elapse before it moves on - waiting longer than this will be useless because the channel will have been closed, and one would want to prevent the possibility that a hanging adviser hangs the current thread. The channels's drive is a thread which sleeps for the cycle interval, and is reawaken either by the expiry of this time, or by interruption. In this case, the drive, which should still be waiting for the cycle interval to expire, is interrupted by the current thread as the final action of this else if block. This else if block implements the to and fro mechanism that keeps a channel open because the drive, when interrupted, sets off a small train of processes which results in the delegate Connection's Limiting Constraint of the channel's inbound synapse Owner Participant to be transmitted to the other Client Device.

The mechanism still requires perhaps a little more development. I do fear that there remain some cases that are not covered because, again, there remain many unexplored use-cases which would have a bearing on this mechanism. Even though perhaps I might think this mechanism could very well be a culminating result of eight years and about four months of development of a concept which is more than 12 years old, there is yet more deliberation to come though possibly this is a stand-out moment in time for the development of Clique Space(TM).

Monday, October 10, 2016

Steganography: a method of identifying Elements signed by the Sovereign

Yes... I'm still working on it. I am a love slave to this Clique Space(TM) thing.

I've been thinking about how one might "digitally sign" an Element so that when it is transmitted amongst Client Devices, that subset of Client Devices which know the same Sovereign can automatically detect that this Element represents cognitive activity of the individual thus manifest. By gosh, the answer appears (currently) to use something called a steganograhical signature. Such a signature is buried within what to the uninformed Client Device appears as an identifier string made up of random bits, each as trivial as the next.

When a Client Device receives a surrogate, it attempts to extract the signature steganographically buried in the surrogate's identifier (perhaps a symmetric key derived from the Client Device's Sovereign) and if it is successful in this task, it subtracts this key from the identifier, reconstitutes the given Element with this difference as its identifier, and stores the Element inside the Sovereign as Elements known to represent the individual manifest by the Sovereign. If the Client Device is unsuccessful, the Element is reconstituted without translating the identifier, and the reconstituted Element is not added to the Sovereign.

When a surrogate needs to be created again, the identifier of an Element not added to the Sovereign is merely copied to the surrogate. However, the identifier of an Element that is known to the Sovereign will be steganographically signed, and the surrogate will be created using this signed identifier.

The signature is buried in the identifier's seemingly random bit pattern, and hence the identifier is also the instrument of authentication to each of those devices "in the know" (possess the same Sovereign). There is no need to transmit a separate signature with the identifier, and so, given a sufficiently strong steganographical scheme, identifier authenticity could never be repudiated.