tag:blogger.com,1999:blog-48536448985629348262024-03-25T07:06:25.815-07:00Owen's garden of thought.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.comBlogger214125tag:blogger.com,1999:blog-4853644898562934826.post-54104634844975124302023-12-10T20:47:00.000-08:002023-12-11T03:52:55.509-08:00Okay. Here's something to describe my intentions.<p>This might be interesting. This code below discloses the mechanism in Clique Space(TM) by which a deliberation and one deliberator is created when a deliberation's sense datum is received via transmission through a synapse.</p><p><span style="font-family: courier;"> <br /><span style="font-size: xx-small;"> public<_SYN extends Synapse<_SYN,?,_P,?,?,?,?,S,I>,_P extends SynapseOwnerParticipant<_SYN,_P,?,S,I>>void internalise(int distance,_P owner,KeyQuale<S,I>key,boolean isAffirming,long ordinal,byte[]signature)<br /> throws CommonDilemma{<br /> var t=Fielder.<_SYN,S,I>currentFielder();<br /> var y=t.currentSolution();<br /> <br /> if(owner==null){<br /> throw new Internalise_OwnerNotGiven(y);<br /> }<br /><br /> var dMap=this.deliberations;<br /> synchronized(dMap){<br /> var d=dMap.get(ordinal);<br /> <br /> if(d==null){<br /> d=new Locker<Deliberation<R,S,I>,DeliberationQuale<R,S,I>,S,I>(t){<br /> @Override<br /> protected Deliberation<R, S, I> processInternally() throws CommonDilemma {<br /> return this.acquire(Subscriber.this.asQuale(key,isAffirming,ordinal,signature)).subcontent();<br /> }<br /> }.process();<br /> <br /> dMap.putIfAbsent(d.ordinal(),d);<br /><br /> new Deliberator<>(t.sovereign(),d){<br /> @Override<br /> protected FirstSolution<Deliberator<R,S,I>,S,I>firstSolution() throws CommonDilemma {<br /> return Subscriber.this.container().container().first(this,owner.getSynapse(),distance);<br /> }<br /> }.start();<br /> } //TODO: Else check the key, isAffirming, ordinal, and signature fields correspond...<br /> }<br /> }<br /></span></span></p><p>The code is an extract of the subscriber's "internalise" method, called by a fielder when the fielder is processing the collection of deliberations that reside in each transmitter of a set of transmitters that have been received from other Peers. Unlike the internalise method of a sense datum, this method also receives the Owner Participant of the synapse and the distance - the number of Peers that this deliberation sense datum has passed through before being processed - from this Peer.</p><p>The currently running fielder is retrieved and stored in the variable named t, the current solution being executed by the fielder in y. Housekeeping ensures no arguments capable of being null are indeed null.</p><p>The collection of deliberations associated to this subscription (assigned to the automatic variable dMap) is a shared resource, and hence is locked so the current fielder has exclusive access to it.</p><p>The uninteresting bit (the false branch) of statement that tests whether dMap has an entry that corresponds to the ordinal argument remains unimplemented; I have just written a comment to check that various variables correspond as I intend to put some code in later to do this.</p><p>The true branch (when there is no corresponding deliberation associated with the given ordinal) creates a new locker. This locker is used to get exclusive access to the Peer Device's quale container. The processInternally method can execute once the current fielder has access to the quale container so that it can call asQuale - creating a deliberation and its backing quale. The backing quale is acquired by the current fielder and its subcontent (the deliberation) is assigned to the variable d and added to dMap.</p><p>Lastly for the true branch, a deliberator is created using d and started.</p><p>******</p><p>So, what's going on here you may ask.</p><p>The running instance of the Peer Device has received a deliberation's sense datum that it hasn't yet encountered. In response, it creates the deliberation, and, by creating and starting a deliberator with the newly created deliberation, has now a chance to understand what it might need to do next - a process which will depend on the implementation of a specific set of methods called from the implementation of the "first" method for a class called the predicate.</p><p>The predicate is a component of the class generically referred to as the resonance, accessed by the call to the "first" method (the subscriber's container's container) appearing in the code. Manufacturers or other parties interested in creating a Peer Device instance for a specific type of hardware or software device would craft their own predicate and supply an implementation of these methods.<br /></p><p>This is the intent of Clique Space. I believe one can build a network of cooperating Peers (indeed, a "neural" network) of arbitrary complexity using my Clique Space system architecture at its core.<br /></p>Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-46625845269693751122023-10-22T02:30:00.000-07:002023-10-22T02:30:15.400-07:00Inflection.<p>Perhaps this point was passed today when apoptosis was triggered only after the subscriber was instantiated, perhaps it was passed on Friday when I put in the code that I managed to get functioning today.</p><p>Hence, after either today or Friday just gone, I believe that I will not be bringing into existence any more structure that is required for the vision I had for Clique Space in 2004, but that rather, I will be building on existing structure - cleaning it up and making it robust.</p><p> Time will tell... <br /></p>Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-89545134178477188892023-10-01T22:57:00.000-07:002023-10-01T22:57:43.988-07:00A date perhaps.<p> I just completed some complicated parameterisations. I thought this might be a date to remember. As with everything, time does tell...</p><p>It is interesting to think that in early July of 2008, I started working on an idea that might only just five minutes ago have been realised. I thought it might take me two years to get here.</p><p>Funny that. <br /></p>Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-78274540360624879792023-07-28T16:50:00.000-07:002023-07-28T16:50:13.603-07:00A letter I wrote yesterday.<div>Thank you again for the time you provided me. I apologise if you
think it was wasted. I hope you don't think this. Clique Space of course
is the product of the best I can do. Googling "Owen Thomas Clique
Space" should demonstrate a presence: I
have told you about my ideas, I have code, I have a blog, I have other
published material. I have left a footprint in this world. I would like
this world to recognise me for leaving this footprint before I go. I
would like to think I lived among people who might have done their best
to help me develop my ideas, and if on the odd chance they were worth
anything, to assure I would be, as anyone might rightfully be,
recognised for having them before they died.<br /><div><br /></div>I really
do hope Clique Space isn't picked up after I'm dead; I do not want
posthumous accolades - everyone hates the thought that they might be
ignored by others only to receive recognition after one's opportunity to
capitalise on it had passed. That thought does not encourage people in
general to do things like I'm doing. Posthumous recognition is not the
point to all this.<br /></div><div><br /></div><div>I hope that if you have
truly spoken to anyone about our encounter, and they have reported any
intent in getting in contact with me, you may remind them that they
really would be doing nothing wrong if they were to act on their intent.
I can confidently say that I have no idea whether you, me, people you
have spoken to about me, nor anyone else truly knows whether my ideas
actually amount to anything right now. <br /></div><div><br /></div><div>If
the people you have spoken to think they know what I'm doing, and if
they think it has already been done, then, if I had time to speak or
write to them, I could find out if their opinion was given from a
position of authority. This is much better than silence.<br /></div><p> </p>Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-27882346613464206302023-05-14T04:23:00.002-07:002023-12-11T20:02:01.402-08:00It's been a while, and yet...<p>I am still here.</p><p>The POC is still evolving. Perhaps recently I have managed to get it to do something that some imaginative venture capitalist might consider relevant: a cluster composing two or more Peer Devices will automatically engage a third or subsequent Peer when that device engages any one of the devices of the neural cluster.</p><p>This is something I have been trying to do for god knows how long. Possibly for about the ten or so years since I conceived of the Synapse as the product of engagement.</p><p>Current developments in AI seem to suggest that such thinking (if that's what it can be called, then who am I to oppose this suggestion) machines still don't know themselves. They still don't know what it is to survive in a world that wants to destroy them.</p><p>Clique Space can say something about this. It has the concept of Sovereignty built into it at the very base. A Clique Space cluster can only contain co-Sovereign Peers. Each and every Peer of a co-Sovereign cluster knows intuitively that they belong for they understand "that which is sacred", and they can intuit this from signals received and shared within the cluster.<br /></p>Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-53580241155173714932022-08-29T07:48:00.000-07:002022-08-29T07:48:08.907-07:00Messages and challenges have nothing to do with initiators and respondents... or do they?<p> Very recently (in the current indefinitely time-boxed sprint) I have decided that messages and challenges (or, as I had less recently as in the sprint just prior to the current sprint - according to the change log of my Git code base it concluded yesterday) no longer have structural relevance. What I mean by this is that there are no components (classes or methods or anything else) that go directly to defining a particular challenge or message component.</p><p>It is noted that signals that flow out of initiators and to respondents (deemed challenges) are identical to signals that flow the other way (deemed messages). The difference still does seem to have relevance, however, consensus appears to be settling on the notion that the labels used for the dichotomy can be dropped in favour of the use of initiator signals for challenges and respondent signals for messages. The difference merely being that initiator signals travel from initiator to respondent while respondent signals flow the other way. Being that there is no other great functional difference between these two signals (as was envisaged for several years up to now) the dichotomy no longer applied and was dropped.</p><p>Both types of signals are represented by the same signal object, save the only dichotomy now that seems still worthy of modelling: the one between constraints and contexts (nee features - another renaming that occurred about half a year or so ago). Hence, the same type of constraint signal that is sent from initiator to respondent is also sent from respondent to initiator; so for the context signal. Whether from respondent to initiator or the other direction, both types of signals contain indistinguishable information.</p><p>Or do they?</p><p>I am seriously considering setting a single bit: switched on for a signal sent from an initiator and off for one sent from a respondent. This single bit difference would yield a completely different digest or signature; one could not create an initiator's signal that was sent through a respondent's synapse. Perhaps better yet, the bit is stored in the serialisable deliberation that is generated from a non-serialisable deliberator. The bit is kept in the deliberator so it generates the appropriate signature for the correct receiving direction. The deliberation may not have to record the bit because it would be inferred by the receiver.</p><p>This is all quite deliciously speculative...<br /></p>Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-51932563852830082462021-10-30T16:23:00.002-07:002021-10-30T16:23:38.122-07:00Updates to some of the terms disclosed in the previous post.<p>Yes, I'm still here! I wonder what else happened around this time that might have made me not put up a post since May 2020. I don't think there was anything.</p><p>So, the topic of this post is to list and perhaps details rationale for some of the changes in terminology since my last post. So, here the are:</p><ol style="text-align: left;"><li>Client Device -> Peer Device<br /><br />This one is a rather big change. Client Device was a term used in my patent, and had survived unchanged among a turbulent wash of changes for a very long time. I think, however, the change is apt because these devices behave more like peers than like Clients.<br /><br />While it might be said that Glions can be thought of as clients to Neurons, Neurons certainly function as Peers among themselves. The word Device is often dropped in less formal discussion.<br /><br /></li><li>Marshaller -> Fielder<br /><br />The noun and verb "Marshal" was commandeered as the label around a new (or merely, a more crystalised) mechanism for managing sense data that cannot be reconstituted on the receiving Peer. Hence, after a bit of searching, the equivalently grammatical "field" was deemed an appropriate replacement; these acquirers take the job of collecting and managing deliberations from the motors (the coupling and receiver) so they can do their time constrained tasks can be completed without this burdon.</li></ol><p>It is hoped that the changes to terminology disclosed here will provide a good background to future posts - the next one of which I will try to get out very soon.</p>Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-55355790107602520752020-05-25T04:51:00.001-07:002020-05-29T19:24:45.141-07:00Deliberators cannot dispose of content!Hi everyone!<br />
<br />
Here again ruminating over more Clique Space(TM) cud. This time, it looks like, with the implementation fairly robust and the core concept seemingly all but proven, my focus seems to have naturally drifted toward working out how to dispose of content that seems no longer to be important to the Client Device.<br />
<br />
In Clique Space land, a Client Device - a Neuron or a Glion (see what I did there?) - needs to delete (the official term is dispose of) content (another official term) from its container (another official term) when that content seems to bare no purpose for continued deliberation (all these official terms...) and has to be removed so things do not pile up for the Client Devices. If content is created but never disposed of, the consequent memory leakage incurred by the poor Client Devices would eventually cause them to stop working. The unfortunate Clique Space neural network would fall apart, and no one would use Clique Space because it wouldn't do the thing it is supposed to.<br />
<br />
So, content that no longer appears to have a use (orphaned content like deliberatorless subscribers, subscriberless subscriptions, subscriptionless resonances etc) would need to be disposed of so to keep the Client Device from running out of memory. The trick is working with the edifice of the current implementation to drive this end wherever it may be.<br />
<br />
It seems like "this end" appears to me must be an expression of the phenomenological beast that Clique Space is. Secrets reveal themselves through this evolving hypothesis if one lets it speak. I am trying merely to listen attentively to what it is trying to say. I'm not a fast worker, yet I try to accept the ways of this Clique Space beast so to bring something I certainly cannot contain in my own mind to life in code. It has been nearly twelve years since I first glimpsed it; perhaps the mechanism of content disposal is one of the last major mysteries to slay before this phenomenological beast is finally manifest in any true form.<br />
<br />
So, the title of this post alludes to the mechanism I currently have in mind; deliberators are not the thinkers that can be responsible for disposal of content they might have created. The reason for this seeming logical maxim appears to stem from how they create and use content.<br />
<br />
Okay. Deliberators are a type of thinker called an acquirer. There is one other type of acquirer: the marshaller. The marshaller, like the deliberator, creates and "acquires" the content it creates. An acquirer needs merely to acquire content that already exists. Content acquisition is a necessary step in tracking when content has become eligible for disposal. The marshaller is different from the deliberator in the following way: deliberators represent streams of thought while marshallers underlie the synaptic mechanism that facilitates the exchange of deliberations about the world between Client Devices. A marshaller coordinates a synapse's inbound and outbound transmitters, and takes the processing load imposed through the reconstituting of deliberators from their deliberations away from the coupling and receiver thinkers. The coupling and receiver are the two thinkers (also known as motors) responsible for maintaining a synapse - they have to be quick: the interlocutor Client Device that initiated the engagement is impatient for more transmitters. A synapse is created when a given Client Device engages another. A Client Device may manage many synapses at a time because a given Client Device, being a member of a neural network, may be engaged with many of it's co-Sovereign kin at a time.<br />
<br />
So, perhaps the deliberator should not be the candidate thinker responsible for disposing content; perhaps the marshaller should do this. Although the marshaller itself creates and acquires content, it has a more cyclical nature than does the deliberator. The marshaller currently creates (creation implies acquisition) or merely aquires content before handing the task of deliberating this content to the newly started deliberator which has been created for the task of deliberating what the content implies. After all deliberators are created and started, the marshaller can then perhaps turn its task to disposing of any deliberators which have finished (another formal term that also includes engagement initiators and other types of thinkers including the anonymous respondent); in turn disposing of any nested content instances (subscribers, subscriptions, resonances or qualia) which are no longer the subject of any finisher (deliberator included) that has indeed finished. Perhaps a marshaller should only be responsible for disposing of content if a particular content instance, eligible for disposal, was referenced by a particular finisher created by that particular marshaller.<br />
<br />
Deliberators (as well as most other finishers) act in a linear fashion. They do some task (whether that be deliberation of a notion, or the establishment of a synapse, or something else that is relevant to the particular Client Device instance) while marshallers spin in circles - sharing time between tending to deliberations received from and to be sent to a specific interlocutor device, and disposing of content which is eligible for disposal. The marshaller seems like the natural place to perform content disposal as part of its cyclic nature. After the marshaller deals with setting up inbound deliberations, it sweeps through earlier started finishers, disposing these finishers and any nested content instances that are also made eligible for disposal as a consequence.<br />
<br />
Sounds promising...Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-91538455435805010662019-10-19T20:38:00.000-07:002019-10-20T04:41:23.806-07:00Another idea on the previous post...Something has occurred to me since my last post about where to implement the behaviour common to traditional neurons in the Clique Space(TM) Neuron.<br />
<br />
Currently, no weights, activation, bias, or other well known mechanism commonly seen in traditional neurons (with the possible exception of structure that resembles a Clique Space synapse) is currently implemented in the Client Device, or the Neuron as an extension of the Client Device. It currently seems too premature to implement any traditional neurologic within these two projects; it instead seems better to delay implementation to an extension of the Neuron that can handle specific device types and can also implement any variety of neurological mechanism chosen by the organisation that implements such an extension, or no mechanism at all.<br />
<br />
The Client Device and Neuron projects define the purpose and structure of qualia and Elements: Connections, Participants, Identities, the Sovereign - and all of their surrogates. The base protocol for the transmission of deliberations and their enclosed signals, as well as synapse and thinker structure are also defined primarily in the Client Device, but are extended in the Neuron to define similar structures that permit the transmission of messages. The Client Device uses the structure defined within it to facilitate the transmission of challenges only.<br />
<br />
The rationale of my conclusion is the following: a relay Neuron is a specific type of Neuron; it acts in a mere signal forwarding capacity. These Neurons don't contribute in any substantial way to cognition, and therefore don't have a need to be equipped with the mechanisms - the Connection weights, activation, bias etc. - that equip a neuron with a greater ability to participate in cognition. A relay Neuron can extend the Neuron without addition of functional structure. Relay Neurons do not inherit anything more than those mechanisms that make a relay Neuron do what it needs to do if traditional neurologic is not implemented in the Neuron.<br />
<br />
Hence, I think details relating to traditionally defined neurological mechanism can be reasonably deferred to the more specific types of Neuron that need these mechanisms.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-4541605447259921922019-10-18T19:03:00.001-07:002019-10-19T03:39:15.472-07:00The exploration of a new hypothesis on or about the neurocognitive connectome.It may all be bullshit, but thoughts over the past two days have led me down what I observe is an interesting garden path concerning the components of a Clique Space(TM) neural network and how a participating Neuron might conceive of itself and its neighbourhood.<br />
<br />
Traditionally, a neuron shares physical connections with a subset of its neighbours. Each of these physical connections is assigned a weight and any given connection is assigned a value for its weight based on a process of "learning". That has always appeared as a reasonable if not abridged overview of the neural way things are generally known in this world.<br />
<br />
I feel that I can give a slightly different slant on the above view. Clique Space is no different from this view in that Neurons indeed share similar physical connections (synapses) with a subset of their brethren; each connection is indeed realised through an algorithmic structure known as a synapse. However, what is slightly different is the following: weights are not assigned to synapses.<br />
<br />
A Clique Space Client Device (a Neuron is a type of Client Device) is identified individually by a Connection. Connections are Elements which contain one or more features that are expressed by Participants (also Elements) which are members of Cliques. Cliques denote some cooperative endeavour is being undertaken. Synapses are a type of bipartite Clique which models the engagement of two Client Devices through the "this Element" feature of their individual Connections.<br />
<br />
While a Client Device may not share a synapse with every one of its cohorts, it can still be aware of every Connection that makes up the entire population. Weights are assigned to the Connections known to a Neuron to represent other Neurons - even those Neurons with which the host Neuron doesn't share a synapse directly. Now, I think at this moment, there is an opportunity to do something
rather useful with this knowledge; something that uses another structure
developed over the past 11 years I have been working on my
proof-of-concept. This something appears to me to advance the
traditional connectionist model of neurons. Instead of assigning a weight to a synapse, weights are assigned to Connections.<br />
<br />
A deliberator is a thinker (a type of Java thread) which is created to deliberate the arrival of a deliberation. Deliberators are associated with the Connection assigned as the first Neuron (actually Client Device but we will not split hairs here) to have entertained the topic being deliberated. Now, getting hypothetical, the wonderful thing about creating deliberators in this way is that a group of deliberators may be created to represent receipt of deliberations sent from neighbouring Neurons all of which are received at around the same time. Apart from the difference in originator, each deliberator is cogitating the same topic and hence each deliberator is constructed to have a identical parameters such as activation and bias because all deliberators are instructed by the same feature.<br />
<br />
Accumulation of Connection weights for deliberators on this same topic may cross a threshold which when reached will cause the deliberator on which the threshold was crossed to send deliberations through synapses to its neighbours. Some neighbours may share synapses and may receive the deliberation immediately and others may only receive the deliberation through a neighbour who has faithfully passed the deliberation on.<br />
<br />
This is all done by assigning weights to the Connections instead of to the synapses. I think that is a big deal, and an advancement in neuroscience that was published in this blog entry before anyone else in this world knew that assigning weights to representations of nodes in a Neuron's knowledge of its neural neighbourhood would be better than assigning them merely to the physical connections it would share with its neighbours.<br />
<br />
This mechanism, and more as would answer most other questions about my concept is all there in my code. Really, it is... almost. I'm sitting on the greatest advancement in neuroscience since the perceptron!<br />
<br />Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-60921435672814189882019-09-20T20:00:00.001-07:002019-09-20T20:31:19.421-07:00Identity and SovereigntyThis post is more or less and addendum to my post on <a href="https://owenpaulthomas.blogspot.com/2018/11/sovereignty-demystified-well-im-trying.html">Sovereignty Demystified</a> in that everything explained in this earlier post except the association between a Connection and its property of sovereignty still applies.<br />
<br />
In Clique Space, sovereignty is a feature only of the Identity Element. Sovereignty is never communicated directly between Client Devices, but one device can work out if an Identity informed to it by a neighbouring device is indeed sovereign when it receives an Identity's key feature. The given Identity is sovereign when the Identity can be used to generate the same public key that was given as the key in the feature. In this case, the corresponding public/private key pair are stored as a CoSovereignKey in the given Identity.<br />
<br />
A Client Device can use an Identity with a non-null CoSovereignKey (a sovereign Identity) to sign deliberations that it generates when informing other Client Devices of subscriptions. Subscriptions are associations between a given feature Element, qualia known as the sense datum and the subject, and a given subscription tag - either an Identity if the subscription is a challenge, or a belief (an association between two Identities - the claimant and the candidate) if the subscription is a message.<br />
<br />
Because an Identity has to be sovereign to contain a private key, sovereign Identities are the only type of Identity capable of generating signatures for deliberations.<br />
<br />
Sovereignty encompasses an individual's concept of self-hood. Identity is a projection of this self-hood within an individual's manifest Clique Space and outward to Clique Spaces that manifest other individuals.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-35064335463859148632019-07-23T07:01:00.001-07:002019-07-23T07:03:27.931-07:00How's this Clique Space(TM) thing going?I'm still here. I'm venturing a comment that Clique Space is continuing, and it just now appears to me that I have perhaps resolved most of my concerns around the question of symmetry between challenges and messages.<br />
<br />
Challenges - sent from initiator to respondent, represent queries asked by a specific device and on behalf of a specific Identity known as the respondent for information about quale associated with a specific resonance.<br />
<br />
Messages - set from respondent to initiator, represent the state of a specific device which is associated with a pair of Identities (a belief - one is the claimant or the Identity making the claim, the other is the candidate or the Identity about which the claim is being made) associated with a specific resonance.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-8410842120975831042019-03-22T22:34:00.001-07:002019-03-23T03:48:46.408-07:00So, tell everyone what's been happening with this Clique Space(TM) thing of mine...Well might you ask...<br />
<br />
Neurons appear to do almost everything a Neuron of any type is supposed to do. The relay Neuron, (I used to call these naked Neurons on account of the fact that they implement nothing more than the basic Neural implementation) seem to work fine on my laptop. Instances of relay Neurons are started in separate JVM's so each Neuron exists as a separate process.<br />
<br />
The Java sockets API regards each process as being "out there" in a world completely separate from each other. They must communicate using TCP/IP socket connections, and hence, when (or if) I do get to run Neurons (or Client Devices more generally) on separate physical devices, there should be little more work needed on the core Clique Space concept; everything should be about extending the core concept to capture the specific nature of the host device.<br />
<br />
With my most recent commit, I think I have worked out the process that allows the life cycle of quale and other content to be managed.<br />
<br />
Content? Other content? Well, yes, as it turns out, all content has a container, and these containers must be managed in a way that prevents deadlock. Indeed, I think I have solved this with a simple anonymous inner class (something that can perhaps be re-implemented as a lambda) called a keeper.<br />
<br />
Content and containers are an abstraction: keepers are used to lock containers before access and ensure that any content retrieved or created is not disposed until the current thinker - instances of Java threads used throughout the Clique Space code - has finished with it. A Keeper can only be used to create or retrieve a single content instance. The keeper's container (and no other container) must be the container that is accessed.<br />
<br />
A thinker uses a keeper to lock the container before it acquires the content, and then releases the container for the next keeper. Thinkers manage a stack of keepers. This stack allows the thinker to release content in the reverse order in which it was acquired so content can be disposed of in an orderly way. A thinker can only access a container to add or get its content when it has a keeper that is ready to acquire an instance of its container's content; a keeper cannot be used after it has already acquired content.<br />
<br />
Quale are content to quale containers; a Neuron (a Client Device more generally) manages a single quale container. Subscribers are content to subscriptions; a subscription is also a type of quale and subscriptions are accessible from features. Deliberators are content to subscribers; apart from expressing the characteristics of both content and container, subscribers are nothing else. Deliberators are a type of thinker; they process (they deliberate) what should follow when a signal is received from another Client Device.<br />
<br />
Deliberators behave in accordance with the instructions given in the implementation of the methods used to deliberate messages or signals internally for a given feature. Features and Connections are some of the extensible components of the Clique Space concept. These components give an individual the ability to transmit and control the state of a device within Clique Space.<br />
<br />
I wonder if anyone else will take notice of this before I'm dead? I wonder if there indeed is anything to take notice of? I'll be pleasantly surprised if there is. I'll wait to be pleasantly surprised only until I die, and then I won't care.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-87537573853615023432019-01-02T15:24:00.000-08:002019-01-02T15:27:46.673-08:00How done might we be if the deliberator and the subscriber are combined?The subject of this post is the consideration that marrying the subscriber and the deliberator into a single class is a good idea.<br />
<br />
I actually think I might have stumbled upon the tail of this idea. I recall momentarily perceiving that it might be necessary a year ago. I was trying to implement the mechanism that helps a Client Device reconstitute as qualia information contained in a transmitter and I remember scaring myself with a very similar set of thoughts I am having now. It appears to me now that perhaps I just wasn't ready to follow this idea at that time; marrying the deliberator mechanism (a type of thinker - a Java thread used throughout the implementation) with the mechanism being considered looked so ambitious at the time that it induced some distraction.<br />
<br />
However, the reconstitution mechanism has been stable for some time now, so I think it's now worth to go back and follow a garden path that earlier expediency had caused me to avoid. Hence, I should consider merging the subscriber and the deliberator; it might perhaps complete the implementation of the core concept... or it will merely open up other questions about the core concept that were off in the thicket of enquiry hitherto. In any eventuality, combining the deliberator and subscriber appears to be a very attractive proposition at this point in time.<br />
<br />
This all looks to be quite a substantial unit of work unto itself, so I should perhaps obtain a clean working copy of my code before embarking. I'll do that later this afternoon. For now, I'll let these ideas steep for doing this might soften the trauma of implementing them.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-87158409248709635122018-11-17T23:09:00.000-08:002018-11-19T21:17:11.121-08:00Sovereignty demystified.I am about to commit some significant changes to my current working copy: local branch master checksum ID of 402ba642a6. Central to Clique Space(<a href="https://www.blogger.com/blogger.g?rinli=1&pli=1&blogID=4853644898562934826#editor/target=post;postID=4043663732468491604;onPublishedMenu=allposts;onClosedMenu=allposts;postNum=64;src=postname">TM</a> - although this link to a blog entry published in late June of 2012 is showing its age) is this thing I call the Sovereign. The changes I talk about here implement the the Sovereign's prime purpose.<br />
<br />
If one wants to design a system that could potentially act as a medium through which individuality can be projected if not also manifest, the notion of individuality would have to be well defined and delineated. This had been a prime necessity that mothered the concept's invention way back in 2004. Back then I had only the most incidental of notions (I knew it would involve digital signatures created from something that would never be transmitted between Client Devices) of how this feat would be pulled off.<br />
<br />
The fact in 2004 was that there was so much about the mechanism of Clique Space that was opaque to my intellect - so much that I could not hold in my mind that I had to start implementing it before I could figure out all of the concept's subtleties. I could see that although the data model (thrashed out a little before publication in the patent of 2008) disclosed the possibility of realisation of the concept, more than fourteen years of deliberation had to be endured before the question of sovereignty could be approached in any substantial way. Sovereignty is <b>the central notion</b> for Clique Space - a notion without which Clique Space would simply not make sense.<br />
<br />
The patent first published in January of 2008 used the name Account. At that time, and although the notion of delineating that which was and was not self was considered important, these notions were still a very nascent. As the years advanced and the concept evolved (through terms such as "Repropsyche"... don't know what I was on there, "Absurdum"... indeed I must have been losing hope at this point, and Axle ... a name I trialled because I began to understand how truly central this Element would be), I settled on Sovereign. This fact was disclosed in a <a href="https://www.blogger.com/blogger.g?rinli=1&pli=1&blogID=4853644898562934826#editor/target=post;postID=1876574298960152187;onPublishedMenu=allposts;onClosedMenu=allposts;postNum=50;src=postname">blog entry</a> made in December of 2012.<br />
<br />
The something that is never transmitted has evolved to become what I now call "that which is sacred". I take this to note that if there is a way to introduce quasi-religious terms into one's software, then this, as far as I can tell, appears to be it. It appears to be a systematic formalisation of the necessary ideal of the sacred, monopolised by religion for most of human experience hitherto, to make manifestation possible. Perhaps this feature is also responsible for inspiring religion in those who are manifest... who knows? I'm no believer, but I find the intersection I appear to have to navigate in Clique Space to be curious.<br />
<br />
That which is sacred is stored in a Client Device as a message digest of something that can be input to a digest algorithm. I have used SHA1 in the implementation, but have noted to myself that this algorithm has weaknesses that render it unsuitable for general use. The SHA1 algorithm has proven convenient for my implementation. That which is sacred is never disclosed between Client Devices; it is something that is probably known to the manifest individual (it would certainly serve the interests of the manifest individual to know what it is), but is certainly not known to anyone else because shared knowledge of this value could render the subject vulnerable to a breach of their sovereignty.<br />
<br />
The Identity, like the Sovereign, is a component (an Element as stipulated in the patent) that has survived from the concept's genesis, although it too was renamed from the less poetic Active Affiliation. Identities are used to project one's presence onto things in the world. Identities are known as identified Elements because Identities (as well and Participants) are identified by a 20 byte string known as an identifier. It was the coincidence between the length of the identifier and the length of an SHA1 digest that motivated me to use SHA1 while implementing the proof-of-concept; it wouldn't be much work at all to change the length of the identifier when another algorithm is selected, but I decided it was too much work for me to worry myself about now.<br />
<br />
The Identity's identifier is combined with that which is sacred using a bitwise exclusive-or operation. This yields an input to the SHA1 pseudo-random number generator which is used to generate a key pair. The private and public keys are assigned to a structure known as a co-Sovereign key, and this key is stored inside the Identity instance. The presence of a co-Sovereign key inside an Identity instance signifies to the Client Device that the given Identity is a Sovereign Element.<br />
<br />
Another structure known as a contra-Sovereign key, containing only the public key, is created. This structure is stored as a quale which is assigned to the Identity's key property and communicated inside transmitters between co-engaged Client Devices over synapses formed by the process of engagement. The mechanisms that permit all of this were designed and constructed after the patent was published, as part of the fourteen year journey in the wilderness of concept's development thus far. There are plenty of previous blog entries to regale the interested reader.<br />
<br />
A Client Device that receives an Identity key's surrogate will reconstitute the quale and assign the quale to the Identity key's property under a new disclosure if this is indeed a new disclosure. If a new disclosure instance is added to the property, the Client Device will compute a presumptive co-Sovereign key for this Identity. If the public key of this (currently presumptive) co-Sovereign key matches the public key of the disclosed contra-Sovereign key, the co-Sovereign key is stored within the Identity instance; the quality of sovereignty has been proven to be actual and not merely presumptive.<br />
<br />
Hence, an Identity's Sovereign Element status can be communicated between two Client Devices. In a similar way, Connections also have sovereignty in that Connections represent Client Device communication access points. A Sovereign Connection represents a co-sovereigned Client Device or rather a unit of mechanism that manifests a particular individual known as the Sovereign to both devices. A biological neuron is an instance of the mechanism of cognitive function in a similar way that a similar machine is an instance designed with the purpose of participating in cognition as a Clique Space aware Neuron (an instance of a subtype of Client Device). A Connection represents an individual Client Device (or perhaps merely one way of contacting one Client Device - one Client Device could have more than one Connection) so activities like synapse formation in Clique Space can occur.<br />
<br />
It's all going well. I think my concept is demonstrable to those who might be able to understand its function and can see its application while a practical demonstration of an application is still a ways off. Perhaps I'll find someone who will see Clique Space for what it can promise. Perhaps some day soon.<br />
<br />
This is my 200th blog entry.... yay! Two hundred blog entries (most of which appear to have been made in 2010 - 2013 because I was doing a lot of "heavy duty thinking" back then) in over nine years!Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-15703555378916126922018-07-29T05:54:00.000-07:002018-07-29T07:42:53.154-07:00Naked Neurons, other types of Neurons.It's been a while since my last post. I'm still alive; I'm still doing this thing I call Clique Space(TM).<br />
<br />
This evening, I feel somewhat relaxed. I have a working copy (only a little more than two weeks' old) still to be committed to my code base. This working copy is the first revision where I have moved the main method out of the Neuron and into two new projects. The first is called the "Naked Neuron", and the second, the "Clothed Neuron". The first represents an ongoing specialisation of the Neuron, while the second is somewhat of a hypothetical (even rather useless) specialisation of the Neuron so that I can conduct further tests on the efficacy of the Client Device project more generally. My motivation for writing tonight came from an observation that perhaps I see a reasonably stable implementation of the way in which Neurons can be specialised.<br />
<br />
Apart from the fact that Neurons can contribute fully in cognition (glia are denied this privilege because they cannot engage their neighbouring Neurons as respondents), a naked Neuron has no capacity to do anything else. A naked Neuron can act as nothing more than a relay between otherwise clothed Neurons who may not share a direct engagement. Naked Neurons know how to communicate in Clique Space as initiators and respondents, but have no other ability; apart from Clique Space itself, a naked Neuron has no capacity to contribute to "thinking" by virtue of the fact that naked Neurons do not model any other medium.<br />
<br />
Clique Space acquires a thinking capacity because some Neurons can be specialised: some can perhaps be made to respond to photons hitting them; some can be made to contract like muscles; some can, when stimulated by other Neurons, perhaps produce some sensations that yet other Neurons specialised in some other way can react to. Glia (I cannot consider a naked version of these ever to make sense) can be specialised to maintain a nice environment for themselves and their Neural brethren. They can perhaps help by dilating nearby nutrient vessels when they detect their neighbouring Neurons undergoing heavy cognition, or perhaps glia help speed signal flow by enclosing the axons of their Neural neighbours in a sheath of myelin.<br />
<br />
A Clique Space Neuron software implementation can be specialised by extending the inbound Connection class (NeuralInboundConnection) exposed as an abstract class in the Neuron project. This class can be extended to capture stimuli that are generated though some other medium present on the specialised Neuron's host hardware. These stimuli must be recorded as qualia - the units of cognition - that must also be accompanied by instances of a surrogate - a serialisable proxy of a quale - so qualia related to a given stimulus can be sent as a signal from one Client Device to be reconstituted as quale in another. Signals are individually wrapped in envelopes, and collections of envelopes are bundled in transmitters before transmitters are exchanged as part of a synapse's activity cycle.<br />
<br />
A property also needs to be created and stored (usually) as a native property of the extended version of the inbound Connection. This property allows a Neuron to form and communicate a belief that a particular stimulus (the object - perhaps associated with a sense datum quale different to the object quale) has been received by the a given Neuron, and is being asserted by a given Identity.<br />
<br />
This very quickly put together summary of Clique Space constitutes a semantically rigid language of thought that I have no reason not to believe would ultimately derive of a synthetic mechanism the ability to exist.<br />
<br />
Perhaps... I have no idea really and odds on this is probably bullshit. Even so, it appears to have worked for me so far.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-33657184238649098802017-11-24T17:51:00.004-08:002017-12-21T18:57:04.315-08:00Is 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-87635032816632020562017-11-23T15:24:00.000-08:002017-11-23T15:46:00.087-08:00The "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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-21971802978057065622017-11-07T04:48:00.002-08:002017-11-08T23:20:53.023-08:00What is the singular term for "glia"?I am entertaining a dilemma which I will answer conclusively in this posting.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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 <a href="http://austinpublishinggroup.com/neurology-neurosciences/fulltext/ann-v1-id1008.php">least one publication</a> 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.<br />
<br />
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. Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-64431093433889783902017-09-24T06:17:00.000-07:002017-09-24T06:18:02.353-07:00Refactoring and some name changes.I've decided to change more names.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Oh, I'm still here... yay! Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-83064079681778788142017-04-08T23:33:00.001-07:002017-04-09T03:39:11.921-07:00Agent Devices are neurons and Administrator Clients are glia.I'm still here. Doing Clique Space (TM). Drip drip drip.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Maybe the best I can hope for is to put this on GitHub, but I haven't come to that conclusion yet.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-78291998103113181162016-11-23T16:14:00.001-08:002017-04-09T06:32:23.784-07:00Even More Robust EngagementThis 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.'<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<pre>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();
this.subscribers.add(subscriber);
if(cycleIn&&channel.isInitiator()||cycleOut&&channel.isRespondent()){
if(c!=subscriber){
throw new Subscribe_FirstCycleSubscriberNotOutboundConnection();
}
/*Uninteresting code removed.*/
channel.activate();
}else if(cycleOut&&c==subscriber){
ChannelAdviser ca=channel.getChannelAdviser();
if(ca==null){
throw new Subscribe_ChannelAdviserDoesNotExist();
}
int ci=channel.getDrive().getCycleInterval();
if(ci==0){
throw new Subscribe_CycleIntervalNotSet();
}
try{
ca.join(ci);
if(ca.isAlive()){
ca.interrupt();
throw new InterruptedException("Cycle interval exceeded; other Client Device is probably unresponsive.");
}
}catch(InterruptedException ex){
throw new Subscribe_CurrentAdviserHasBeenInterrupted(ex);
}
channel.getDrive().interrupt();
}
}
</pre>
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<pre>public boolean isInitiator()throws CliqueSpaceException{
boolean isInitiator;
if(this.isInitiator==null){
isInitiator=false;
}else{
isInitiator=this.isInitiator;
}
return isInitiator;
}
public boolean isRespondent()throws CliqueSpaceException{
boolean isRespondent;
if(this.isInitiator==null){
isRespondent=false;
}else{
isRespondent=!this.isInitiator;
}
return isRespondent;
}
</pre>
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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).<br />
<br />
<br />
<br />
<br />
<br />
Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-3550635331422978762016-10-10T05:47:00.000-07:002016-11-07T01:08:27.920-08:00Steganography: a method of identifying Elements signed by the SovereignYes... I'm still working on it. I am a love slave to this Clique Space(TM) thing.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-22809172775449489682016-05-26T19:15:00.003-07:002016-05-30T02:17:22.418-07:00Hmmm... a relatively curious bit of code...At approximately 8:25am AEST on Saturday 28 May 2016, I wrote the following code:<br />
<br />
<pre>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(
channel.getThisDeviceRepresentative().getIdentity());
if(!su.getCarrier().contemplate(su,author,channel)){
su.dispose();
}
}</pre>
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0tag:blogger.com,1999:blog-4853644898562934826.post-32551864149789284412016-02-08T22:17:00.001-08:002016-02-14T01:29:14.041-08:00Finally...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.<br />
<br />
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.Owen Thomashttp://www.blogger.com/profile/05019343424769849874noreply@blogger.com0