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 Clique Space.

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.

Thursday, May 26, 2016

Hmmm... a relatively curious bit of code...

At approximately 8:25am AEST on Saturday 28 May 2016, I wrote the following code:

public void execute(PostsynapticChannel channel)throws CliqueSpaceException{

    Identity author=this.authorSurrogate.asQuale();

    // The receiver's identity will always be signed by this Client Device's Sovereign.
   Subscription su=this.subjectSignal.asSubscription(


This particular code, comprising the non-trivial part of the SubscriberMessage's execute method will dispose of a subscription, created or retrieved from the signal disclosed in this subscriber message, if the carrier's contemplate method returns false.

The subscription's carrier is the object that contains the subscription. The carrier will be the subscription itself if the subscription is an Enabling or Limiting Constraint, otherwise (if the subscription is a principle's subscription), will be the principle that contains the subscription. Principles convey specific information about the specific context represented by the subscription. Principles are customised by Media Profile vendors to create subscriptions that exhibit a certain behaviour.

The carrier is a very important structure because it provides the opportunity for the subscription to behave in ways that are appropriate for the specific subscription. It is like providing for a mechanical system the opportunity to think in ways that are as diverse as say, thinking about what to do about having a drink versus the visceral feeling of having a thirst that needs to be quenched. While both of these are the products of neural activity, the first is a product of cognition that needs to be remembered so that the physiological arousal given in the second example can be meaningfully satiated. Once the urge is satisfied, its accordant state can be forgotten, without forgetting the cognitive process of quenching one's thirst.

Hence, a carrier can treat its subscriptions according to that carrier's particular function; does that carrier remember something about how to quench one's thirst, or does the carrier perhaps provide something toward the arousal of thirst. Both carriers are necessary cognitive facilities in the individual, and both have their own particular contexts. The contemplate method customises the carrier's behaviour in relation to this context. Principles hence implement the contemplate method with appropriate behaviour.

Monday, February 8, 2016


About an hour ago, I finally got three Client Devices (two Agent Devices and an administrator client) to maintain three sets of stable synapses between each other.

I'm going to go to my Alma Mater to have a go at selling my idea tomorrow. Maybe perhaps someone will be receptive to what I've got to show.

Thursday, January 7, 2016

Still here.

I'm still here. Still getting this Clique Space(TM) thing to work.

However, I fear that the things I'm working on at this point in time are not protected by my patent. They feel significantly different to the scheme published in the patents that I think disclosing them on this blog at this point in time would risk letting ideas escape into the public domain.

The patents (3 of them covering the Australian, US and New Zealand jurisdictions) talk of what components would need to form the bases of a real-time communications medium capable of representing individuals as a collection of devices that each operate. These patents form the shell of the idea.

I feel that the development of these ideas has created mechanisms that go deeper than the shell of these ideas; that I have penetrated this shell into the soft inner form to which I had only faith in the shell's containment as a guide.

I had faith because I had no idea of what was within when I put my ideas to a patent. I thought the ideas disclosed a simple system; maybe it is a system that is too simple for me to comprehend. Although I am now navigating a world where contingent ideas to those disclosed in the patent dominate, my faith hasn't wavered yet. I guess I might never finish. I may chase my tail to my end.

Thursday, September 17, 2015

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.

Monday, September 14, 2015

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.

Thursday, September 10, 2015


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.