Of Clique Owners and the resolution of "squabbles".

The implementation has brought me to the question of the resolution of confusion that would inevitably arise when different versions of Clique Space(TM) Elements are flying around, and being communicated to devices; which version is the true version.

This is a significant issue to the smooth operation of the Clique Space. This issue is equally significant to all devices that are connected within a Clique Space domain, and between federated domains. The issue is critically significant to all devices that use Clique Space, and counts directly to Clique Space's efficacy.

So, considering this issue earlier, I envisaged that one Agent Device in every Clique Space was responsible for the consistency of all the Clique Space's Elements. Furthermore, I envisaged that one Participant of every Clique would be responsible for the consistent communication of all Participants' device status. As a Clique Space is itself, modelled in a Clique, any Agent Device which has the ultimate say in the state of a Clique Space and its constituent Elements is designated the Clique's Owner for that Clique Space's Clique just as the case is true for the Agent Device that is serving any other device associated with a Participant designated as that Clique's Owner.

Hence, in any medium, a Clique's Owner is a critical designation; fulfilling the necessary realisation of an ultimate chain of responsibility that ends with a single Agent Device as arbiter of squabbles that would ensue when, consequent to changes in device state, different versions of Elements exist simultaneously. Such squabbles need to be resolved quickly so that a Clique Space can be restored to a consistent internal reflection of the state of all devices.

So, the following observations can be made about Clique Owners.

1. The general case for all devices
   
   The Clique's Owner Agent Device (the Agent Device serving a device assigned as one or more Participants - one of which is designated as the Clique's Owner) is the Agent Device responsible for the consistent representation of all Participants in that Clique.
   
   
2. The specific case for a Clique that is modelling the underlying Agent Collaboration
   
   The Clique's Owner Agent Device (a particular Agent Device which is manifest by one or more Participants - one of which is designated as the Clique's Owner) is ultimately responsible for the existence and state of all Clique Space Elements in that Clique Space.

Hence, general Clique Owners are the lords of their Cliques, while a Clique Space's Clique Owner is the sovereign representative of a particular Clique Space domain - much like a King or President. The Clique Space Owner may hence be the prime target for a cyber attack in the Clique Space system, while a Clique Owner in any other medium might be the target of such an attack which would be limited only to the particular medium being modelled.

Ownership, influential power, concepts of sovereignty, and ways and means to overthrow and resist attempts to overthrow, become a central consideration in cyberspace as they may ever have been in any other physical sense.

I firmly believe that something like Clique Space can largely cast aside myths that the internet is a place where anonymity over any telecommunications medium can be maintained. It is at least theoretically possible that access to and use of a telecommunications infrastructure of any type can be totally supervised by a Clique Space system.

This might be a controversial claim, but it is one that remains to be disproved. I believe that whoever implements a truly real-time media agnostic audit and control system, they will find that they will have had to do this in accordance with my specification for Clique Space.

Clique Space(TM) Progress Report

I've redone the way the Agent Device forms an Agent Collaboration's Clique. This time, I've put in a bit more thought about how the formation of the Clique Space can rely more on the core components to the Clique Space concept. I.e., how I can form an Agent Collaboration's Clique Space as if it were just like any other medium.

It appears that I've had to forsake multiparty formation. This is primarily because restricting the process to the concept's core objects leads to a small conundrum in the formation process: in what administrative domain is a Clique Space formed? Well, I've answered that in part by the concept of the Agent Device's Clique Space. The Agent Device's Clique Space is the genesis of all other (Agent Collaborations') Clique Spaces.

So, I've taken the opportunity to describe a use case scenario of how an Agent Collaboration's Clique Space can be created. This is a fairly accurate description as a version of it was accompanied by console output of the three devices (one Agent Device - AgentOne - and two Client Devices - ClientOne and ClientTwo) to someone who has expressed an ongoing interest in the concept.

So, here is the scenario:

1. ClientOne connects, activates, and forms a serving Agent Device's Clique with AgentOne in the Clique Space known as the Agent Device's Clique Space.
   
   
2. ClientOne instructs the Agent Device to create a new "Agent Collaboration's" Clique Space by using the same Active Affiliations that formed the Agent Device's Clique Space. The new serving Agent Device Clique is to be named "Two" and the Agent Collaboration's Clique Space is to be named "First".
   
   AgentOne does not know of a Clique Space named "First", so by specifying a Clique Space name that the Agent Device doesn't know of, this Clique Space will be created on AgentOne, and a Clique will form that has two Participants - both taken from AgentOne's collaborator Active Affiliation that is created in this new Clique Space so the new Clique Space itself can be modeled. This "Agent Collaboration's" Clique will also have the name "First".
   
   Because ClientOne is connected to AgentOne in a serving Agent Device's Clique on the Agent Device's Clique Space, the Agent Device uses these two Active Affiliations to create Participants that appear in a serving Agent Device's Clique - "Two" as named in the form operation - inside the new Agent Collaboration's Clique Space.
   
   These elements demonstrate one use of foreign elements in Clique Spaces that are technically federated even though they exist merely as different collections of Clique Space Elements in the same Agent Device. Although untestable until I get the Agent Collaboration truly functioning (see the first paragraph following these steps), I believe the Clique Space federation is a natural extension to what already exists.
   
   
3. In this step, I cheat by taking advantage of the fact that I can see what Elements exist on the Agent Device through its console output. With this knowledge (a Clique Space user may not ordinarily have it) I take an identifier of one of the AgentCollaboratorParticipants (these are the Agent Device's collaborator Participants in the Clique that is modeling Clique Space "First" - mentioned in step 2) and tell ClientOne to get this identifier. Doing this creates the projection of the Clique Space's Clique - the Clique named "First" - in ClientOne.
   
   
4. ClientOne then shows a Participant list of Clique "First", an Element list of Clique Space "First", and Element structures of the Agent Device (just another Client Device structure to Clique Space) described by both Participants of Clique "First". Both Client Device structures show that both Participants are created from the same set of six elements that describe AgentOne. In other words, both structures list the same set of six Elements; they come from the same Client (Agent) Device.
   
   
5. ClientOne creates a new Account called "Who", an Account Profile called "Self", and an affiliation that associates the Account and Account Profile on "First" - the newly created Agent Collaboration's Clique Space.
   
   
6. ClientTwo connects to "First" using the Account "Who" (Who is on First), activates its Connection against the Affiliation registered in the previous step, and forms a serving Agent Device's Clique with the Agent Device in Clique Space "First" called "Three".
   
   At this point, we can observe the element structure of this newly formed Agent Device's Clique. Doing this demonstrates that "Who" - the Account underlying the Participant which is modeling ClientTwo - is a different user to "Primary" - the Account underlying the Participant which is modeling AgentOne. This is of course what most Cliques would be representing - a collaboration between two or more Participants typically representing two or more individuals typically using two or more devices over a particular medium.
   
   
7. To demonstrate that the Clique Space concept is robust, ClientOne is instructed to disband Clique "First". Because Clique "First" is the Clique that models the Clique Space in which it is manifest, this instruction obviously implies that Clique Space "First" is to be destroyed.
   
   Hence, in an orderly fashion, AgentOne disconnects ClientTwo, and ClientTwo cleans itself of Clique Space "First". Likewise, ClientOne is disconnected from "First" and cleans out its projection of the Clique Space, including both Cliques "Two" and "First".
   
   
8. Observing the Element structures again, we can see that ClientTwo is not connected to an Agent Device, and knows of no Cliques. ClientOne remains connected to AgentOne via its Agent Device's Clique Space, and knows of Clique named "One" which models ClientOne's connection to AgentOne through this Clique Space.
   
   
9. ClientOne disbands the serving Agent Device's Clique from "First" which removes this Clique Space from ClientOne, and finally deactivates, and disconnects itself from AgentOne. This leaves AgentOne's Clique Space container in the same state it was when it was started.
   

This scenario primarily represents the creation and destruction of an Agent Collaboration's Clique Space. However, Agent Devices do not currently collaborate, although I have implemented some of the infrastructure necessary to do this. My intent has always been to have Agent Devices collaborate to realise Clique Spaces; this being the prime reason I called them Agent Devices.

I think Clique Space does some unique things, and provides the potential to see some other rather unique things emerge. To me, these things appear analogous to how a central nervous system functions. It is still my belief (a believe I have held shortly after conceiving the system) that anything that would do anything similar to Clique Space would provide society with something similar to a CNS. Likewise, I believe that anything that realises a social (or possibly any synthetic) CNS is probably going to look very much like Clique Space.

Additionally, and I've seen this since putting the user case together, I've begun to question the purpose of federating an Agent Device's Clique Space when forming an Agent Collaboration's as described in the fourth paragraph of step 2. Although federations are an important component to the Clique Space concept, and although the concept of Clique Space federation should be as natural as it appears in step 2, I feel uncomfortable about federating an Agent Device's Clique Space as step 2 demonstrates. This did originally start as an appeal to some thought of algorithmic symmetry, but now, the concept of an Agent Device's Clique Space which can federate seems technically problematic.

There's still more work to be done on Clique Space formation...

Clique Space(TM) and Wikileaks

This unfolding tale of "citizen action" is great to watch. In some ways, blame might in time be seen to fall with me for raining on the parade. In considering this statement, it still might be nice to be recognised for inventing such a versatile tool.

The internet is supposed to allow anonymous communication, and the Clique Space system can deal with people who choose to remain anonymous by simply not connecting to one, while interacting with others who do use one or more Clique Spaces to keep track of their device activity and interactivity with other individuals so connected. However, what might be controversial is that any device can obtain a connection to a Clique Space.

Truly, any piece of hardware or software could be eligible of being made "Clique Space aware", so any "low-level network device" over which a network is manifest could potentially be connected to a Clique Space. Now, if devices such as these are connected to a Clique Space, they might mandate that devices that use them to provide low-level network services to also be connected. Such low-level network devices might also account for the number of bits that they transmit between themselves by any device which uses them, ultimately assigning these bits to the user from whom the bits originated and to whom the bits were destined. As a Clique Space is used to capture which device is sending which bits to which other device, an audit log could well be kept of which users are sending and which users are receiving every bit that is transmitted.

Because Clique Space might identify a user who is claiming control of a device to other users capable of knowing these things, the potential does arise to attribute the transmission and consumption of every bit of information to the actions of the individuals involved, and hence, holding them accountable for their actions.

I don't wish to make it my place to prescribe wisdom on the morality of such a scenario. I only wish to point out that such a scenario is possible with Clique Space as the tool. Society is there to make such intricate judgement calls. In considering some of the ways that anonymity can embolden individuals to do harm to other individuals, I'm not going to discount the utility in a scenario such as this; however, neither am I about to defend the actions of corporate or government organisations that attempt to restrain the rights and so forth of what it is to be an individual.

Clique Space(TM) Progress Report

Over the past week or so I have been working on the Agent Collaboration's Clique Space, and yesterday reached a break-through of sorts.

I can create a multi party Agent Collaboration Clique Space on the device designated as the Clique Space Owner. Although the underlying Agent Collaboration does not yet distribute the Clique Space and its contents to all member Agent Devices which are recorded as Participants in the Clique representing the Agent Collaboration, the Clique Owner (the Clique Space and the Agent Collaboration Owner) "invites" the prospective members into this Agent Collaboration by requesting each to divulge identifying characteristics about themselves corresponding to the Agent Device's device Participant identifiers supplied by the administrator Client Device directing the Agent Device to create the new Clique Space, and hence form the new Clique.

As I work further on this, I realise further just how flexible and elegant my concept is. For instance, in this case, I now realise how I can improve the way the Agent Devices are asked to form the Agent Collaboration's Clique Space. At the moment, I direct the administrator tool (the Client Device in this case) to Connect to each Agent Device, and from there, I issue a special "create cliquespace" command to one of the Agent Devices, supplying the administrator tool's delegate Connections obtained from each other prospective member. Even though I think this is a very good first try at the formation of an Agent Collaboration's Clique Space, think this is a little too "special" in that I am making excuses for the Clique Spaces' creation that go beyond my original specification; I am saying that Clique Spaces are more than just a collection of devices participating in some collaborative activity, ipso facto raising Clique Spaces above mere collaborations between devices.

I do not believe Clique Spaces are more than mere collaborations between devices. I am actually thinking how I might bring the Agent Collaboration's Clique Space down to the same plebby collaboration level possible between any set of devices. I believe this will involve a federation between the Agent Collaboration's and the Agent Devices' Clique Spaces because at this moment, the Connections that look most suitable to be activated in the Agent Collaboration's Clique Space are the ones that each member Agent Device creates to their own Agent Device's Clique Space.

This way of Agent Collaboration Clique Space membership is very intriguing, and demonstrates an immediate utility of federation I hadn't hitherto though of.

More to come... evidently.

New Domain established.

For those of you who may be interested, I have set up a dynamic domain name: cliquespace.dyndns.org. May all your IP logs give you certainty.

Enjoy.

A letter titled: "What you may want to do about my enrolment."

-->

My local university has shown the same side to me as ever they have. I have given up on the fantasy that they might be able to help.

I am unsure whether you [the person I believe is the HPS - the 'to' recipient of this email] are still responsible for these matters (I don't know - nor should it require my effort to know - who actually is) but I tell you because I previously understood you to be the person responsible. Please forward this message to the person who is responsible should you no longer be such a person.

It has been almost two weeks since I last visited "my supervisor" [the 'CC' recipient of this email]. In that "meeting" my frustrations about his inability to keep a regular fortnightly appointment boiled over when I witnessed his indignant rebuttal of my efforts almost border on intimidation. Such behaviour as I witnessed appeared wholly hypocritical; he did not wish to express an interest in my idea by sticking to a regular fortnightly appointment, and now he's getting impatient with me?

Anyway, I witness such an incident as merely another instance where university staff attempt somehow to morally elevate themselves above their responsibilities to their students. Academic staff generally appear to expect a student to somehow respond to this distancing by devoting all one's time to the task of appeasement. It appears that this posture (this academic culture) is incompatible with me and my version of human respect.

Hence, without a better suggestion, I wish to withdraw from my degree program and finally cast aside once and for all time, any misguided notions of support and respect which may have been carelessly planted in my head as a younger man. I'm not a socially engaging individual, so regardless of how useful the contents of my mind might actually be (I'm making no claims here), I'm willing to accept that I don't have a personality type that disposes me to get on in academia.

This will be the last time you receive correspondence from me about this matter unless, after receiving encouragement to do so, I consider there are other points to make.

Who gives a toss...

Invention and the inventor.

These deliberations come to you today because I'm rather pissed off about how I am (or might be) treated as an inventor. If I am indeed treated in the way that I might be, the society in which I, you, and everyone else dwells aught not to laud curiosity and inventiveness as a way by which individuals receive a reward; it's a fallacy, backed up by relatively few success stories of arbitrary origin, which perpetuates the larger myth that one's individual efforts are rewarded. Legends like these are the bullshit that sustains the stupid (myself amongst them) to cough up a great idea only to have no consideration paid for it.

Posthumous awards may await - piss off if they do; I want recognition in this lifetime or none at all. In this lifetime, I need some one or more people to recognise a potential - to take a chance - in my ideas. The worst thing that could happen is that they're crap. Knowing that an idea is crap is knowledge (a reward) in itself.

Not knowing whether an idea is feasible or crap is frustration to the inquisitive. Not having people to help one find out the feasibility/crappiness of an idea only prolongs the frustration. Having someone else claim a another inventor's feasible idea is downright betrayal, and posthumous recognition of a feasible idea is a waste of the notion of a quid pro quo for an inventor's time.

I'll go on with this exercise, only because I have nothing better to do with my time antehumous (that sounds like a word) and so working on Clique Space may save me from an insanity that springs from boredom, until, like yourself, death catches me.

Clique Space(TM) is mine. Help me prove that it works while I'm alive god damn you.

Clique Space(TM) and Microsoft Lync.

A bit of a development this evening. I get a reply from someone I never expected to receive a reply from. This individual is an employee of Microsoft, and he replied to a message I sent inviting comment on Clique Space. I was told of a product called Lync; a fairly new offering by Microsoft which looks to be a collaboration environment of sorts based around Microsoft products.

I have replied to the response, and I quote the reply I put excluding identifying characteristics of the individual as I neither sought nor received permission to publish these.

Here it is

After reading what Microsoft's LYNC is offering, I'll now attempt to challenge you by explaining a bit about how Clique Space looks at things. I hope you might find what I say interesting, and I hope you might engage me in a conversation over Clique Space. LYNC looks like a good way to achieve a collaborative environment, but a cursory look over it points to there being shortcomings that I find are present in many other such environments.

I believe self-reference and simplicity is crucial for any collaborative environment. The Clique Space data model is self-referential, very simple, and very generic. However, this data model is also extremely customisable to the functioning of any medium, and so I claim is a very powerful way to represent any collaborative activity of people over cyberspace. Clique Space will model any current and future collaborative hardware or software device. Clique Space will even model collaborative activity of devices which you may think are not collaborative, and it will do this in a completely consistent way.

However, the implementation of Clique Space is a very substantial task; one for which I haven't got the capability myself. I need the help of others, and so I appeal to you in the hope that you might respond positively. Even after my cursory review of LYNC, I remain to be convinced that anything comparable to Clique Space currently exists.

Thanks for your time, and I hope to hear from you soon.

Of course I respect trademarks, and Lync, being one, is given its due respect. Although I realise that publishing this post may generate future business opportunities, I do not expect to derive any income directly from the use of any other proprietary marks. It's a little hard to talk about something without actually naming it.

A trend in the industry of information. A trend in my mind.

The more I observe, the more I'm convinced that the IT industry isn't developing as much as it is merely aging along with a generation, called "baby boomer" that had taken to labelling generations that have followed by the last three letters of the alphabet; enough that it might keep itself happily bathed in hubris before death eventually enfolds its number.

Whoa... packing a cynical punch! Still, better than a nervous breakdown that would result from the self-consuming simper others, comfortably nestled in their educated piety, might find entertaining.

Some interest in Clique Space(TM)

I have been receiving some interest in my concept. This is great to see because I'm rather hoping I'm not crazy about this stuff. Otherwise, I'd rather hope to be able to walk having tried my best, and having proven another concept of mine wrong.

Here's some of the comments I've received from some people who are involved in the identity community. I have tried to remove identifying characteristics of the individuals concerned.

1. This is extremely relevant in a federation and my initial cursor review of your paper sparks a bit of interest.
   
   
2. [In later correspondence, the same respondent as 1 commented] This fits and benefits various sized federation environments so I am more than fleetingly interested.
   
   
3. I'm somewhat interested in the idea since I've been thinking about the "Internet of Things" from a capability POV lately.
   

There have been other comments one could judge as largely positive made privately, but the comments I give here expressed sentiments I believe I could separate from identifying characteristics of the respondents while keeping their context.

A definition of the Client Device.

I can't leave it alone. My last posting has been niggling me since I posted it. If I don't clearly define this Client Device term, I feel as though a central piece of my concept becomes ambiguous, and my concept weakens.

My concept is clear. Although it has become clearer because I've given time to its implementation in a computer language, the concept has not changed substantially since I put it down in my prov January 2008.

Here's a clear definition: A Client Device describes properties about the device and the individual that controls it. The Client Device is a manifestation of any physical hardware device, software process, or any other concept that can be so expressed in Clique Space. The Client Device is hence, a realisation of a Clique Space entity as a compendium of Clique Space Elements. This notion is left intentionally philosophical because the concept quickly fractures when you try to explain a Client Device as a particular arrangement of Clique Space Elements; I think it's best to think of a Client Device as a holistic, though still discrete entity; instances of which can be expressed through different collections of Clique Space Elements.

Glad to have gotten that off my chest.

(Apparent) Errata from 5 October

I've just looked at the blog I put up on 5 October, and there appear to be some statements of inaccuracy in it.

It appears to me currently that a Client Device does not have the register with the Clique Space(TM) owner to become an active participant in Clique Space. It currently appears sufficient only to participate in a Clique with the serving Agent Device for the particular Clique Space in question.

Additionally, one Client Device is not described by a single Connection. The Client Device is actually a dissection through a weird, multidimensional beast made up of one combination of all the Clique Space Elements. One Connection normally is associated to one Account which might have multiple Active Affiliations which associate the given device to multiple roles as expressed through the multiple Affiliations. Each Affiliation is normally expressed as an association between one Account and one Account Profile.

It's still, as ever it was, a work in progress.

The unknown known and how some people suck.

I'm listening to a broadcast from the US National Public Radio taken from a feed of the Australian national broadcaster (ABC) about how ideas and concepts involve networks and the building of ideas on top of one another. Apparently, this is innovation.

Personally, I think a lot of what is being said on this program are ways to rationalise reasons for why the individual has no claim to one's ideas. It's all a big hippy free love thing. Anyway, to steer me back to the point of my topic... I am updating the count of the types of knowledge... there is relevance in the fourth: the unknown known.

That is, there are those facts we know; there are those facts we know we don't know; there are those facts we don't know we don't know. I also include facts that we don't know that we know. It is this fourth fact that yields epiphany, and is heralded as innovation.

I believe that for several years before the winter of 2004 when I joined the dots whilst jogging, I had the requisite pieces of the Clique Space(TM) concept in my mind; all that remained was my realisation that they were coherent. So, I had been working on Clique Space for some time - I remember wistfully mulling over various pieces of concept soon after my stupid boss's boss roused me out of his office when he couldn't give me a reasonable justification for vetoing my boss's approval for me not to have to commute to Sydney 5 days per week.

People can really suck. But their suckiness can drive inspiration. However, that suckiness can also rid the individual of their claim to their own inspiration, and assign this inspiration to something called a 'network'.

Some people can act most perniciously.

Clique Space(TM) is alive an kicking, except for...

Today, I committed revision 306 to my svn code base.

Apart from the fact that I have an implementation that is 1. next to useless; 2. ugly; 3. fragile and inflexible; 4. possibly leaking memory like a gauze-less sieve; 5. without transaction and thread control; and 6. insecure, I reckon to have proven about 75 to 80 percent of the core concept. The only component to remain in fantasy land is the full implementation of the Enabling and Limiting Constraints, although the latter has been partially implemented.

The Clique Space view, while being part of the concept that I envisaged, is apparently not part of the concept that I have patented. Again, it appears that I'm not rich enough to afford to protect myself.

So, to explain these numbered points.

1. Next to useless.
   
   This might sound derisive (in a way it probably is) but this is actually progress from the state of fantasy that one would behold had I not have started this exercise. This is also a relatively accurate statement considering the fact that Clique Space is customised to work with devices through Media Profile customisations. Considering that someone told me there are about 4 million types of devices in this world (that's probably growing at an exponential rate based somewhere around More's folklore), the fact that I have implemented no less than two (the Clique Space administrator Client Device and the Agent Device) means I've got quite a few device types to make Clique Space generally useful.
   
   
2. Ugly.
   
   Currently, Clique Space has only a console interface. I have very clear ideas about how I want Clique Space to look, but at the moment, I still have too much application logic concerns to direct any focus this way. By console interface, I probably mean an interface that has no proper display output at all: just many strategically placed system.out.print/println() statements; input, via the administrator Client Device (where it is supposed to be) is through a simple command dialogue box.
   
   
3. Fragile and inflexible.
   
   Clique Space can be considered fragile and inflexible for three reasons. Firstly, in so far as my prototype can behave in all the ways it will when fully developed, it indeed does a great majority of these things. However, there is currently no respect paid to human error or interference introduced through a noisy world. Anything unexpected that happens to Clique Space while running usually leaves the associated Agent Device and the zero or more connected Client Devices in an inconsistent state. There is currently no way of dealing with exceptions but to restart all devices involved.
   
   Secondly, a Clique Space is a collaboration of one or more Agent Devices. Only one Agent Device (the Clique Space owner) can currently realise a Clique Space because the Agent Collaboration has not been implemented. I am about to direct my immediate attentions to the implementation of the Agent Collaboration.
   
   Thirdly, both the Client and Agent Devices operate on the same host. Although this is a relatively trivial issue (it just means replacing the hard-coded localhost entry with a configurable IP address in most circumstances where the devices are using TCP/IP as their transport) the development work that still remains to be done keeps me away from truly distributing my prototype on different hardware devices.
   
   
4. Possibly leaking memory like a gauze-less sieve.
   
   Simply, I have been programming functionality in to the system. At this moment, the Client Device appears to have better memory hygiene, but I'm just getting the thing (the whole Clique Space thing) to work. Maybe some day I'll get my hands or someone else's hands to get the Agent and Client Devices to properly clean up after themselves.
   
   
5. Without transaction or thread control.
   
   An Agent Device will not serve multiple Client Devices simultaneously, nor is it capable of reversing the actions of one Client Device if something goes wrong. The Agent and Client Devices communicate to each other using a collection of RMI servers set up on each. Although multi-threading is implemented by default through the RMI mechanism, no consideration has been paid to contention or deadlock. These are more specific cases that demonstrate the system's current fragility and inflexibility.
   
   
6. Insecure
   
   Clique Space will, of course, use whatever the latest information security mechanisms exist. Clique Space will, of course, be continually updated to use tighter such mechanisms as they come into being. At the moment, Clique Space has nothing. Separate Clique Spaces will be capable of federation into a large neighbourhood of distinct Clique Space domains, and Cliques that might form in one will (depending on mutual federation polices) be able to span two or more Clique Spaces. Secure federation is perhaps a while off right now.
   

To sum, I am beginning to see the shape and the potential of a fully developed Clique Space system, but there is one hell of a long way to go.

If you like this idea, and you think you might be able to help me, then please leave me a private message. I'll get back to you. Try me on my email address; owen dot paul dot thomas at gmail dot com or my phone number +61 401 493 433.

I also have a Skype address: "owen.paul.thomas". I'll fairly chew your ear off about Clique Space.

More on Clique Space(TM) and the self.

Again, it can be said that Clique Space defines the self. This "selfness" quality is asserted primarily through an Account.

Clique Space Accounts are used to express the individual operator behind adaptations of the how the user wishes to represent themselves to others; collections of Client Device Connections and role-based Affiliations. A connection is the first access level to a Client Device in a Clique Space. Such a Client Device may activate itself, or may be activated by another Client Device which is a Participant, and has the ability to activate such a Client Device through a Client Device which is registered in a Clique as a Participant with the Clique Space Owner. Usually such a Active Affiliation will be granted through authorisation from an Active Affiliation of a Clique Space administrator Client Device that is being used by the same Account (denoting the same operator) as that to which the access is being granted.

Clique Space, per se, is useless. Any Clique Space only becomes useful when it can model the interactions over different media as described in its Media Profile hierarchy. The more comprehensive this hierarchy, the more devices can be modelled, and hence, the more useful a Clique Space can potentially be either to those who choose to connect directly to it, or to those who choose to participate in Cliques that span their own Clique Space and the specific Clique Space in question. Connections associate an Account with a Media Profile, and one Connection represents one particular Client Device instance in Clique Space.

Affiliations are defined by associating a particular Account to (at least one, but possibly more) Account Profiles. Account Profiles are primarily the way by which privacy settings for a particular Account can be Asserted. An Account Profile hierarchy can define, for instance, a business hierarchy. Instances of Affiliations can be (depending on the permission settings - expressed through Limiting Constraints - of the Account Profile to which a particular Affiliation may associate) freely assigned to different Connections through the process known as Client Device activation. Each Active Affiliation is the apex of the set of six elements just described: Active Affiliation, Connection, Affiliation, Media Profile, Account, and Account Profile. These six elements aggregate a collection of Limiting Constraints.

Activation is the second access level; it is an association between a particular Connection and a particular Affiliation, and is itself, represented with an Active Affiliation. A Client Device that holds an Active Affiliation can, depending on the compatibility between Limiting Constraints between the two Client Device stacks, participate in Clique Space with other Client Devices which are likewise active.

Participants are the seventh element of the Client Device stack and are the third and final access level to a Client Device. Participants represent a Client Device's membership of a particular Clique; a group of collaborating Client Devices which are being modelled. The Clique's media is a collection of Enabling Constraints (parameters through which Limiting Constraints can shape) shared by all Client Devices. The media is determined by one of the Participants known as the Clique Owner.

A UML diagram is so much more compact.

Clique Space(TM) and peer to peer.

The issue I deliberate here is how does Clique Space address the question of the clandestine nature of peer to peer communications.

I put forward that Clique Space will have absolutely no effect in bringing these communications under control if such communications happen entirely over a network that is completely isolated; that one might be able to completely curtail peer-to-peer is a nuisance notion that only appeared when people started to look at the internet through the blinkers of web servers.

However, Clique Space will be able to prohibit or at least, to model peer-to-peer activity if at least one of the participating devices were connected to a Clique Space, or if at least one component of the underlying network infrastructure was connected to a Clique Space. However, this may be unlikely if the number of parties involved are kept to a minimum; peer-to-peer usually involves only two devices. Even so, the internet is based on forwarding messages between nodes until the messages reach their destination, so if any intermediary node is connected to a Clique Space, this activity can at least be collected.

Clandestine data exchange will still just as likely occur, but Clique Space may provide a way to tap into a conversation and integrate it with a wider set of activity. Hence, the prospect of modelling peer-to-peer data exchanges may be policed within Clique Space. Clique Space was designed to model collaboration between two or more devices - including intermediary network devices - and this is exactly what a peer-to-peer exchange is.

Any undesirable activity that may transpire through peer-to-peer would necessitate the construction of separate network infrastructure; an exercise that becomes more intractable as lower layers of network activity are incorporated into a Clique Space device activity model.

Clique Space(TM) and the smart grid.

I am listening to a segment on BBC world news about the so called "smart" electricity grid. John Arnold of Microsoft is being interviewed about the subject of integrating devices in the home with utility suppliers, and presenting everything to the home user through their own customisable interface, email messages, or phone text messages.

Clique Space. Hello?

I think I have something far more powerful than anything a Microsoft executive can prattle on radio show about. I think I can do all that any "smart grid" might want, but I also think I can model people collaborating and exchanging information over every conceivable current or future media. I think I can do this as reliably as any device that a user is operating can report usage. I think I can do all this over devices composed of physical hardware, software, a mixture of both. I think I can create new virtual devices which are a composition of other devices ad infinitum. I think I can model the collaborative reasons for why people might get together; thereby modelling any formal structure involved in collaborative or information exchange between two or more individuals. I think I can model the activity of individuals who might be engaging in activity that is not considered "collaborative" like travel and any other activity one might consider as having no traditional mode of communication.

I think I can do all this without violating the sacred notion of individual privacy - a notion that exists at Clique Space's core. In fact, I believe I could just as well (so, indeed, I will) say that Clique Space introduces a flexible and robust notion of sacred individuality to a secular society. Nothing I have seen has been able to assert so much with such a simple mechanism as I have put forward for Clique Space.

I've offered this idea to the world so that it might try to prove the idea wrong.

Clique Space(TM) Progress Report

Apparently, a Client Device can disconnect and activate a remote Client Device's Connection, and deactivate a remote Client Device's Active Affiliation. The logic to get one Client Device to form a Clique between another and a serving Agent Device is still buggy. Hence, this is what I've turned my attentions to now.

Once I do this, I may yet be able to pick up working on the Agent Collaboration from where I had quarantined the code. I had revisited on the Agent Collaboration about a month ago, but was diverted by the necessity of remote Client Device administration.

Anyway, once I nail the remote Clique formation, I might not yet return to the Agent Collaboration. I might in fact, work on the Clique Space View. I see the issue of the View as being quite a technical achievement in its own right. What I have had in mind for the View implementation may be at least as involved as the implementation of the core Clique Space application logic, and equally central to the full realisation of the Clique Space concept.

However, I think I'm going to run into a problem. The thing is, it (at least currently) appears that the RMI framework over which I am building Clique Space is incapable of handling code as if it were data. I.e., while data, describing the state of objects, can be transmitted from an RMI server to a client, the little I currently know about RMI tells me that it is incapable of transmitting JVM bytecode instructions from server to client. RMI appears to cover this issue with something called a code base server, but for so many reasons, it appears inadequate.

Hence, I might have to roll my own real-time on-the-fly code distribution solution, and hence it might be better to concentrate on the Agent Collaboration. On the other hand, I might be able to cobble together a start on the View that doesn't have to rely on reinventing a code distribution mechanism so I could demonstrate Clique Space to the people who attend demos that I hold from time to time. I want to be able to show at least a glimpse what a Clique Space is meant to look like, and the current code-trace console output is hardly giving people what they want. I want to get a functioning View so others would be able to understand what Clique Space is.

A partial implementation of the View would be a good move in terms of demonstrating the proof-of-concept.

Agent Collaboration v Clique Space View: things to think about...

Clique Space(TM) Progress Report

About 15 seconds ago, I committed revision 265 to SVN.

In this revision, a Client Device can now disband a Clique, deactivate a Connection and disconnect a Client Device through another remote Client Device. This draws Clique Space a little closer to some of the capabilities I have envisaged it would have since 2004.

Eventually, functionality like this will enable a device's operator (a Clique Space Account holder) to nominate through which particular devices one wishes others to know about one's cyberspatial presence. Being able to remotely control devices through the whole Clique Space access schema (connection, activation, forming/joining, leaving/disbanding, deactivation, disconnection) equips the individual user with control over these devices.

A device would normally transition from connected to activated after the user has authenticated the Connection that was obtained using their Account. As no other Clique Space user except the Account holder can see a Connection until it is activated, the Account holder has a chance to accept the Connection as authentic by activating it - thereby obtaining an Active Affiliation - or rejecting the Connection as inauthentic by disconnecting it - thereby removing the Connection, or simply leaving the Connection alone.

My confidence in this concept's efficacy grows still.

Clique Space(TM) Progress Report

I think now, after nearly 1.5 years, I might finally have made sufficient preparations to return to the Agent Collaboration. The work that needed to be done was to implement the Clique Space framework and Media Profile customisations for the Agent and administrator Client Devices. This work appears done, so now, I can return to the development of the Agent Collaboration, and the further specification of the engagement semantics of the Agent and administrator Client Devices in their respective Media Profiles.

I believe I will have to entertain thread control and some degree of transaction logic. This will require some thought, so I'm going to have to refrain from implementation for a while until I've had time to deliberate the enhancements that appear to be required.

Time to ponder and take one's bearings before the next sprint...

Clique Space(TM) progress report

I'm putting my prototype together in Java. I thought I'd quote a comment I put in the code here. I like to put preparatory comments in code wherever I feel the need to clarify to myself what it is that I need to do. I usually do this because I want to get my intentions down, and then leave them for a while to see if I'm sure that I want to do something in the way I describe in my comments.

I like these comments because they appear to be fairly accurate, and they disclose my intentions in a fairly central piece of the concept just prior implementation. However much I like to show how good I think I am at my craft, I think this is about as close to code as I'll get in this blog.

Here it is:

We have to remove the Clique if we find that the Element we are removing references for is the only member of the Clique in this Client Device. As we need the Owner for any Clique in order to get information on that Clique, the Owner will have either been previously removed in an Agent Collaboration's message that caused this method to be called, or this Element being here removed is the Owner. I.e., the Clique will have been disbanded; an Agent Collaboration message sent to the collaborating Agent Devices from (what was previously) the Clique's Owner will advise the same.

The Client Device shouldn't have to check that the Clique has disbanded; it just removes Elements as instructed by the serving Agent Device, removing its Clique if there are no more Elements in it. The Client Device will be able to cross reference the instructions it receives through it's Participant delegate server to its serving Agent Device with activity it receives through its Agent Collaboration member server (Agent Collaboration messages), and this information can be cross referenced to help diagnose a Clique Space's stability.

It appears that the only restriction that must be put on the order of Element removal is that the delegate Element (a Participant) must be the last Element asked to be removed when the Clique between the serving Agent Device and this Client Device disbands. In this case, the Client Device must get the opportunity to remove any Elements that are managed by the delegate Element, because the serving Agent Device will not advise the Client Device to remove these Elements; removal of the delegate Element implies removal of access to the managed elements.

There you go. I'm fairly sure this looks okay, but I'll have to let the comments in my code sit there for a while. Clique Space is a little like an art installation in progress.

Profound maxim #1: Understanding the paradox of sentience.

I have just returned from a jog along Wollongong's foreshore. It's a drab day. Sheets of rain falling between speckled intervals of grey on a cycleway devoid of all but the seagulls; a great day to run and meditate.

Maxim: Sentience defines what is sacred, and so is sacred itself. Its container must not leak.

Clique Space(TM) and a knowning self.

As I have made clear in previous posts, Clique Space can model itself. This means that Clique Space closes the circle of capability because if it couldn't "autosimulate", it wouldn't really be an environment capable of modelling anything. It would be like a balloon which had a hole in it; Clique Space would quickly deflate.

What of this capability then? How does the property of autosimulation help Clique Space in other aspects? What could be the end result of a system capable of autosimulation?

A system capable of modelling itself is easily capable of extending this model to model its environment in much the same way as the cortical homunculus models the organism (including each one of us) within which it is maintained. In this way, Clique Space is capable of modelling all the devices that are attached to it in exactly the same way as we model all our bodily functions within our own homunculus.

Functions consequent to this mapping including coordination of numerous muscles in the performance of a particular act would also be rendered possible in a Clique Space through the coordination of devices connected to it. As an extension to this coordination, higher cortical functions such as emotions, thought, and memory can be coordinated internally inside a Clique Space in exactly the same way as each of us feel, think, and lay down memories.

I think the analogy is very real, but I also think it is a portent of much potential danger. If a big brother might exist, a Clique Space system will give it the necessary "little brother" simulator. Indeed, if a Clique Space system might permit a foundation on which a mechanised consciousness might form, the definition of the self in a society might need to be reassessed to include more than just people.

IP registration and the consequences for Clique Space(TM)

The 30 month deadline has passed without financial backing to secure further national phases. The 31 month deadline looks likely to pass with a similar vein hope of securing a foothold in jurisdictions where I have 31 months. I'm not currently sure what I should say about development progress on Clique Space.

I am still enrolled for study, but only three national phase applications is not a positive outcome, and will tax my motivation to complete my research program. The only comfort I might be able to take from the publication of my idea is the fact that it is prior art. It's no one's idea, and hence, no one will be able to register it. Still, I have three national phases (one being the United States) so should there be any competitor activity, I may yet be able to claim licensing income in these jurisdictions, but even this is not given.

No one has helped me. Wollongong University has extended to me nothing beyond the enrolment. The opportunity for a backer to gain exclusive access to a market has slipped away. Negligence has bestowed a critical wound to a business proposal for a concept that I think will, in time, prove to be an indispensable tool for many types of collaborative activity.

Clique Space(TM) progress report.

I am deliberating the implementation of a major part of the innovative essence of Clique Space: how to determine whether a Clique can form.

This can be systematically worked out by finding the intersection of Media Profiles common to all nominated Active Affiliations, and then determining if the Clique Owner's Limiting Constraints can be applied to each Active Affiliation (including the Owner) without contradiction.

If there are no contradictions, the Clique can form. If there are contradictions, the Clique cannot form, and each contradiction will be made evident. A variation to this could be that the Owner could elect (through a Limiting Constraint) that a Clique may form provided a quorum of Participants is generated, even if some of the Active Affiliations cannot participate.

So, I believe I need something like an abstract method for Active Affiliations that will be implemented in a given Media Profile customisation. It looks like this method will accept 1: a set derived of the intersection of Media Profiles common to all member Active Affiliations (this will become the Clique's medium), and 2: the Clique Owner's Active Affiliation. It looks probable that this method will return a Participant for the Active Affiliation it is called on, or a list of contradictions. The method will return both if the user will permit the variation described above.

I remain confident...

Clique Space(TM) progress report.

It is Sunday night, 11:30. I am sitting in front of the teev watching some cop drama. I am reasonably happy having had dinner at my mothers and almost ready to go to bed.

About a week ago, I set up SVN on my spare desktop. I'm now using that installation to host my code, and I am preparing to head off in two possible directions. First, I've still to complete the Agent Collaboration, and second, is the concept of constraints which still remain to be implemented.

As has so far been the case, I'm going to address both issues simultaneously until fate determines which one (or particular part of one) my attentions should be concentrated.

I have three patents: AU, NZ, and US, and although I believe three patents is not be enough to set up a marketplace that is free from competition while this concept is establishing itself, I felt all along that I was up against stupid people who didn't have a clue. I would have completely lost my claim to ownership of this concept unless I saved enough money to make these three registrations myself. I wish I could have made more, but I have no more money.

Kill the fox to feed the pig. I need help with this for I prognosticate the necessity to defend the claims I have been able to afford...

Consideration for my IP

Almost a year has past since I registered a PCT about my concept. The outcome looks like becoming as real as my cynical deliberations a year ago had predicted.

The thing about using the patent system to protect IP is that it does involve risk. The length of time within which one has to prove whether the risk will pay off is in many cases insufficient for that risk to be assessed. Additionally, a risk also involves a probability of failure, and those who may choose to back a risk take on the consequences of the failure as well as any consequences of success. Unfortunately, it appears, the investment necessary to register national phase patents in some jurisdictions (viz Europe - $20 thousand AU) is too costly for any potential investor to to carry - even if the risk an investor may carry is only the money they would lose if the concept failed.

So, although I have three national phase applications in progress (Australia, New Zealand and the United States), I have no European registration, and this considerably compromises my market position, and saps my motivation. I have told the university as much, and although I intend to commence my study in July, think I might see things go on in the marketplace that will help me neither complete the programme nor apply myself fully to it. This may be all for the fact that I couldn't get a European registration because I couldn't afford the cost and couldn't find anyone to back me who could.

Although my concept becomes prior art, software leviathans may muscle in to the innovative territory staked out by my concept, and provide a solution that uses my concept in their product without paying consideration to me, the person who came up with the concept. I might observe this and conclude that this must be competition. This must justify the malaise that results in the cynicism that pervades an inventor's intentions. This must be the type of social justice in the society all of us want, because the evidence suggests that this is the type of social justice we all have.

Those who have the money to pay for expensive national phase patents stand a better chance of claiming ownership of their ideas than those that cannot. I can stand as testament to the way current secular philosophy can crush the individual as innovator; very possibly to promote the individual as consumer. Its better to kill the fox in us so to feed the pig in us. We've made this route so much less expensive and safer for everyone.

I have a disability support pension, so on disability support I will stay to do my consumer duty until my life is complete. Lay your hands on me oh life. Tuck me in.

A Clique Space(TM) generates a social homunculus.

In a very general way, a homunculus is often used to describe the way a nervous system maps the organism it represents. In much the same way, a Clique Space provides an environment that maps the goings on of a social network. I believe it is fair to say that Clique Space is a social nervous system, and like any nervous system, needs a way to map the body of the organism that the nervous system has control over - the social network over which the Clique Space has administrative dominion.

I think that's a fair conclusion to draw.

Clique Space(TM) and my opportunity.

When the world starts to think that modelling real-time ad-hoc collaborative activity by individuals is valuable, I'm hoping that it might pay me some respect for having adopted the "clique" as the basic the idea of tracking the ways collaborations over distinct media form, grow, contract and disband.

Clique Space(TM) progress report.

Indeed, I feel vindicated. My confidence in the strength of this concept has been steadily growing since I decided to give it a go back in January 2008 - three and a half years after it was conceived by me while jogging.

It appears as though the administrator Client Device and the Agent Device are working well together. Because of this, I am now thinking about moving my code base to an SVN installation on my IBM desktop running Ubuntu that I bought from my "work for the dole" employer last year, and running instances of the Agent and Client Devices on separate hardware after I replace the hard-coded reference to localhost from both to a true IP address.

Utterly wonderful.

I'm still using a console interface for the display of both Agent and Client Devices, and I imagine I will be for some time yet. Still, I imagine that the console interface will prove a valuable permanent component at least for the administrator Client Device. Any GUI will assist operators checking out the activity of the devices they control, and the devices others control as long as those others have given them permission to do this, but the console feed may be seen as being too convenient to let go of.

Anyway, I think I'm soon to have an environment that I will be able to present to others which will make some sense. I'm going to see if I can schedule a presentation of Clique Space at Wollongong uni after I get the Agent and Client Devices to work on separate hardware. In my presentation, I'll use my laptop at the podium to run one of two Client Devices. I'll start the other Client Device on one of two PC's inside the presentation room. On the other PC I'll start an Agent Device. My podium laptop and the two PC's will be networked together, and both Client Devices will be connected to the Agent Device. My laptop will be displaying the output of the Client Device through the projector that I will have run my presentation on, and the two presentation room PC's will be displaying their output on their own display.

I have been considering what other devices I might start developing Media Profile customisations for. Skype and an IRC client are good candidates. I'll do some more investigation on this. I also have my upcoming M.InfoSys research degree to consider this and other Clique Space related questions in. I have to contemplate some design theory related research directions for my degree, and indeed, I will get round to doing this before the degree starts in July.

While, from the above diatribe, it can be seen that I'm upbeat about the implementation, I'm perhaps a little philosophical about patent licensing.

I am in the process of finalising national phases for Australia, New Zealand, and the United States, but I do not have any more money to pay for registration in other jurisdictions. This is unfortunate, because I feel that a wider scope protection (Europe if possible, India if possible, China, Russia, Canada, Africa, and South America as some of the major ones) may only increase the attractiveness for business investment. But then, the collection of royalties from three jurisdictions would see me living in relative comfort; hence the philosophical disposition. I wonder if I'd still be recognised as the concept's inventor for the jurisdictions in which I didn't secure licensing...

Still, the PCT expires 15 July. That still gives me a bit of time to find finance, and I've still got a few lines of enquiry to follow...

Time will tell on Clique Space's future...

Clique Space(TM) progress report

What can I say... more good news.

As I write this, believe I have just stabilised the second of the three access levels (Connection, Active Affiliation, and Participant) available in Clique Space. These access levels have relevance to every device that uses a Clique Space, but their use is most obvious to the administrator Client Device because this device, being a device that a Clique Space administrator would use, needs to transfer through each of these levels manually as required by the administrator.

Generally, for devices of any medium...

Connection access allows a device to be seen by a Clique Space, but does not allow other devices (other than possibly those devices that have obtained a Clique Space Participant using the same account) to observe the given device. As I've said before, this is used as a very convenient way to facilitate remote authentication amongst perhaps a few other things that I can't recall right now.

Active Affiliation access allows a device to be seen within a Clique Space, but that access does not give the given device the ability to observe and engage others from within the given Clique Space. Because a device can collaborate with other devices through its device specific way regardless of whether it is connected to a Clique Space or not, it is envisaged that most devices would need only an Active Affiliation to collaborate with any other device for which they are able to engage. Besides that, giving participant access to a device that has no ability to view, and therefore engage other devices through, a Clique Space is redundant, and could subject the Clique Space users to undesirable consequences.

Clique Space Participant access is granted to a Client Device if the associated device possesses a view of the Clique Space. Such devices are usually equipped with a view of the Clique Space to which they have connected, and can actively interact with other devices using the Clique Space system. This interaction may include with those devices that make up the Clique Space.

Alternatively, the operator of a device obtains a Participant for a Client Device whenever the associated device collaborates with another device over some medium. While a device possessing only Active Affiliation access cannot engage another device from within the Clique Space system to which it is connected, that device may be able to engage similar devices in accordance with its own media protocol. If these other devices are likewise connected to the same Clique Space, the Clique Space will model this interaction as a Clique between the two individuals known to the Clique Space or federated Clique Spaces concerned as the devices' operators. Should one of the given devices not be connected to a Clique Space, the collaboration may still be modelled as a Clique between two Participants; one of the Participants is shown as anonymous.

This whole idea is so powerful that it's applicability may far outstrip my ability to describe it.

It is without any coincidence whatsoever that these access types are used to model collaborations going on in any medium by any number of individuals. This access "backbone" is part of the technology that has been developed around the core inspirational concept; the unaltered inspiration I had in 2004 whilst jogging between Bellambi and Bulli. The backbone is made up of three vertebrae (four if you want to be more technical and include the Media Profile) which I have envisaged are central to the Clique Space implementation.

Clique Space(TM) progress report.

My goal of modelling in real-time, interactions between individuals, anonymous or otherwise, that involve any device, any medium and any affiliation is farther along today than I thought myself worthy of. Two years ago, I had thought that the idea sounded good, but that possibly, there was a deep flaw somewhere in it. While I had rather cynically perhaps anticipated that there had been undocumented records of others who followed the path I am now on, I'm getting more confident about how this is shaping up with every passing day. It really appears to be efficacious.

Note, that my posting history should disclose the fact that I believe Clique Space is like nothing else currently conceived by anyone else - as far as I have been able to tell. I've already mentioned in a previous blog-post how Clique Space isn't middleware. I've already mentioned how Clique Space isn't a Multi-User Virtual Environment. I have already delineated the quintessential difference between Clique Space and other products like Google Wave. However, I'll reiterate it here just to make it clear:

• Clique Space(TM) models collaborative encounters by individuals.

That's it. How these collaborations function is up to the hardware doing the collaborating. Hence, Clique Space isn't a middleware system. It also isn't a Google Wave because Clique Space leaves the question of what "content" of a collaboration is modelled unanswered. Ultimately again, this is a question that must be answered by the media being modelled. Clique Space simply provides an environment in which the activity state of connected devices is used to depict coordinated collaborative activity between the devices' operators. Clique Space is more than a Role-Based Access Controller for no RBAC system I have seen asserts that it can create a device-independent model of the collaborative encounter of two or more participants (Participants), each of which are represented by one or more individual users, or are anonymous.

While a Clique Space might require a suitable Media Profile to be installed before it can model a particular medium, a Media Profile does not realise collaborations' underlying mechanics, nor does it instruct Clique Space how to physically realise the underlying machinery of the medium's implementation. The Media Profile simply exposes the existing components of this machinery to the Clique Space system in a manner that serves the intersection of the intents of the individual or organisation responsible for the Media Profile, the Clique Space's administration, and the individuals who make use of the Media Profile and a given Clique Space when they connect a device through the Media Profile to the given Clique Space using an Affiliation that identifies a role to an Account that identifies the individual.

Through this model, collaborative instances (Cliques) may be controlled and audit logs may be taken in accordance with every connected user's ability to do these things. I assert that Clique Space is the first contrivance of its type.

Does anyone have a differing opinion?

UOW approves Masters by Research on Clique Space(TM).

This morning, I received an email from (who is now) my assigned research supervisor giving their approval for a research masters degree with Clique Space as the subject matter.

Excellent stuff. This university (my Alma Mater - because I live here) is a good one. I am hoping this will give me a good incubation environment where the concept's efficacy can be tested. Should this idea prove successful, I hope the university will be able to reduce obstacles to commercial development.

The Clique Space(TM) Agent Device.

I have been pondering how much alike an Agent Device is to the Client Devices (devices everyone possesses from time to time - things like phones, computers, cars, televisions, refrigerators, bicycles, etc.) that connect to an Agent Device so each might be able to be seen in a Clique Space to other users so connected. My ponderings were whimsically flowing over the subject of what of the Agent Device is being modelled in Clique Space.

It goes like this: any device one connects to Clique Space has something in common with any other device: each device can talk to selected others based on mechanical characteristics that enable this communication to take place. Each and every device connected to a Clique Space gives Clique Space information about its operating state so Clique Space can model this state and communicate it to devices which have the capability of rendering this model in some specific way in accordance to the medium of such a device. Such a device has connected to a particular Clique Space so that it can render (and possibly persist) this device activity model.

Each device which is connected to Clique Space is ultimately responsible for two things: it has to accurately 1. convey and control its place in the mechanical orchestra of its specific medium so that Clique Space 2. can accurately cross-reference the specific device's state with that of others and generate a model of user collaborations. A device has responsibility to accurately convey collaboration between 1. like devices in a specific collaboration, and 2. a Clique Space when connected to one so that the device's collaborative behaviour may be modelled (and controlled) within Cliques.

So, back to the original focus of my pondering. What dual responsibilities does an Agent Device have? Well, 1. an Agent Device collaborates with other Agent Devices over a medium known as Clique Space, so an Agent Device is therefore responsible for accurately conveying its state within this medium; 2. the Agent Device must communicate its state within a Clique Space it is a member of (and to which it also possesses a Connection) so that Clique Space can maintain an accurate model of the collaboration (a Clique) that represents that Clique Space's collaboration.

I love self-contained self-reference. Since I programmed in Smalltalk, it has been the singular most compelling subject responsible for exerting force on my attention, locking my gaze in an embrace that I appear unable (or unwilling - though perhaps I don't see a difference in this respect) to escape from. I believe such a subject is wholly or significantly responsible for the phenomenon of consciousness.

Owen.

And another Clique Space(TM) value proposition.

About two months ago, I made a submission to an organisation to try to elicit their interest in Clique Space. I was unsuccessful. I think it would be okay to quote some of what I had to say in a web log - especially since they asserted that anything I did submit to them would be treated as non-confidential.

So, here's a paraphrasing of some of the questions they asked, and answers I gave. These questions appear generic enough to be of interest to anyone who may want to think of helping me in realising Clique Space.

I was asked to give a detailed description of the business opportunity:

People have always desired mobility and autonomy in how they conduct their lives. This relationship extends specifically to how they interact with others in work (income generating) and non-work activities. Many types of Information and Communication Technology (ICT) devices empower the individual to greater flexibility with these qualities by keeping communications channels open at a distance.

ICT permit real-time interaction between an arbitrary number of people to occur over an increasing number of communications channels. This will continue an exponential growth trajectory for the foreseeable future.

However, this trend is also producing an intimidating mountain of technology. For each technology that comes to market, users need to grapple with the physical question of using a new device, and they must keep abreast of which other users might have the same device, who they may be representing when they are using the device, which other users may use the device if it is shared between two or more users. All user's must keep changes to their own usage pattern and those of others in case these details change, and attempts to engage one or more users by another one or more users are later perceived by the latter as intrusion when the former are unaware of, or can subvert any changes.

Therefore, adoption of new ICT will encounter growing resistance to their uptake as the number of available technologies increases. People will avoid using ICT because any impressions of enjoyment they may receive from their use are being stymied by an unnavigable morass in the sheer number, variation of their use, and the possibilities of increased probability of privacy invasion. While middle-ware solutions might go some way in reducing the physical barriers, other aspects such as standardisation of a device engagement interface, contact list management, individualised cross-cutting activity audit logging, and individualised cross-cutting device control remain largely unaddressed.

Clique Space will help ameliorate this resistance by providing an answer to what appears to be producing the resistance. It provides a simple and flexible collaboration mechanism that can be extended to work with any device. Although powerful, Clique Space is a simple solution to a significant and growing ICT dilemma.

I was asked to discuss the solution to the above business opportunity:

A Clique Space is realised by a device, or rather a network of collaborating devices called Agent Devices. The individual user connects any other hardware, software, synchronous or asynchronous device – a Client Device – to one of these Agent Devices through an Account that represents that individual self. The activity of all these devices and the interaction with other users generate device and Clique activity on a Clique Space that can be recorded and controlled by the individual.

Multiple Clique Space networks can be federated. These federated networks provide one way for an organisation to administer activity within their own Clique Space, and to coordinate activity between their own, and neighbouring Clique Spaces. Federation establishes administrative sovereignty within an organisation's Clique Space, while permitting regulated control of information between Clique Spaces.

A public Clique Space would function as a common federation hub through which organisational entities might federate their proprietary Clique Space. Anyone who needed to get in contact with any organisation may find that organisation's Clique Space presence through the public Clique Space. Metaphorically, the public Clique Space would function as a city street or town centre where most public interaction would take place.

While I believe it is fair not to expect licensing revenue from usage of the Clique Space implementation in a proprietary Clique Space, I do think substantial revenue would be realised in the cost of federating a proprietary Clique Space to the public Clique Space. Revenue may also be realised by device vendors that wish to register Media Profiles (customisations to the Clique Space for their particular devices) or small organisations who prefer their presence only to be manifest on the public Clique Space through an Account Profile user-role hierarchy. Revenue may also be realised through the provision of a guaranteed level of authentication

User Accounts are freely available and associable on the public Clique Space; anyone can use any account they want. There are, however, many ways of ensuring the authenticity of an individual's usage; but these would depend on characteristics of the devices and other federated Clique Spaces. To reduce the burden of information, I will leave discussion of these to a future meeting.

I was asked to describe the major characteristics of my product:

Although the concept is well-defined, its implementation is still a proof-of-concept. At the time this was written, the prototype is still relatively immature.

However, I envisage that Clique Spaces:

1. collect the activity state of devices connected to them, associating one or more devices with the individual(s) who is/are operating the devices

2. use the device activity state to generate real-time models of individuals as they collaborating

3. provide an opportunity to control collaborations in accordance with cross-cutting, device independent criteria associated with the collaborating individuals.

4. define a uniform media engagement UI which would assist the uptake of new ways of communicating as they became available

5. can be federated according to mutual agreed organisational boundary conditions.

6. have the potential to provide unique ways of connecting devices, including the connection of devices that make up a Clique Space to themselves and other devices.

This list is not an exhaustive compendium of Clique Space's capabilities.

I was asked to outline my company's "go-to-market" strategy

I would expect Clique Space to initially become popular by specialised “early adoption” users. When the product is sufficiently mature, organisations might be approached to trial Clique Space to as a way to coordinate device activity within and between their organisational boundaries.

As Clique Space's versatility gains a reputation, its use would be adopted by a wider collection of individuals both inside and outside organisations, and it is hoped that business, wanting to reach these consumers, may observe a return on expenditure necessary for representing itself in the public Clique Space. This may be a long-duration objective, but one that I believe would attract large revenue.

The holder or licensee of a patent (currently a PCT which expires 15 July 2010) would also have exclusive access to the technology while the patent remained active.

So, there one has it. Indeed, I do my best, and that is all one can ask for.

Another Clique Space(TM) value proposition.

I've been thinking more about the value of Clique Space, and here are a few more suggestions. This web log is taken from another private letter I wrote to someone who has been helping me frame the concept so it can be understood by others.

1. Remote device control.

I believe this is a differentiating quality, because even though there exist some network administration utilities that are capable of remote device administration, I assert that no other technology makes a case for this notion as flexibly as Clique Space.

To comprehend how flexible remote device administration in Clique Space is, one must be comfortable with the concept whereby a Clique Space user is capable of connecting as many devices as one possesses to as many Clique Spaces as one has access to. Amongst those devices (Client Devices) so connected, a user may have one device that gives the user access to a Clique Space View. Through this Clique Space View, the user may also control all Client Devices which they have obtained Connections for, and all Cliques one Owns on all Clique Spaces on has connected this View to.

One might want to obtain a Clique Space Connection for a device that one does not have physical possession of. Although one would have to indicate to Clique Space some address so Clique Space could contact the device in question, one might not have to know anything specific about how that device is located through its own addressing mechanism, because the Clique Space might be informed about how to contact the device in question through the Media Profile that has been installed on the Clique Space by that Clique Space's administrators; all one might have to remember is a generic Clique Space addressing mechanism, and the installed Media Profile might provide a mapping of this address to one specific for the device in question.

Depending largely on the versatility provided by the installed base of Media Profiles, a Clique Space may completely remove from the user, the necessity of having to remember any device specific control semantics. A user might only have to deal with one interface: the interface provided through a Clique Space View to connect a device to Clique Space, control a device within Clique Space, or engage a device within Clique Space with any other device within or outside of Clique Space in a collaboration moderated by Clique Space; the Clique.

2. User privacy assurances through multiple Affiliations.

While other access control systems may have notions of role-based access control, I do not believe any other concept uses this notion with quite the same versatility as Clique Space. Clique Space role-based access control is realised through the Affiliation, which is an association between an Account Profile and an Account. Like an Account, which identifies a single Clique Space user, Account Profiles and Affiliations are Clique Space Elements.

Because an Affiliation is a Clique Space Element, an Affiliation can be published as can the Account and Account Profile to which it relates. Now, regardless of whether a user knows the Account identity of another user, this first user may be unable to enquire on the Account identity of the second because the second user may have instructed Clique Space, through the application of a Limiting Constraint, not to divulge any knowledge of the second user's Account. The first user, instead, would only be able see connections of the second user that were associated (through an Active Affiliation) to the second user's published Affiliation.

Hence, the second user would have a way to assure privacy at the level of specific Client Devices by selecting an Affiliation through which each Client Device Connection is established. A user could therefore maintain multiple presences on multiple Clique Spaces simultaneously under the same Account name. However, owing to the fact that the user manages multiple Affiliations, a user could maintain separate guises and separate, flexible awarenesses to other users.

Now for an anecdote that combines a bit of both points.

This morning, I discovered that I lost my mobile phone. Yesterday evening, I had coffee and cake with a friend at a McDonald's in Wollongong. I did not know that I had left it there, but I was informed of this when my mother told me someone had left a message on her phone telling me my phone was set aside to be picked up. Indeed, I was happy to get it back and thankful to the person; both because they took the time to call my mother who, they probably (and correctly) assumed, would be a good choice of go-between, and for the fact that they understood that the phone was my property and they should make an effort to return it to me.

However, even though they had to go through my contacts or call-log to find a suitable person to send a message to (they chose my mother because she is recorded in my contacts as "Mum") I did feel as though my privacy was violated. This was unavoidable under the circumstances, but with a system like Clique Space, this violation of privacy needn't happen. If my phone were connected to the public Clique Space, and was displaying my Affiliation to the public Clique Space's Account Profile named "Self", the individual who picked it up may be able to get in contact with me directly.

That individual could use a device that offer's a View to the public Clique Space to enquire on my Affiliation, bringing into View any other devices connected under the same affiliation. This individual could then find a compatible device, say, email, and using my email address which is supplied perhaps through a Connection to my email server, contact me directly. This individual would therefore have avoided going through my phone's contact list or call log, and they also would have contacted me directly - removing the possibility that whoever they did decide to contact would not have passed the message on to me.

A Clique Space(TM) value proposition.

What is Clique Space? How does it differ from anything out in the marketplace today?

This question is a nagging one that I haven't yet successfully explained. Here, I quote a piece of a letter I have just written to someone as an attempt to illustrate Clique Space's value. The boldface was added by me here in this blog entry.

Clique Space receives changes in the state of a Client Device which is connected using an Account that represents the individual responsible for that device's operation. The Connection thus formed is activated against an Affiliation so the individual can operate their Client Device in the Clique Space. An individual may obtain as many Active Affiliations for as many Client Devices as they wish, and may assign a level of access to [their Active Affiliations by] other individuals in a way that suits themselves, and any organisation which has created an Affiliation for them. Collaboration between two or more Active Affiliations are registered Cliques in which each Active Affiliation is registered as a Participant.

So, in essence, Clique Space is a user and collaboration activity modelling environment. Clique Space provides the opportunity to 1: collect information concerning an individual's use of one or more Client Devices they are operating, and 2: control the way these Client Devices behave in respect of the individual that is operating them, and the organisation that the individual may elect to be representing while they are operating them.

I do not intended Clique Space replace any existing transport mechanism, nor do I intend that Clique Space would replace an access control layer. It would use what is already there to support Clique Space's intended purpose. Indeed, an existing system may create the equivalent of Accounts, Media Profiles, and Account Profiles. These comparable entities would manifest themselves within Clique Space so that Affiliations can be assigned and Connections and Active Affiliations can be obtained.

How's that? Let me know...

Clique Space(TM) and more development.

Yet another development update.

I have decided to delay implementation of the Agent Collaboration Clique Space for now because the Clique Space semantics have still to be sufficiently developed, and a collaboration of cooperating agents is not something that I'm trying to prove. It'll come later.

So, currently, I can get a Client Device to connect, and can tell its Connection to disconnect. I can get the Connection to activate, and can tell the resulting Active Affiliation to deactivate. I can get this Active Affiliation to form a bipartite Clique with the Active Affiliation of the serving Agent Device, and I can tell this Clique to disband. In short, I've got a functioning skeleton for device connection semantics. It's looking good.

Currently, however, this communication is only from Client Device to serving Agent Device. I have a very strong idea of how I want to implement a system that alerts Client Devices in state and existential changes in the Elements they have obtained projections for. But for now, I'll implement (what perhaps is) a compromise solution that gets the Agent Device to alert connected Client Devices of changes.

This could be implemented before I present the prototype in March 11 at Wollongong uni. See this site for details.

Clique Space(TM) and NSW politics.

Again, another post (this time to an ABC television programme called the 7:30 report). I re-post it here because there is no guarantee at the time this blog entry was written that my post will appear there. It's 375 words long, and the web site to which I posted the original says that one's posts should not be longer than 100 words. So, at least I can guarantee that it appears here.

Here it is:

Mr O'Brien. I hope you'll excuse me for a reply that is more than 100 words; this is succinct as I could manage.

If you would like to discuss solutions to Australia's population and urban crises, you might like to include work from home in your discussion.

I am from Wollongong, and since I started in my professional capacity as a software designer, I have had to deal continually with the issue of displacement.

I like Wollongong, and I like software development. Almost 25 years ago, I took to software development as a career choice because I found that programming computers was an interesting and absorbing occupation that I could do from home.

Now, 2.5 decades later, I find that in order to participate in this career, one has to entertain what I consider the pathological association between this profession and a need to physically collocate. The consequence is ultimately to leave ones home town or to spend a significant fraction of one's life commuting from where one lives to an office desk where one works.

This is intolerable to me, and the antithesis of why I started down this career path.

If you like to get Mr Carr on your programme, and if you like to let him say the debate is over with regard to the building of concrete enclaves and sucking people into them, then maybe you might like to let me, another individual, take an opposing view, and let me talk about the troubles I've had in achieving my happiness - especially when such a man as Mr Carr, as premier of NSW, might systematically, with pernicious cajoling intent, thwart my goals in life and replace them with what he thinks they should be.

It is a pity that I cannot give you my email address privately so that you might have a chance to respond privately to my suggestion. However, rather than quoting my email address here, look up "Clique Space" (include the quotes) on Google. Do this, and you shall find a lot of information on a concept that would help managers and employees realise a virtual work-from-home environment. You will also find out how to get in contact with me, as well as a lot more about me.

Clique Space(TM) and yet another blog entry.

After listening to an article on the news, I wrote the following to the person featured in it. I thought I'd share it here because I think it's a good letter, and I invite anyone else to act as the letter instructs. The only thing I have done to change the content is to remove the first few sentences that could identify who the recipient might be. I do respect people's right to anonymity.

Here it is:

I have invented something that I have called Clique Space, and I would perhaps like you to indulge your imagination on just what it does, as there is no practical implementation of the technology [interjection: just yet - though at the time this blog was put up (a day after this letter was sent) I am tantalisingly close]. I am putting a proof-of-concept together between writing emails to people like yourself about it.

Imagine a system where you can connect any personal device you possess to it. Other people do the same. You connect each device to it through an Account that represents you as an individual. You can also elect to represent yourself, your employer, or any other club or association you might be a member of, and this representation acts as a way to limit the visibility of the devices you have connected to others, and maybe also the way these devices interact. This is basically what Clique Space does.

I believe Clique Space is not a Google anything, an Apple anything, or any other type of anything, but I do think that the anythings one possesses can be connected to a Clique Space so that the devices can be controlled, and so individuals can take device activity audit logs of any interactions they may have through the devices while they are connected to a Clique Space. Clique Space does not replace the mechanism that devices already use to communicate, so it isn't a middle-ware anything either.

I have, for a very long time thought that this idea is a sorely needed piece of a device integration puzzle that will become more obvious as time moves on, and so, I have registered an international patent for the technology. I'd like to know from you whether you think my idea might offer the same promise.

No one's really bashing down my door to help me implement this system, but I think that's because I'm one person who chooses, for lifestyle reasons, not to go to where the action might be. Hence, I would also like to know if you might to perhaps write about it. I can give you more info on Clique Space.

Get back to me when you can.

Thanks,

Owen.

--
www.cliquespace.net
Clique Space(TM) Facebook Group: http://www.facebook.com/group.php?gid=81335296379
Owen's Garden of Thought: http://owenpaulthomas.blogspot.com/

Clique Space(TM) and collaborative devices.

All Client Devices are collaborative for by definition, they collaborate with Clique Space. Because a device would (also, by definition) become a Client Device if it were capable of obtaining a Connection with a Clique Space, any such device can therefore be called collaborative, even if the only thing it is collaborating directly with is a Clique Space system.

In the abstract of my research report on Clique Space, I said that Clique Space models device collaborations over an arbitrary number of media. I have always considered Clique Space a type of medium, and the Agent Devices that make a Clique Space system to be Client Devices that collaborate in a Clique Space. I have steadfastly asserted that a Clique Space can be modelled inside itself or another Clique Space as a Clique where the Participants are the Agent Devices.

Hence, I intend any device that can be connected to a Clique Space - including devices that are not collaborative per se to be collaborative merely for the fact that each Client Device is collaborating with the Clique Space system. A car, a golf ball, a washing machine, a rotorlacter, etc. (if any can be connected to a Clique Space) are collaborative devices.

Implementation Progress of Clique Space(TM).

Reporting on very good news. Every time I get a piece of Clique Space functioning, I continue to be bolstered by the prospect that this concept might actually work. Right now, the (to-be Clique Space administrator) Client Device can create a Clique Space representing itself, and can obtain a Connection to an Agent Device's Clique Space and an Agent Collaboration Clique Space from an Agent Device. I have been able to do this for some time in earlier iterations, but only now am I reasonably confident that I am doing it correctly.

Currently, I cannot disconnect from these Clique Spaces; I believe this is a trivial enhancement, and is one that has been working in previous iterations.

Now, I've partially integrated the Agent Collaboration mechanism into the Agent Collaboration Clique Space. Much of the Agent Collaboration concept was realised by last April when after that date, I began to put together the Clique Space. So, the Agent Collaboration was put aside from then until now, but I have returned to it and am using the lessons I learned about the implementation of the Clique Space to integrate the Agent Collaboration.

So, I think I almost have the framework of a proven concept. Once I have integrated the Agent Collaboration, I believe I can expose Agent Device functionality in a collection of Enabling Constraints which are associated with the Media Profile of the "Remote Client". The remote client is the first Media Profile, and encodes the functioning of the Agent Device itself.

Every component here except the Enabling Constraints has been implemented, but I remain confident that the Enabling Constraints will have their deliverance.