Owen's garden of thought.

The self-organising Clique Space(TM).

2012-02-09T03:36:00.000-08:00

I have seen how Clique Space organises itself. The specification I have patented, and am in the process of implementing indeed describes a self-organising system of Agent Devices; devices which behave in any sense I know of, exactly as I imagine neurons behave.

I have just glimpsed a solution regarding message dissemination through a Clique Space, and believe that the solution I have glimpsed will shortly be implemented. It is robust, instantly reconfigurable, and is composed of parameters which can be adjusted completely independently of "human" intervention.

I think it entirely possible that a Clique Space that knows "itself" is not only capable of autonomously organising its member Agent Devices, but also of autonomously sustaining this organisation. And to think that all this comes merely from a simple data model.

There you go; thoughts that send shivers down spines.

Human Habit and the Stupidity of the Office Block

2012-02-02T20:45:00.000-08:00

Let's commune a bit about human habit, for it is merely human habit that prolongs the stupidity that is the office block.

Now, an individual is born and raised in a society where notions of being a responsible member of society are instilled at the earliest of ages. This has been so for a very long time, and is indispensable in the maintenance of a coherent society. However, any such notions as tradition can have an undesirable side effect: they delay the societies adaptation to change, even when the potential for change has come about from an aggregate will to see change. Change, sometimes when achieved, is denied by appeals to tradition.

An individual leaves school, and finds themselves a job. Usually (it seems to be the case in my observations) people dream of the cars, mortgages, and families. People take their lead from those who have come before them; they accept many of the behaviours of earlier generations as being exemplar to the way they should behave in order to realise their "individual" dreams. People can accept too much.

So, people who accept that the office is the place where work is done, and the home is the place where life is lived have in all but a very few cases, tacitly complied with a social convention; they have not exercised their own will, and in most instances without necessarily thinking what the implications are. However, when I was 12 years old, I wasn't comparing and contrasting modes of work; I had merely observed promise in a way to relate to the necessity of work so it would pay dividend for me, and I found that promise existed in working as a regular employee for a large corporate employer in my own space, time and intensity needing only to concentrate on issues relating to a profession that interested me.

Others had since surrendered the promise of a similar relationship to the work they do because the command and control structure of work conspired with their need to fulfil other priorities of their lives. Others don't necessarily "decide" to give up the promises they make to themselves, they just adopt conventions because devoting thought to alternatives required an effort they couldn't have priority for. It is (possibly more) true that most also do not have the wider social support to help realise these alternatives. I have observed that society has built a form of systemic slavery where those who work, only do so because they accept the way work is done: from an office, and at a time and intensity which is determined by a set of long ago established conventions that place the ability to perpetuate this system at the discretion of the whims of a few individuals; not necessarily because this system works in any way that benefits all the interests involved, but rather, just because things are just done this way so to make more of the same things so to perpetuate this way of doing things.

I observe the wish of raising a family to be the most compelling motivation. I too, feel such desires, though perhaps they are not strong enough to compel me to act on them. In exercising one's individual wish specifically to have a family, individuals are most compelled to accept the choice presented by social convention: to accept the way things are in terms of how they are going to work, and to teach their kids likewise, or not to have a family. For individuals who want the former, the choice to adopt a conventional relationship to work is not a conscientious decision; this is the acceptance of a convention that is maintained through a contract between one generation and the next. Such a contract is based on very little more than the very dark motivations of blackmail and coercion that, while enforced from one generation to the next, are not moral teachings; they are nothing more than coercive habit.

Hence, individuals accept that work is done in an office, life is lived at home, and social structures (regardless of their actual benefit or detriment) are formed around these tenets. Cities grow, and draw people into ever higher population densities because people are drawn together by working conventions; not because working this way is an aggregate exercise of individual desire. Some may have a genuine desire to work and live in accordance to this arbitrary convention, but for a majority, it is merely a tacit agreement accepted only because most individuals can tolerate this behaviour and most are tolerating it only because they need to so to meet other priorities; raising a family prominent among these.

Raising a family unfortunately inculcates the same acceptance in their offspring. Those who hold a genuine desire to convention are often looked at with envy and their ideals are promoted, even though most individuals do not desire to adopt the life of a few - they just desire to enjoy their life as those individuals who readily desire convention appear capable of.

So, where do I fit in? Well, if I don't start a family and accept the way work is done, it looks as if I don't.

Yea... um... then give me my disability pension (I have an acquired brain injury which appears to explain why I am averse to collocation) and fuck off. But I've got a lot of time on my hands. Hence, I'm going to continue heckling your good selves because I've got to do something with, say, the next fifty or so years or things are going to be rather boring. I could terminate my life (if I put my mind to it, I can make sure you won't be able to stop me) but then the question of whether society can break with the convention of the office block goes on unanswered. If you think this question should continue unanswered, then I might label your good self with such phrases like "arrogant pig", "wanker", and "profligate bastard".

So people. My apathy, and the extent to which I feel forced to distance myself from this particular society of convention is but a symptom of my behaviour which is deemed for arbitrary reasons, to be unacceptable. I have chosen not to select the convention of working habit because I see no way for these habits to bring happiness to me. Any participation at any intensity in any collocated love-in is, at its idealistic best, a zero sum for me. However, notions like "deployment" are introduced which conspire to drag my arse involuntarily around this planet entrapped in chronic "cosmopolitan" transience. There appears to be a consequence for the fact I do not wish to take on working mode prescribed by this convention; I am chronically isolated. I receive much less than I need to feel welcome in other peoples' society.

My friends. I think you will hear a bit more of what I think about collocation. As my implementation of Clique Space(TM) continues to evolve, I may yet be able to underscore the fallacy of collocation: a stupidity that stupid people have inserted into what would otherwise be a good vocation for me.

Let me work from home part time.

2012-01-28T18:30:00.000-08:00

No more delay, prevarication, empty promises. Your placating lip-service only angers.

Open your eyes; wake up; face the truth; come to heel.

Another exorcism.

2012-01-27T21:25:00.000-08:00

I want to work in a part-time job (20 hours pro-rated full time weekly earnings) from home (95%+ of my time in a location of my choosing). Up to now, I have been a one-time employee of IBM. I left IBM because I appear to have a personality that does not lend itself to a full-time job in an office cubical; at least a personality that does not spare me a nervous breakdown if I try to participate in this mediocrity.

So, here's the letter I wrote to IBM, about 40 politicians and public servants, and a lawyer:

I charge IBM with the following:

Innumerable counts of tacit complicity to participate in a system of moral sterilisation; of removing the ability for people with personality traits labelled as undesirable to make a worthwhile contribution to the society within which they exist.

I intend these allegations to be met with the full legal and political weight. I expect there to be corrective action in relation to these allegations. I expect IBM to be held as an accountable example of this systemic behaviour. I expect IBM to come to heel.

Owen.

--
Employment-from-home. Make mine part-time.
You've go a job for me working full-time from an office? No thanks.
Clique Space(TM). Practical, Ubiquitous, Individual, and Real-time Security and Identity in Cyberspace.
Research paper on Clique Space: http://ssrn.com/abstract=1714848
Owen's Garden of Thought: http://owenpaulthomas.blogspot.com/
www.cliquespace.net
Skype: owen.paul.thomas
Mobile: +61/0 401 493 433

I want to work for IBM again, but I do want to work in a way that works for me, and I want IBM to accept that it has work that I am particularly suited for - something I have known for 26 years.

A demonstable prototype: what is really left to do?

2012-01-25T20:46:00.000-08:00

My last post gave some of an indication as to how I think I'm travelling with the implementation of this Clique Space(TM) concept. My last post got me thinking about how I can express my progress in this journey, and I have come up with 6 basic criteria that I think can express this progress.

Does it work?

In asking this question, I purposely limit scope to the core implementation. It works when I have successfully implemented the concept in a prototype. To this end, I believe I have almost done this; the only component I have to implement here is the Agent Collaboration's pulse message - the mechanism that exchanges information between Agent Devices which are members of a Clique that is used to disseminate knowledge about the operation of a particular device collaboration in some medium. The first device about which knowledge will be disseminated will of course be the Agent Device itself, the first collaboration will be a Clique Space within which a given set of Agent Devices will all be members, and it looks like the first medium will hence be encoded in what has become known as the "collaborator Media Profile".

Actually, the collaborator Media Profile might in some technical sense actually be the second Media Profile if one considers that the "engager Media Profile" has a model that can be divorced from its implementation, which I don't think one can honestly do. However one can observe an Agent Device's local Clique Space as if it were modelling a collaboration between itself and other Agent Devices it has engaged. The thing about the engager Media Profile is that it is part of an individual Agent Device's transport mechanism, and hence doesn't technically model a collaboration, but rather, lists other partner Agent Devices through which the given Agent Devices exchange information through a "synapse". The true media used by Agent Devices to model collaborations as members of a Clique Space is encoded as Enabling Constraints in a Clique Space's collaborator Media Profile.
Does it look pretty?

Probably not currently. This question relates to how "user friendly" the administrator Client Device's View is. Practically, this criterion relates to how easy it is to make others understand what Clique Space is all about. I would like to have a graphical user interface front-end because this will certainly lower the bar of comprehension; a GUI that displays two or more devices collaborating as two or more hexagonal Participant Chips inside a bounding ellipse representing a Clique will certainly help.

However, I do think the console output is quite consistent, and I should, absent the GUI, be able to use a whiteboard to manually draw a View's contents as I am demonstrating it to prospective venture partners.
Is it stable?

No. Putting the Clique Space concept together (putting anything not hitherto done before together) requires one to be very selective in what one does: one really has to put something together that does the first intended purpose before one makes it work across a range of adverse environmental conditions.

Major considerations revolving around stability include how the system deals with devices that behave erratically or inconsistently among the other devices with which they are collaborating. As a special case, what happens when a Clique Space's member Agent Device behaves erratically, or inconsistently, or abruptly goes off-line? As a special case of this, what is done when a Clique Space's owner is lost? Another consideration about the stability of the Agent Collaboration will be how to disseminate knowledge about the collaboration's state to all members when those members could number in the hundreds of thousands or more. I have some ideas along these lines, but their implementation will have to wait until I 1: get it to work.
Is it secure?

No. However, I have found that while I was implementing things like the Agent Device's engager semantics, at least some of these considerations perhaps dissolved. When two Agent Devices engage, they exchange information about each other's local Agent Device Clique Space, and this mechanism can guarantee confidentiality provided, of course, either or both Agent Devices do not leak this information to other parties of adversarial intent.

In terms of the collaborator Media Profile, whatever standard encryption and other security mechanisms are available can be fitted as time, and needs dictate. Yet other Media Profiles can in turn encode information about other, more or less powerful collaboration security, which at the very least, should be a clear demonstration of how flexible Clique Space is as an identity and collaboration metasystem... now there's a good term.
Does it really work?

No. In this question, I'm asking myself whether it works beyond its core implementation. Clique Space models and can (or rather, should be able to) control any existing or future collaborative device provided any particular device type can, at least, collaborate (with the purpose of exchanging state and control information) with a Clique Space Agent Device. Clique Space is completely useless if it isn't used along with other devices. Hence, at this moment, Clique Space is completely useless.

Truly, anything that can exchange state information with another thing is a candidate device. Should any type of thing in fact be capable of exchanging sufficient information to the extent that it can be modelled and controlled by a Clique Space system, then indeed, a Media Profile can be developed for that type of thing(device, as earlier described) so that any instance of it can be expressed along with the individual who has nominated themselves as the controller as well as any operational parameters and privileges associated with the thing instance and the individual who is controlling it.

A Clique Space that really works will work with phones, PC's, cars, flippers, fridges, email clients, email servers, Facebook accounts, space shuttles (or their successors), teleporters, Second Life avatars, kidneys, brains (possibly as Clique Spaces in their own right), and bank accounts, etc. Currently, Clique Space only knows of the Agent Device and the administrator Client Device.
Is it useful?

Maybe. This is a question of value that I alone cannot answer. The answer is provided by you and sufficient others who would find a use for it in their lives. The above criteria will be necessary but insufficient for you to decide that it is useful. Maybe you don't like me and hence you may boycott Clique Space.

I hope you don't hate me, but if you do, I hope you still find Clique Space useful. Let me know if I can do anything to help you make up your mind about me, Clique Space, or both me and Clique Space. I would welcome your feedback and the chance you might provide for me to address questions you have about me, about Clique Space, or about me and Clique Space.

A demonstable prototype: what is left to do?

2012-01-13T22:51:00.000-08:00

Clique Space(TM) is almost at a demonstrable state; at least this is what I feel. The Agent Collaboration's pulse message is something that needs to be done to get it to this state.

The Agent Devices still lack what is necessary to collaborate. The pulse message is still swimming around my head as a set of ideas that have not found a place to roost. As much as can be told, engaged Agent Devices send pulses to each other. These pulses will either alert collections of collaborating Agent Devices to the change in a Clique's state (additions or deletions of Elements) or changes in an Element's state (additions or deletions of Limiting Constraints). My most recent SVN revision committed a start on the pulse message, but still, some thought will have to be applied to the specific utility of the variations of pulse message that will be necessary. This will take some time.

My current concern (I'm hoping one revision will solve it) is that I want to move the declaration of the undisclosed Element from the Client Device project to the shared Clique Space project so the Agent Device can capitalise on the use of the undisclosed Element.

Everything else described below has to do with the concept's implementation once the proof-of-concept has been achieved.

Late 2010, I put a blog entry together like this one estimating how far I thought I had to go. I actually don't think I am much further along now than what I said in that entry, but casting my mind back to that time, I can say that my progress from that point in time has been significant. The current system is certainly next to useless in terms of the fact that Media Profile customisations are necessary to make some of the more popular media Clique Space aware. Nothing has changed currently.

Certainly, the implementation is still ugly. The administrator Client Device still doesn't yet have - because I haven't prioritised time to put in - a nice graphical user interface, although I feel significantly more comfortable that the console output it is giving me now makes more sense than it did back in October 2010. My greatest feeling of progress from 2010 has been in the degree to which forming, joining, leaving and disbanding Cliques have increased in their flexibility.

Agent Devices are still fragile and inflexible; they lack even rudimentary logic necessary to maintain a stable Clique Space in environmentally adverse conditions (mainly because they lack an implementation of the pulse message), and I have still to host different Agent Devices on different machines although I have delayed doing this because of the fact that I believe it is a trivial consideration. Progress has perhaps been made on memory performance and hygiene, and some concurrency control has been implemented although anything approaching true transaction logic is perhaps still a while off.

I am finding that when implementing such things as the Agent Device's engage/disengage semantics, it at least appears that concerns around security are being watered down by mechanisms that have been necessary for implementation.

Continue...

Clique Space(TM): Devices, Client Devices, and Agent Devices.

2012-01-09T21:05:00.000-08:00

I've been reading over some of my blog entries and believe that, again, I need to reinforce the relationship between these notions. So, I'll try once more to be reasonably consistent about this.

A device is anything that can exchange information relating to its own state with something else.

A Client Device has a structure within Clique Space which is composed of seven (very probably to-be 6) Clique Space Elements. A Client Device represents any device in Clique Space... any device at all.

An Agent Device is just a specific type of device, and therefore is expressed in Clique Space as a Client Device. An Agent Device is a device to which any device can connect (yes, including other Agent Devices) to get Access to one or more Clique Spaces. Agent Devices connect to each other so they can communicate information between themselves as members of a Clique Space, or to share information between Clique Spaces.

Agent Devices establish communications channels (which appear to me to be logically similar to synapses) by engaging each other and exchanging information about each other's Agent Device Clique Space.

Clique Space(TM) Progress Report.

2012-01-02T06:27:00.000-08:00

Alright! I think I've reached a point where the Client Device's behaviour is basically stable and dare I say... complete in terms of a functional proof-of-concept.

Five minutes ago, I have apparently managed to put in code to do something I thought would be rather tricky. Although the code is perhaps obscure, a total of only 9 files were lightly changed. What I have managed to do is to get the Client Device to ensure that no duplicate member Participant identifiers are instantiated within the VM whenever the Client Device receives information relating to changes in a particular Clique's membership.

Utterly wonderful. I will commit the code tomorrow. After committing, I actually think I can start work on the Agent Collaboration's pulse message... finally. Maybe not before too long, I'll have a very basic proof-of-concept capable of console output only. A GUI will come in time; it isn't a current priority.

Owen.

Clique Space(TM) Progress Report.

2011-12-29T03:20:00.000-08:00

As of about five minutes ago, I just completed an iteration that involved re-implementing the Agent Device's disengage operation. Hopefully, these things are relatively stable and I can finally approach the Agent Collaboration's pulse message.

It is worthy of note that the engage and disengage operations differ in rather strange and curious ways. The engage operation is reciprocal: there are somewhat symmetrical programmatic structures in place for engaging Agent Devices; one for the initiator, and the other for the responder. On the other hand, the disengage operation is recursive; the same method that is called on the responder in reply to the initiator's request is called again on the initiator in reply to the responder's actions. Of course, the recursion stops at the initiator on the disengage call-back. Just how the engage/disengage operations are implemented is rather complex (it could be more complex than it needs to be), but I have tried to be as straightforward as I could. The code might be more complex than it needs to be because I travelled down a few blind alleys, and may not have completely removed work-around code when I could revisit it to put in the intended code after covering incidental issues. It might be the simple case that I was in a reciprocal mood when completing the implementation of engage operation and in a recursive mood for the disengage operation.

Maybe one day, if the implementation becomes open source in some way, a million or so brains will pack down the footprint.

Looking good...

Some sense from this morning's dreaming.

2011-12-27T12:54:00.000-08:00

In the morning he awoke!... suddenly; transfixed on a vivid dream (one for which he hesitated to label a nightmare) about the deprivation wrought by his mother's inevitable descent into senility; about the consequent loneliness which would render him truly disabled. He discarded the thing that drew metaphor as he lie there only half conscious - brought into life by this same thing that drew his possible future into his present moments. It was a warm summer's morning; too warm for a quilt which, for lack of a bed sheet, he had draped over his soon-to-be middle-aged but otherwise well-fed frame. Time, after only three and a half hours of sleep, to get up. Time to peer at his computer to watch the unfolding kaleidoscope of his own creation; that prism of infinite beauty, of infinite strangeness that he at least thought was infinitely beautiful and strange.

He hesitantly embraced his dream for he had been taught by experience not to respond to the echoes of promises long ago formed. These promises - the ones that similar dreams said would boldly rescue him from his inevitability - contort his life into anathema. In time, and by the actions of intent, these promises would evolve: evolve to something that might save him from his inevitability; evolve to something which might at least distract him long enough perhaps for him to remain ignorant of how screwed up his life had become before inevitability would wash his cares for life away; evolve to reveal to him the banality of the pursuit for distraction; evolve in time to become that which, for want of his childhood comfort - a comfort that could have sprung from an accident in late childhood - he desperately avoided; evolve to have no meaning beyond a beautiful and strange anathema: something he foresees making no discernible difference at all to his inevitability.

Long since become a man in at least the physical sense, his mind was awash with the cynical intent of too many other men (and perhaps a few women). Perhaps some of these individuals had only a wish for his happiness as their intent; but apart from his mother (and his father - he hesitates to use the word "perhaps" because it is at least his father as much as it is his mother), one simply cannot lift this nature from their actions. His kaleidoscope still flashes its images of infinite beauty in his head; images which he still feels compelled to form sentences with and implement code on honour of. His mind is still seeing promises; promises without delivery; promises that an outwardly capricious though inwardly patient world of razor sharp intent might, he reckons, want him to make to himself as a child. The promises he observes now feed a desire to remake his world - a world of hedonism; of compulsory consumerism; of the paradox of inescapable slavery expected of him from the society in which he exists. He wants his world to become a world of silence without loneliness; of an individual's freedom to have his command to "fuck off" be respected. As a child, these promises were made to him (are made to children still) because of the power they have to enslave. He hadn't grasped the cudgel of family life - perhaps he was too scared; perhaps he understood too much of the promises' origin - so perhaps society's promises were over-made to him. He almost feels resigned to this as the natural order of society. He thinks the use of the word "almost" is an important distinction to make as to the state of his mind on the matter.

Quids are played without the pro quo's that he hesitates to think he is entitled to because he questions whether he has truly offered anything to the society in which he exists. Such an uncertainty as whether his quid deserves a pro quo might be the tool a society uses to get him to deliver more and expect less in return. He examines his conscience, and comes to the conclusion as a 37 year old man, that he has tried his best.

He is now, perhaps, almost willing to accept an hypothesis that the accident from his late childhood may have contributed significantly to the current circumstances. Even with the certainty that tales of one Kurt Friedrich Gödel gave him, his work still needs to be... complete. What better way to complete this work than without the distractions of societal expectation? Why now, he asks himself, reclined in his comfy chair of philosophical lugubriousness that his disability pension pays for, would he want to sacrifice these circumstances for even an hour per week of part-time telework? Why now when society might pay for his work's completion? Why, indeed, would he want to sacrifice his pension for the promise to see the wealth that the completion of his work could render unto him?

He reacquaints himself to his philosophy about promises.

He completes his blog entry, wishing the world would "fuck off", but perhaps is almost resigned to the probable inevitability that it might not do this just yet. Maybe his resignation is, in a way, an attempt to fend off the wolf of loneliness at his door. This man hopes that inevitabilities unfold in their appropriate sequence and through appropriate circumstance.

Clique Space(TM): appropriation without consideration?

2011-12-16T20:04:00.000-08:00

Before I embarked on proving my idea in July 2008, I asked myself what chance was there for me, an individual who has neither strong connections with nor direct access to people with means to help develop Clique Space, to have my claim to my idea recognised as such by the society within which I exist? By what means am I, one person in this world without direct access to appropriate legal measures, able to defend myself against others who may come to desire the appropriation of my idea?

There doesn't appear to be much I can do. I've got to tell others what I am doing, or no one will know. I've got to disclose enough of my idea to others so that an interest may be generated. I have to do this with the hope that the interest I may generate returns a consideration for my endeavours at a future point in time.

Hence, I have disclosed and re-disclosed my concept. The fact that this world has not registered much of an overt interest over these repetitive disclosures might be frustrating to a younger Owen Thomas. Yet as a 37 year old man, I have come to bare witness to an ocean of astonishingly perverse frustration wrought by the collective action of others. Whether borne of ignorance, sentimentality, perniciousness , fatalism, hubris, or a combination of all of these origins, the machinations one feels the world capable of exacting on me might consume the invention and me as its inventor in a whirlpool of frustration. I hope philosophical detachment might be enough to keep my sanity should these wrong things be done to me.

So, I've got to do my best to steer away from this inevitability. Disclosing, re-disclosing, and re-disclosing again is in a way, an attempt of mine to openly lay claim to these ideas. This blog, and everything else that I might put in the public domain are attempts by me to rid any with malicious intent simply appropriating this idea. I've done my best, with a PCT in January 2008, and national phase registration in Australia, New Zealand, and the United States a year after, to enshrine the idea in patent form. I simply didn't have enough money to register in other jurisdictions before the PCT period lapsed; the cost was about 15 thousand dollars to get what I got.

I intend to continue disclosing my concept, and any future significant progress I make in my implementation. I simply appear to have no other protection against appropriation without consideration. It would be the right thing to do if others, inspired by my concept, would get back to me. It would just be the right thing to do.

While my implementation is my property, and my implementation still remains to be legitimately disclosed in the public domain, distribution of my property amongst others with the capability to help me develop it is a condition for which I am willing to negotiate.

Hence, you needn't try to figure out what I have put together by reading my public disclosures; it won't be as profitable a proposition for you than approaching me would be. I believe I will shortly be able to demonstrate that I have done it. In the next months, I believe I will be able to demonstrate that my concept works. As far as I know, your understanding of my concept may still lack salient features, facts which I consider trivial, and have glossed over. Being that I cannot read your mind, I cannot know what you need to know. I think it would be easier for you to talk to me, and together, we can work out how to deliver Clique Space to a global market.

Early this year, I disclosed much of the functionality of Clique Space in this Oracle forum. In this particular example of a disclosure as with any other disclosure that I have made, I am attempting simply to elicit interest in it by people for whom I consider may have the ability to help in some way; coders, especially Java coders, being my target in the Oracle forum.

Before I finish. I note that this week's blog activity shows quite a few page views coming from Russia. I dare not follow links of referring sites lest they contain something undesirable. If some one or more people from Russia wish to know more about Clique Space, I would sincerely welcome their getting in contact with me.

What it's all about.

2011-12-10T07:59:00.000-08:00

Everything a device. Everyone an individual.

Clique Space(TM) makes it possible because of self reference.

It could be Haiku, but probably not.

OPTUML: A Slightly Saner UML

2011-12-10T05:37:00.000-08:00

Introducing OPTUML. It stands for Owen Paul Thomas's UML. Here, I talk about a difference in OPTUML class diagrams to the whatever other UML standard says is true.

A slightly saner version of UML (1 or 2 - who cares) that rids the developer of the rectangular interface from their class diagrams. That's right, all interfaces now use a circle - they use a larger circle if they list information such as method names. One needn't use a circle that encloses their interface's contents because this is almost impossible to do. One draws their circle large enough to make it clear to the viewer that they are looking at an interface, and reserves philosophical resignation about the dilemma of intersecting lines.

In addition, dashed lines on block-arrows indicating an implements relationship have now been filled in; you know you are implementing an interface when you see a block-arrow that starts at a rectangle and points to a circle instead of a rectangle which, by virtue of the fact that all circles are interfaces and all interfaces are circular in OPTUML, now exclusively means you are extending a class.

A block-arrow that starts at a rectangle and points to a rectangle indicates a class (to which the arrow is pointing) is being extended by the class where the arrow originates. Likewise, a block-arrow that starts at a circle and points to a circle indicates that an interface (to which the arrow is pointing) is being extended by the interface where the arrow originates. Block-arrows originating from circles do not point to rectangles; this is officially naughty.

Abstract and final classes are indicated by an "abstract" or "final" stereotype (in guillemets, which I can't do using greater than and less than signs in HTML, and couldn't be bothered finding the characters in unicode or whatever - curse HTML; curse everything). Abstract classes remain rectangular because they are still classes... in Java at least. I have dismissed multiple inheritance because I am currently programming in Java and find the singular inheritance thing much simpler.

Because interfaces can extend multiple superinterfaces, more than one block-arrow can originate from a circle whereas (because Java says a class cannot extend multiple classes) only one block-arrow can originate from a rectangle. I love OPTUML.

I decree these rules now be adopted by the software development industry at large. Everything else in OPTUML is sweetness and light, unless I stumble onto something else in UML that gives me the shits!

Make it so.

PS: I don't love Java any more than I am repulsed by multiple inheritance; these things certainly do not give me a hernia.

PPS: Call me the great revisionist. I think I have stopped now.

Another letter...

2011-12-09T17:52:00.000-08:00

Firstly, my apologies go to Ray Kurzweil for naming him as the person to which the letter quoted herein was sent. I'm going back on earlier statements that I wouldn't do this because I didn't think it polite to do so, but I only wish here to point out that I have written to him about my concept. Any personal reply Mr Kurzweil makes to my letter will be treated as a personal reply.

This letter is also quoted because it restates the objective of Clique Space(TM) from possibly another vantage point. Explanations of what Clique Space is might not paint a picture in large brush-strokes so much as empty a large bucket of paint on the reader.

Here it is:

Hello Mr Kurzweil

I was interested in a recent interview you had with an Australian journalist and thought you might be interested in what I'm doing.

I believe I have come up with a way to construct a software system which behaves exactly like a nervous system. I've called it Clique Space. A Clique Space is composed of a cluster of one or more Agent Devices. There is no theoretical limit to the number of collaborating Agent Devices in a Clique Space, and I assert that each Agent Device functions like a neuron. A logical structure similar to a synapse is created when one Agent Device engages another. Message units called Elements are passed around and between clique Spaces through a packaging mechanism somewhat similar in logical consequence to neurotransmitters. Although all this has been merely a coincidence of necessity, I think the coincidence is curious.

I assert that this system will be able to model (and may even control) any device which is capable of connecting to and exchanging state information with an Agent Device in a Clique Space and represent this activity as some activity of an individual autonomous sentience which has claimed possession of a collection of devices thus connected. The interactivity of devices is modelled and perhaps controlled (limited by the way the particular device functions) as Cliques where each Participant represents an individual operator. As Agent Devices are themselves just a device, the way Agent Devices are modelled and controlled is no different to the way any device is ultimately modelled and controlled in a Clique Space; hence a Clique Space can be (and is) modelled within itself or another Clique Space as a Clique.

I appear to be a shunned inventor, and although I have been trying to elicit interest in my idea for three years, I have been working solo on this concept for at least this long. Although my proof-of-concept is still incomplete, I believe it currently can demonstrate to the educated onlooker that Clique Space is certainly plausible. Subsequent to my coining the term Clique (and apparently Clique Space for that matter), I have learned that current research in biological neural systems is beginning to gravitate toward these notions, and has adopted these terms to describe similar phenomena.

Clique Space(TM) Progress Report.

2011-12-08T09:06:00.000-08:00

Development has been progressing steadily for nearly 3.5 years. Now I'm observing a lot of the application logic coming together. I didn't realise that so many of the dilemma's I had thought I couldn't give time to get a handle on have appeared to resolve themselves. This thing's looking good.

For instance, I can call up any Element in my Client Device, and render it (currently only to a console display - but I feel confident this will apply equally to a GUI) at will, without having to tell the Client Device what type of Element it should expect. Such a thing only became possible since I implemented the identifier, transmitter, and renderer components. I'm almost ready to move back to the Agent Collaboration.

I'm going to commit this revision 494 to the codebase tomorrow. It's 4:30 in the morning, and I'm losing my sense of time's even passage. I'm going to put 15k under my pins in a slow easy jog tomorrow and I might even work Heaslip St into the routine which might push it closer to 20k - I'm getting a bit paunchy. Should stop pushing beef rogan josh through my system... I've let things slip.

The Undisclosed Element and the [Tendrils] of Code Coupling.

2011-12-04T22:43:00.000-08:00

I'll disclose some code here. It's my code, so I'm free to do this. These code disclosures are meant to elicit interest and hopefully a response by people who may be interested in what I'm doing. That's the theory; I don't know the reader's mind, but one hopes the reader is one who has scruples enough to honour the fact that this idea is mine, and who will respect the fact that I have patented it.

This post, and the code disclosed therein demonstrate how complicated structural parameterisation can sometimes be; something of what some have come to see as a nuisance about Java. Java parameterises classes and interfaces through a mechanism called generic declarations. There's a lot about what a generic declaration is, so I'll leave it to the curious - but hitherto ignorant - reader to discover this wonderland. However, I need to put the mechanism into context here: generics bind one Java element (object, class, interface) to one or more others. When a class or interface is declared with a generic declaration that refers to another class or interface, objects of both classes or interfaces are bound by a "contract" which depends on some mutually recognised generic property.

Now, all this means that one or more objects is being structurally bound to others - increasing the objects' degree of coupling. This doesn't appeal to purist doctrine but there are plenty of times where this structural binding is absolutely necessary. My seven-Element (to be six-Element eventually - but that's another story) Client Device structure is one of these times.

The Client Device is loosely based around an arrangement of seven distinct, but related, Element types. At least one of each of these Element types are necessary to express one Client Device. Hence, one should be totally unsurprised to imagine that there would be a high degree of coupling between these Elements. Each element encapsulates a property of any device which is connected to a Clique Space(TM), so each Element describes only a part of the Client Device. Hence, the Client Device (the abstract representation of any device in Clique Space) and its constituent Elements is a prime component of the Clique Space concept. This particular Client Device mechanism was the epiphany I had in mid-2004 while jogging.

Working with generics in my implementation, I can see why some might become dismayed with what can sometimes become an intractable exercise that generates compile-time errors of sometimes frustratingly obscure origin. It almost seems that even a powerful IDE cannot help ease one's frustrations when it comes to getting code involving generics to compile. The relationships generics create do not appear to me to have an easily way to be visualised, so one really has to be careful and patient when one has to manage generic relationships between approximately 30 classes and interfaces - a structure not only as described, but a whole structure of subinterfaces, and their implementations for Elements as they manifest on the administrator Client Device, and the Agent Device.

Still, if one exercises patience against a solid application model defined around a clear concept, one can navigate through what may seem like a maze of these coupling relationships.

The massaged code snippet that I disclose is of a class called an undisclosed Element. This class is intended to be a substitute on the Client Device for situations where information about projected Elements and their identifiers is known to be missing, and this information cannot appear on the device's View, or persisted to a device activity audit log. Hence, the undisclosed Element and its identifier are used as place-holders whenever an Element or its identifier are known not to be projected. Instances of non disclosure could be the result of a lack of Limiting Constraint affinity between the user doing the viewing and the user being viewed, or if the user of a device collaborating with others isn't themselves connected to the same Clique Space or a federated neighbour Clique Space capable of sharing information about the user being viewed, or where the operator of the serving Agent Device to which the View device is connected has insufficient Limiting Constraint affinity; even though the operator of the View device may themselves, have sufficient affinity.

Instances where Elements might not be disclosed include, say, a user who lets you know what device they're using, and how they're using it, but not who they are (one can see that the Active Affiliation, Connection, Affiliation, Account Profile, and Media Profile are disclosed, but no Account has been likewise disclosed). At other times, say, a user may let you know who they are when you're letting them know who you are in some situations. In these cases, the Account may be disclosed for times when the particular user lets you know who they are, but in situations where they don't, an identifier relating neither the connection nor affiliation to their account will be likewise disclosed. So near, yet so far... and so very flexible.

In any situations where partial or non disclosure of Elements is apparent, the Client Device substitutes its undisclosed Element. This Element must have an interface that is compatible with every type of Element. It must therefore be structurally coupled to each Element's interface, expressing specific behaviour of the undisclosed Element which is compatible with all of the other disclosed Elements in terms of how a particular undisclosed Element's type is represented.

So, here it is in all its syntactic glory - a compromise to accommodate the apparent limitations of this web log. I also think HTML is a distraction that is not worthy of me.

 39 /**
 40  *
 41  * @author owen
 42  */
 43 public class UndisclosedElement
 44 extends NonLocalElementImpl<
 45  NonLocalCliqueSpace<
 46   ?extends NonLocalElement,
 47   ?extends NonLocalAccount,
 48   ?extends NonLocalAccountProfile,
 49   ?extends NonLocalAccountProfileRoot,
 50   ?extends NonLocalMediaProfile,
 51   ?extends NonLocalMediaProfileRoot,
 52   ?extends NonLocalAffiliation,
 53   ?extends NonLocalActiveAffiliation,
 54   ?extends NonLocalClique>,
 55  UndisclosedIdentifier,
 56  IdentifierTransmitter,
 57  ElementToken>
 58 implements
 59  NonLocalAccount<
 60   NonLocalCliqueSpace<
 61    ?extends NonLocalElement,
 62    ?extends NonLocalAccount,
 63    ?extends NonLocalAccountProfile,
 64    ?extends NonLocalAccountProfileRoot,
 65    ?extends NonLocalMediaProfile,
 66    ?extends NonLocalMediaProfileRoot,
 67    ?extends NonLocalAffiliation,
 68    ?extends NonLocalActiveAffiliation,
 69    ?extends NonLocalClique>,
 70   UndisclosedIdentifier,
 71   IdentifierTransmitter,
 72   ElementToken,
 73   NonLocalAccountProfileNode<
 74    ?extends NonLocalCliqueSpace,
 75    ?extends AccountProfileNodeIdentifier,
 76    ?extends IdentifierTransmitter,
 77    ?extends ElementToken,
 78    ?extends NonLocalAccount,
 79    ?extends NonLocalAffiliation,
 80    ?extends NonLocalAccountProfile>,
 81   NonLocalMediaProfileNode<
 82    ?extends NonLocalCliqueSpace,
 83    ?extends MediaProfileNodeIdentifier,
 84    ?extends IdentifierTransmitter,
 85    ?extends ElementToken,
 86    ?extends NonLocalAccount,
 87    ?extends NonLocalConnection,
 88    ?extends NonLocalMediaProfile>,
 89   NonLocalAffiliation<
 90    ?extends NonLocalCliqueSpace,
 91    ?extends AffiliationIdentifier,
 92    ?extends IdentifierTransmitter,
 93    ?extends ElementToken,
 94    ?extends NonLocalAccount,
 95    ?extends NonLocalAccountProfileNode,
 96    ?extends NonLocalActiveAffiliation>,
 97   NonLocalConnection<
 98    ?extends NonLocalCliqueSpace,
 99    ?extends ConnectionIdentifier,
100    ?extends IdentifierTransmitter,
101    ?extends ElementToken,
102    ?extends NonLocalAccount,
103    ?extends NonLocalMediaProfileNode,
104    ?extends NonLocalActiveAffiliation>>,
105  NonLocalAccountProfile<
106   NonLocalCliqueSpace<
107    ?extends NonLocalElement,
108    ?extends NonLocalAccount,
109    ?extends NonLocalAccountProfile,
110    ?extends NonLocalAccountProfileRoot,
111    ?extends NonLocalMediaProfile,
112    ?extends NonLocalMediaProfileRoot,
113    ?extends NonLocalAffiliation,
114    ?extends NonLocalActiveAffiliation,
115    ?extends NonLocalClique>,
116   UndisclosedIdentifier,
117   IdentifierTransmitter,
118   ElementToken,
119   NonLocalAccount<
120    ?extends NonLocalCliqueSpace,
121    ?extends AccountIdentifier,
122    ?extends IdentifierTransmitter,
123    ?extends ElementToken,
124    ?extends NonLocalAccountProfileNode,
125    ?extends NonLocalMediaProfileNode,
126    ?extends NonLocalAffiliation,
127    ?extends NonLocalConnection>,
128   NonLocalAffiliation<
129    ?extends NonLocalCliqueSpace,
130    ?extends AffiliationIdentifier,
131    ?extends IdentifierTransmitter,
132    ?extends ElementToken,
133    ?extends NonLocalAccount,
134    ?extends NonLocalAccountProfileNode,
135    ?extends NonLocalActiveAffiliation>>,
136  NonLocalAccountProfileNode<
137   NonLocalCliqueSpace<
138    ?extends NonLocalElement,
139    ?extends NonLocalAccount,
140    ?extends NonLocalAccountProfile,
141    ?extends NonLocalAccountProfileRoot,
142    ?extends NonLocalMediaProfile,
143    ?extends NonLocalMediaProfileRoot,
144    ?extends NonLocalAffiliation,
145    ?extends NonLocalActiveAffiliation,
146    ?extends NonLocalClique>,
147   UndisclosedIdentifier,
148   IdentifierTransmitter,
149   ElementToken,
150   NonLocalAccount<
151    ?extends NonLocalCliqueSpace,
152    ?extends AccountIdentifier,
153    ?extends IdentifierTransmitter,
154    ?extends ElementToken,
155    ?extends NonLocalAccountProfileNode,
156    ?extends NonLocalMediaProfileNode,
157    ?extends NonLocalAffiliation,
158    ?extends NonLocalConnection>,
159   NonLocalAffiliation<
160    ?extends NonLocalCliqueSpace,
161    ?extends AffiliationIdentifier,
162    ?extends IdentifierTransmitter,
163    ?extends ElementToken,
164    ?extends NonLocalAccount,
165    ?extends NonLocalAccountProfileNode,
166    ?extends NonLocalActiveAffiliation>,
167   NonLocalAccountProfile<
168    ?extends NonLocalCliqueSpace,
169    ?extends AccountProfileIdentifier,
170    ?extends IdentifierTransmitter,
171    ?extends ElementToken,
172    ?extends NonLocalAccount,
173    ?extends NonLocalAffiliation>>,
174  NonLocalAccountProfileRoot<
175   NonLocalCliqueSpace<
176    ?extends NonLocalElement,
177    ?extends NonLocalAccount,
178    ?extends NonLocalAccountProfile,
179    ?extends NonLocalAccountProfileRoot,
180    ?extends NonLocalMediaProfile,
181    ?extends NonLocalMediaProfileRoot,
182    ?extends NonLocalAffiliation,
183    ?extends NonLocalActiveAffiliation,
184    ?extends NonLocalClique>,
185   UndisclosedIdentifier,
186   IdentifierTransmitter,
187   ElementToken,
188   NonLocalAccount<
189    ?extends NonLocalCliqueSpace,
190    ?extends AccountIdentifier,
191    ?extends IdentifierTransmitter,
192    ?extends ElementToken,
193    ?extends NonLocalAccountProfileNode,
194    ?extends NonLocalMediaProfileNode,
195    ?extends NonLocalAffiliation,
196    ?extends NonLocalConnection>,
197   NonLocalAffiliation<
198    ?extends NonLocalCliqueSpace,
199    ?extends AffiliationIdentifier,
200    ?extends IdentifierTransmitter,
201    ?extends ElementToken,
202    ?extends NonLocalAccount,
203    ?extends NonLocalAccountProfileNode,
204    ?extends NonLocalActiveAffiliation>>,
205  NonLocalActiveAffiliation<
206   NonLocalCliqueSpace<
207    ?extends NonLocalElement,
208    ?extends NonLocalAccount,
209    ?extends NonLocalAccountProfile,
210    ?extends NonLocalAccountProfileRoot,
211    ?extends NonLocalMediaProfile,
212    ?extends NonLocalMediaProfileRoot,
213    ?extends NonLocalAffiliation,
214    ?extends NonLocalActiveAffiliation,
215    ?extends NonLocalClique>,
216   UndisclosedIdentifier,
217   IdentifierTransmitter,
218   ElementToken,
219   NonLocalAffiliation<
220    ?extends NonLocalCliqueSpace,
221    ?extends AffiliationIdentifier,
222    ?extends IdentifierTransmitter,
223    ?extends ElementToken,
224    ?extends NonLocalAccount,
225    ?extends NonLocalAccountProfileNode,
226    ?extends NonLocalActiveAffiliation>,
227   NonLocalConnection<
228    ?extends NonLocalCliqueSpace,
229    ?extends ConnectionIdentifier,
230    ?extends IdentifierTransmitter,
231    ?extends ElementToken,
232    ?extends NonLocalAccount,
233    ?extends NonLocalMediaProfileNode,
234    ?extends NonLocalActiveAffiliation>,
235   NonLocalParticipant<
236    ?extends NonLocalCliqueSpace,
237    ?extends ParticipantIdentifier,
238    ?extends IdentifierTransmitter,
239    ?extends ElementToken,
240    ?extends NonLocalActiveAffiliation,
241    ?extends NonLocalClique>>,
242  NonLocalAffiliation<
243   NonLocalCliqueSpace<
244    ?extends NonLocalElement,
245    ?extends NonLocalAccount,
246    ?extends NonLocalAccountProfile,
247    ?extends NonLocalAccountProfileRoot,
248    ?extends NonLocalMediaProfile,
249    ?extends NonLocalMediaProfileRoot,
250    ?extends NonLocalAffiliation,
251    ?extends NonLocalActiveAffiliation,
252    ?extends NonLocalClique>,
253   UndisclosedIdentifier,
254   IdentifierTransmitter,
255   ElementToken,
256   NonLocalAccount<
257    ?extends NonLocalCliqueSpace,
258    ?extends AccountIdentifier,
259    ?extends IdentifierTransmitter,
260    ?extends ElementToken,
261    ?extends NonLocalAccountProfileNode,
262    ?extends NonLocalMediaProfileNode,
263    ?extends NonLocalAffiliation,
264    ?extends NonLocalConnection>,
265   NonLocalAccountProfileNode<
266    ?extends NonLocalCliqueSpace,
267    ?extends AccountProfileNodeIdentifier,
268    ?extends IdentifierTransmitter,
269    ?extends ElementToken,
270    ?extends NonLocalAccount,
271    ?extends NonLocalAffiliation,
272    ?extends NonLocalAccountProfile>,
273   NonLocalActiveAffiliation<
274    ?extends NonLocalCliqueSpace,
275    ?extends ActiveAffiliationIdentifier,
276    ?extends IdentifierTransmitter,
277    ?extends ElementToken,
278    ?extends NonLocalAffiliation,
279    ?extends NonLocalConnection,
280    ?extends NonLocalParticipant>>,
281  NonLocalConnection<
282   NonLocalCliqueSpace<
283    ?extends NonLocalElement,
284    ?extends NonLocalAccount,
285    ?extends NonLocalAccountProfile,
286    ?extends NonLocalAccountProfileRoot,
287    ?extends NonLocalMediaProfile,
288    ?extends NonLocalMediaProfileRoot,
289    ?extends NonLocalAffiliation,
290    ?extends NonLocalActiveAffiliation,
291    ?extends NonLocalClique>,
292   UndisclosedIdentifier,
293   IdentifierTransmitter,
294   ElementToken,
295   NonLocalAccount<
296    ?extends NonLocalCliqueSpace,
297    ?extends AccountIdentifier,
298    ?extends IdentifierTransmitter,
299    ?extends ElementToken,
300    ?extends NonLocalAccountProfileNode,
301    ?extends NonLocalMediaProfileNode,
302    ?extends NonLocalAffiliation,
303    ?extends NonLocalConnection>,
304   NonLocalMediaProfileNode<
305    ?extends NonLocalCliqueSpace,
306    ?extends MediaProfileNodeIdentifier,
307    ?extends IdentifierTransmitter,
308    ?extends ElementToken,
309    ?extends NonLocalAccount,
310    ?extends NonLocalConnection,
311    ?extends NonLocalMediaProfile>,
312   NonLocalActiveAffiliation<
313    ?extends NonLocalCliqueSpace,
314    ?extends ActiveAffiliationIdentifier,
315    ?extends IdentifierTransmitter,
316    ?extends ElementToken,
317    ?extends NonLocalAffiliation,
318    ?extends NonLocalConnection,
319    ?extends NonLocalParticipant>>,
320  NonLocalMediaProfile<
321   NonLocalCliqueSpace<
322    ?extends NonLocalElement,
323    ?extends NonLocalAccount,
324    ?extends NonLocalAccountProfile,
325    ?extends NonLocalAccountProfileRoot,
326    ?extends NonLocalMediaProfile,
327    ?extends NonLocalMediaProfileRoot,
328    ?extends NonLocalAffiliation,
329    ?extends NonLocalActiveAffiliation,
330    ?extends NonLocalClique>,
331   UndisclosedIdentifier,
332   IdentifierTransmitter,
333   ElementToken,
334   NonLocalAccount<
335    ?extends NonLocalCliqueSpace,
336    ?extends AccountIdentifier,
337    ?extends IdentifierTransmitter,
338    ?extends ElementToken,
339    ?extends NonLocalAccountProfileNode,
340    ?extends NonLocalMediaProfileNode,
341    ?extends NonLocalAffiliation,
342    ?extends NonLocalConnection>,
343   NonLocalConnection<
344    ?extends NonLocalCliqueSpace,
345    ?extends ConnectionIdentifier,
346    ?extends IdentifierTransmitter,
347    ?extends ElementToken,
348    ?extends NonLocalAccount,
349    ?extends NonLocalMediaProfileNode,
350    ?extends NonLocalActiveAffiliation>>,
351  NonLocalMediaProfileRoot<
352   NonLocalCliqueSpace<
353    ?extends NonLocalElement,
354    ?extends NonLocalAccount,
355    ?extends NonLocalAccountProfile,
356    ?extends NonLocalAccountProfileRoot,
357    ?extends NonLocalMediaProfile,
358    ?extends NonLocalMediaProfileRoot,
359    ?extends NonLocalAffiliation,
360    ?extends NonLocalActiveAffiliation,
361    ?extends NonLocalClique>,
362   UndisclosedIdentifier,
363   IdentifierTransmitter,
364   ElementToken,
365   NonLocalAccount<
366    ?extends NonLocalCliqueSpace,
367    ?extends AccountIdentifier,
368    ?extends IdentifierTransmitter,
369    ?extends ElementToken,
370    ?extends NonLocalAccountProfileNode,
371    ?extends NonLocalMediaProfileNode,
372    ?extends NonLocalAffiliation,
373    ?extends NonLocalConnection>,
374   NonLocalConnection<
375    ?extends NonLocalCliqueSpace,
376    ?extends ConnectionIdentifier,
377    ?extends IdentifierTransmitter,
378    ?extends ElementToken,
379    ?extends NonLocalAccount,
380    ?extends NonLocalMediaProfileNode,
381    ?extends NonLocalActiveAffiliation>>,
382  NonLocalMediaProfileNode<
383   NonLocalCliqueSpace<
384    ?extends NonLocalElement,
385    ?extends NonLocalAccount,
386    ?extends NonLocalAccountProfile,
387    ?extends NonLocalAccountProfileRoot,
388    ?extends NonLocalMediaProfile,
389    ?extends NonLocalMediaProfileRoot,
390    ?extends NonLocalAffiliation,
391    ?extends NonLocalActiveAffiliation,
392    ?extends NonLocalClique>,
393   UndisclosedIdentifier,
394   IdentifierTransmitter,
395   ElementToken,
396   NonLocalAccount<
397    ?extends NonLocalCliqueSpace,
398    ?extends AccountIdentifier,
399    ?extends IdentifierTransmitter,
400    ?extends ElementToken,
401    ?extends NonLocalAccountProfileNode,
402    ?extends NonLocalMediaProfileNode,
403    ?extends NonLocalAffiliation,
404    ?extends NonLocalConnection>,
405   NonLocalConnection<
406    ?extends NonLocalCliqueSpace,
407    ?extends ConnectionIdentifier,
408    ?extends IdentifierTransmitter,
409    ?extends ElementToken,
410    ?extends NonLocalAccount,
411    ?extends NonLocalMediaProfileNode,
412    ?extends NonLocalActiveAffiliation>,
413   NonLocalMediaProfile<
414    ?extends NonLocalCliqueSpace,
415    ?extends MediaProfileIdentifier,
416    ?extends IdentifierTransmitter,
417    ?extends ElementToken,
418    ?extends NonLocalAccount,
419    ?extends NonLocalConnection>>,
420  NonLocalParticipant<
421   NonLocalCliqueSpace<
422    ?extends NonLocalElement,
423    ?extends NonLocalAccount,
424    ?extends NonLocalAccountProfile,
425    ?extends NonLocalAccountProfileRoot,
426    ?extends NonLocalMediaProfile,
427    ?extends NonLocalMediaProfileRoot,
428    ?extends NonLocalAffiliation,
429    ?extends NonLocalActiveAffiliation,
430    ?extends NonLocalClique>,
431   UndisclosedIdentifier,
432   IdentifierTransmitter,
433   ElementToken,
434   NonLocalActiveAffiliation<
435    ?extends NonLocalCliqueSpace,
436    ?extends ActiveAffiliationIdentifier,
437    ?extends IdentifierTransmitter,
438    ?extends ElementToken,
439    ?extends NonLocalAffiliation,
440    ?extends NonLocalConnection,
441    ?extends NonLocalParticipant>,
442   NonLocalClique<
443    ?extends NonLocalActiveAffiliation,
444    ?extends NonLocalCliqueSpace,
445    ?extends NonLocalParticipant>>
446 {

Etcetera...

700 }

I will not disclose the entire body of this class. You might find that a relief, but I will at least disclose one of the overridden methods which contains a not uncommonly long signature.

541     @Override
542     public AffiliationIdentifier[]getAffiliationIdentifiers(NonLocalAccountextends NonLocalCliqueSpace,?extends AccountIdentifier,
543      ?extends IdentifierTransmitter,?extends ElementToken,?extends NonLocalAccountProfileNode,?extends NonLocalMediaProfileNode,
544      ?extends NonLocalAffiliation,?extends NonLocalConnection>account,NonLocalCliqueSpaceextends NonLocalElement,?extends NonLocalAccount,
545      ?extends NonLocalAccountProfile,?extends NonLocalAccountProfileRoot,?extends NonLocalMediaProfile,?extends NonLocalMediaProfileRoot,
546      ?extends NonLocalAffiliation,?extends NonLocalActiveAffiliation,?extends NonLocalClique>cliqueSpace) throws CliqueSpaceException {
547         AffiliationIdentifier[]afia={this.getAffiliationIdentifier()};
548         return afia;
549     }

Indeed, it's a bit bewildering, but apparently necessary. If you observe the relationship between the definition of this undisclosed Element and all the other Elements given in the class declaration, the pattern shows that the concept is strong, uniform, consistent, and efficacious. At least, that's what I'm asserting. Likewise, I assert this class discloses a very small part of an implementation of a novel and unique concept.

Client Device stabilisation.

2011-11-26T06:52:00.000-08:00

Apart from some "testing", one certainly feels as though the interface between the Agent Device and the administrator Client Device has reached a state of completeness. This is the best work I've ever done.

A big "Guten Tag!" to all my German friends. Let me know what you think about Clique Space(TM) some time perhaps.

The Clique Space(TM) Client Device is a Lie Detector

2011-11-13T01:38:00.001-08:00

Everything is a device in Clique Space. Agent Devices (those devices that make the Clique Space system) and Client Devices (any other device, including the administrator Client Device being developed in parallel to the Agent Device) are simply different devices to Clique Space. Agent Devices, being mere devices, are subject to the same control mechanism as any other device. This point is an important designed intention.

Agent Devices establish Connections amongst themselves through a process of engagement. The product of this process is something I have come to call a synapse - seeing as it appears remarkably similar to one of these.

Client Devices establish one or more Connections with one or more Agent Devices through a slightly different process, and although this process yields something similar to what the product for the Agent Devices is, the fact that the Client Device can engage with multiple Agent Devices (there is no real reason to say that a Client Device cannot engage a single Agent Device more than once, but I have yet to test such a scenario) allows the user of the given Client Device (should it be equipped with a View adapted to some medium) to detect lies.

Lie detection... how does this happen?

Well, the Client Device can't tell you who is doing the lying, but it can tell you that one or more of the Connections to the (serving) Agent Devices are sending information relating to one or more Elements that is inconsistent with one or more of the same Elements sent from one or more other of the serving Agent Devices; indeed, a form of lie detection. So, how does this work?

Summarily, Elements are sent from an Agent to a Client Device through tokens, and each token is kept by the Client Device until the token's serving Agent Device tells the Client Device to remove it. An Element is recreated as a composite of the different tokens. Hence, the term that I use to describe the exchange of a token: "projection" makes each token a little bit like a light beam projecting an image on to a screen. The more light sources one has, the more accurate one might expect the image to be.

Lies can be detected in two basic ways: 1. token inconsistency; should the details of any set of tokens describing an Element differ in ways that another set of tokens describe the same Element, then that Element is "token-inconsistent". 2. Element inconsistency; relating to the inter-Element relationships between two or more Elements, "Element-inconsistent" relationships become apparent when these relationships (say, between an Affiliation and its component Account) are found to contradict through Elements only once they are assembled. In the case of the Affiliation - Account relationship, this element inconsistency will become obvious if, when composing the Affiliation from its tokens, one or more of these tokens discloses a differently identified Account than the Account assembled from its tokens which is stating that it points to the given Affiliation.

In the case of the Element-inconsistent Affiliation - Account relationship, these relationships only become evident at the time of the Elements' assembly within the Client Device to which the tokens have been projected.

Such contradictions could point to some problem with the serving Agent Devices, but yet again, they probably also point to nefarious intent of the operators of the serving Agent Devices. So, if you're a Clique Space user, and you don't trust the opinion of the person operating a singular serving Agent Device, seek a second (or perhaps a third or a fourth) opinion and ensure safety in consensus through simultaneous Connections to multiple serving Agent Devices; preferably ones which each are operated by different individuals. No serving Agent Device's operator would (nor should they) ask that you only connect to a single Agent Device, or only restrict your connection to those Agent Devices operated by a given individual. If they do ask you, then just lie and say "of course I am".

Clique Space(TM) Progress Report. Another possible milestone... perhaps.

2011-11-10T03:42:00.000-08:00

Evolution.

My prototype Agent Device appears to have many of the functional attributes it needs to set itself up, project Elements to connected Client Devices (capable of viewing Elements), and respond to commands from an administrator's Client Device, itself capable of viewing Elements albeit currently only through console output. Very nice.

I have often likened programming to crochet; sure as I am are the similarities between a nicely crafted algorithm and a nice lace doily. Clique Space, however, is a veritable Persian carpet.

What use the Active Affiliation?

2011-10-09T21:35:00.000-07:00

I've been pondering whether the Active Affiliation serves any specific purpose for some time, having talked briefly about this subject before.

The Active Affiliation Element was intended as a kind of state-object that connected devices would acquire to indicate that the connection was authenticated. Devices that possess a View would then use their Active Affiliation to form a Clique with their serving Agent Device. Other devices that did not receive View information from the serving Agent Device would acquire Participants when engaged with relevant other devices in Clique Space, otherwise devices would possess a lone Active Affiliation when not engaged with other devices in any collaboration.

Now that I'm developing the concept, my understanding of the relevance of each of the pieces shifts and one consequence of this appears to be that I'm being drawn to the conclusion that the Active Affiliation is redundant, and the Participant can take on the intended 'authentication' purpose of the Active Affiliation implying that media spines might only have three vertebrae: the Media Profile, Connection, and Participant Elements. The serving Agent Device's Participant and the bipartite Clique in which both Participants exist, is generated for all devices -- the mode of which differs with the type of device and what state information it exchanges with the serving Agent Device through which the device is connected to the Clique Space in question.

All this leads more directly to the convenience, or rather, the very point of Clique Space: Cliques model collaborations. And because every device has to "collaborate" with a serving Agent Device, at a minimum every device must form a Clique with its serving Agent Device before any View or log-based device can observe this collaboration and discover other collaborations this device might be involved in which are being modelled (and possibly controlled) by the Clique Spaces over which their Cliques span.

Now, my proof-of-concept has been evolving for some time. While the removal of the Active Affiliation from the core data model will ultimately simplify the implementation, this procedure is to going to be messy. Obviously, I'm going to consider this issue for some time yet while other issues are worked through.

Clique Space(TM) administrator Client Device command grammar.

2011-09-25T19:33:00.001-07:00

After committing my last revision (I think it was 478) which has seen a stable implementation of the Agent Device disengage process, I decided it would be a good idea to map the assortment of commands available to the Client Device in a reasonably formal grammar.

The notation I have ascribed to is my own, developed as I put the grammar together; it should be fairly easy to work out, and although the elements "schema:label" form may lend itself to a meta-notation, I have not given such a schema the little consideration required beyond this because I don't currently care to.

Here it is:

command:=

command-clause:without-delegate|

{keyword:with value:delegate-identifier command-clause:with-delegate}

command-clause:without-delegate:=

command-clause:disband|

{keyword:list command-clause:list-without-delegate}|

command-clause:connect|

command-clause:show-or-hide-Clique-Space|

keyword:help|keyword:exit

command-clause:list-without-delegate:=

command-clause:list-Clique-Space|

command-clause:list-structure|

command-clause:list-Clique-without-delegate|

command-clause:list-Element-without-delegate|

keyword:rmi|

keyword:tokens|

keyword:cliques|

keyword:cliquespaces|

keyword:elements

command-clause:list-Clique-Space:=

keyword:cliquespace value:Clique-Space

command-clause:list-structure:=

keyword:structure keyword-clause:Element-type value:Element-identifier

command-clause:list-Clique-without-delegate:=

keyword:clique [value:Clique]

command-clause:list-Element-without-delegate:=

keyword:element keyword-clause:Element-type value:Element-identifier

command-clause:connect:=

keyword:connect value: Agent-Device-name

[keyword:accountprofile value:Account-Profile-name]

[keyword:cliquespace value:Clique-Space-name]

command-clause:show-or-hide-Clique-Space:=

keyword:show|keyword:hide value:Clique-Space-name

command-clause:with-delegate:=

command-clause:Particpant-adapter|

command-clause:Active-Affiliation-adapter|

command-clause:Connection-adapter

command-clause:Participant-adapter:=

command-clause:list-with-delegate|

command-clause:disband|

command-clause:join|

command-clause:leave|

command-clause:deactivate-other|

command-clause:form-other|

command-clause:activate-other|

command-clause:disconnect-other|

command-clause:create|

command-clause:destroy|

command-clause:Active-Affiliation-adapter

command-clause:Active-Affiliation-adapter:=

keyword:deactivate|

command-clause:form-self|

command-clause:Connection-adapter

command-clause:Connection-adapter:=

keyword:disconnect|

{keyword:activate command-clause:activate-self}

command-clause:list-with-delegate:=

keyword:list command-clause:list-Clique-with-delegate|command-clause:list-Element-with-delegate

command-clause:list-Clique-with-delegate:=

keyword:clique delegate-token:Participant-adapter value:Clique-name

command-clause:list-Element-with-delegate:=

keyword:element delegate-token:Connection-adapter keyword-clause:Element-type value:Element-identifier

command-clause:disband:=

keyword:disband [value:Clique-name]

command-clause:join:=

keyword:join value:Clique value:Clique-Space value:Active-Affiliation-identifier*

command-clause:leave:=

keyword:leave value:Participant-identifier*

command-clause:deactivate-other:=

keyword:deactivate value:Active-Affiliation-identifier

command-clause:form-other:=

keyword:form value:Clique-name value:Clique-Space-name value:owner-Active-Affiliation-identifier

value:member-Active-Affiliation-identifier*

command-clause:activate-other:=

command-clause:activate-self value:Connection-identifier

command-clause:disonnect-other:=

keyword:disconnect value:Connection-identifier

command-clause:form-self:=

keyword:form [keyword:clique value:Clique-name] [keyword:cliquespace value:Clique-Space-name]

value:Active-Affiliation-identifier*

command-clause:activate-self:=

value:Active-Affiliation-identifier

command-clause:create:=

keyword:create

{keyword:account value:user-identifier}|

{keyword:accountprofile keyword:name [value:Account-Profile-identifier*]}|

{keyword:affiliation value:Account-identifier value:Account-Profile-identifier}

command-clause:destroy:=

keyword:destroy keyword-clause:non-spinal-Element-type value:Element-identifier

keyword-clause:Element-type:=

keyword-clause:non-spinal-Element-type|

keyword:mediaprofile|

keyword:connection|

keyword:activeaffiliation|

keyword:participant

keyword-clause:non-spinal-Element-type:=

keyword:account|

keyword:accountprofile|

keyword:affiliation

I believe this grammar discloses a lot about my concept. Although perhaps disclosure of this detail is fraught with intellectual property hazard, I hope it might stand as proof to some that what I am doing is of realisable value, and that some day, a society might actually pay me recognition for this value. These are the motivations for publishing.

Clique Space(TM): A disengaging development.

2011-09-16T03:00:00.001-07:00

Earlier this afternoon, and although perhaps a bit rough, I can now get two Agent Devices to disengage. The engage/disengage process has a wonderful parallel to the notion of the Agent Collaboration. This is because, like the Agent Collaboration (a manifestation of a Clique Space), a relationship being formed in the engage process and destroyed in the disengage process between two Agent Devices can be modelled as a Clique. As I have said before, this product, representing precisely two conjoined Agent Devices, appears to me to necessarily mirror the function of a synapse.

Because Clique Space should be able to model any collaboration between (or even within) a device, Clique Space should be capable of modelling collaborations between its own components. Hence, this means modelling collaborations at two levels: 1; at the level of the engage/disengage Agent Device Clique Space's synapse, and 2; at the level of form/join/leave/disband Agent Collaboration Clique Space's Clique.

Now, it appears that I still have one substantial obstacle to realising a minimally functional prototype: the Agent Collaboration's pulse message. At this time, functional specifics of a pulse are very sketchy, and much more thought than has been the case up until now will be directed to this pulse thing. While I deliberate, I will revisit the Client Device with the hope of simplifying its command syntax. This will hopefully 1; make a demonstration easier to understand, and 2; allow me to add commands in a more orderly manner, which will hopefully simplify the introduction of commands concerning the pulse message.

The Client and Agent Devices are co-evolving components; a significant observable property of Clique Space's development process is how development alternates, and at times goes on simultaneously, between the Agent and Client Devices.

Clique Space(TM) Progress Report.

2011-08-29T23:26:00.000-07:00

Most of my time has been taken up by coding my proof-of-concept, and hence, I haven't been generating as many of these web log entries this year. That's no bad thing because I can't keep talking without an implementation. This implementation continues to evolve, although very slowly; such is the pace set by the capricious, somewhat bone lazy, wandering endeavour of one individual.

Anyway, a sufficient interface between the Agent and the Client Device appears to have been implemented, and so, most time of the near to medium term will now concentrate on what goes on between Agent Device instances: the Agent Device's and Collaboration's Clique Space. There is still much work to be done here.

Nose to the grindstone (or something like that)...

Coming together...

2011-08-08T03:01:00.001-07:00

I can really see the pieces of Clique Space(TM) come together. I've completed the Agent Device engagement process, the projected Element contains tokens thing, and I've been retrofitting a class that manifests an Element's identifier (ElementIdentifier) to see if I can architect a way to discriminate between different identifiers so I can (inter alia):

indicate an Element's serving Agent Device through its EngagerParticipantIdentifier.
prevent an errant (or nefarious, or even perhaps merely a narcissistic) user from giving an identifier a specific value; an identifier's value has no inherent meaning beyond its ability to uniquely identify an Element, and each Element is assigned an identifier who's value is currently a 40 character randomly generated upper-case alphanumeric string when the Element is created on it's serving Agent (or, indeed, Client) Device.

Other things like the co-evolution of the Agent and Client Devices, the growth of the number and variety of the Elements and the growth of the complexity of the interactions between the Agent and Client Devices continue to inject increasing functionality into the implementation. As the system's complexity evolves, I observe the data model moving from a simple implementation to a more abstract and generic one. I introduced Java generics about a year ago, and this move has (hopefully for the better) proven indispensable in expressing the relationship of the Agent and Client Device's specific use and manifestation of the generic data model.

Just yesterday, I completed the projected Element's existential life-cycle by coding a method that "unprojects" Elements given an Element's identifier, and the delegate identifier of the serving Agent Device through which the given Element token has been obtained. It works. I can remove any Element describing any part of a projected Client Device's structure from any Client Device through which the command to unproject is issued. I am entirely confident that implementing a robust identity/anonymity mechanism using this ability to unproject any projected Element is not far away.

Clique Space(TM): An engaging development.

2011-07-27T10:11:00.000-07:00

About 15 minutes ago, I believe I have successfully managed to get two Agent Device's to exchange information about the other, and in so doing, acquire information about each other that facilitates further communication.

I have called this the engage process. There is an opposite - the disengage process - where two Agent Devices formally break this relationship and mutually forget about their association with the other. The disengage process hasn't yet been implemented, but I'm pretty sure it is much easier to implement than the engage process.

While engaging and disengaging are a device-specific thing (specifically Agent Devices), this process uses the basic Clique Space data model, with perhaps some liberties. It's a fairly straightforward process; two Agent Devices create information about each other on their "local" Agent Device Clique Spaces, and then mutually exchange information each has created about the other along with information about themselves by creating "foreign" Agent Device Clique Space copies of the other's local Agent Device Clique Space. The process requires that one of the two Agent Devices be the "initiator" and the other be the "responder", but once the process is complete, it is completely symmetrical; one cannot determine which device was the initiator and which the responder simply by inspecting the relationship artefacts on each Agent Device.

So there you go. Now that the Agent Device engagement process has been (one hopes) stabilised into a fully functional realisation, I will begin concentrating on the Agent Collaboration.

Does this Clique Space(TM) thing work yet?

2011-06-20T06:22:00.000-07:00

Probably not, but this last commit has seen another yin receive a yang, and still, no unresolvable paradox.

Yesterday's tale of woe was bleaker than today's reality.

The Client Device now appears able to disband under the "projected Element contains tokens" architecture that went in on 31 May. Part of any development process means travelling down garden paths, back-tracking, and changing direction, so although things are still a bit rough, it appears that the Client Device can listen to any Element the user has access to. This code is beginning to look tight, and I'll tighten it yet.

It has also been a year since I started using SVN, having committed revision number 453.

Another causal loop. A conundrum. Another crossroads. A possible compromise.

2011-06-18T00:22:00.001-07:00

Just as things looked easy, I hit a snag.

The (administrator) Client Device listens to other Elements from the Agent Device to which it is connected. The Client Device does this by registering its interest on these Elements from one of the delegate Elements on its Client Device spine so these Elements can be projected onto its view for the user to observe, or persisted on some storage medium for the user's record; the primary vertebral Element (and the one from which this conundrum emerges) currently being (currently is part of this problem) the Client Device's Participant of its serving Agent Device's Clique.

It's not really a problem. Rather, I feel that it could be a crossroads, or then again, the problem might only be in a misapprehension of the nature of Clique Space's(TM) domain in the current implementation. Certainly, I feel that I can solve (or rather, I merely need to find where the correct solution exists to) this problem.

The problem is thus:

The administrator Client Device listens to Clique Space activity by registering its Participant in the serving Agent Device's Clique as a listener to another Element the Client Device's operator is interested in. The serving Agent Device's Clique is a bipartite Clique which is created using the Client Device's Active Affiliation and the Agent Device's Active Affiliation from the Clique Space to which the Client Device is seeking Participant access. The Client Device's Participant is this serving Agent Device's Clique's Owner.

Now, although I thought the importance of the serving Agent Device's Clique was coincidental in the Clique's formation, it also appears that the agent Device's Clique's structure appears to be of great importance to the way the Clique disbands.

Currently, I don't believe I have a full appreciation of the problem, but maybe all I need is a sufficient appreciation of it.

When one disbands a serving Agent Device's Clique, it appears that the Client Device must be the owner of the Clique in question. Consider for a moment, what currently is not the case. If the Agent Device was allowed to own the Clique, the following circular relationship would appear to hold: which Participant does one remove first? The Agent Device's Participant (the Clique's Owner), or the Client Device's Participant; the delegate participant for this Client Device? If the owner is removed first, the administrator Client Device loses information about the Clique (although removal of a Clique's Owner means the Clique is disbanding and therefore retaining information about a Clique is not necessary) before it loses its delegate. If the Client Device's Participant is removed first, the Client Device loses its delegate before the Clique's projection is removed (although removal of the Client Device's delegate means that the Client Device has lost Participant access to the Clique Space- which is what is happening since the serving Agent Device's Clique has disbanded).

I have to make a decision, and currently, and at the moment, it is this: I will discount notions like the one described in the above paragraph where the Client Device can be represented by a non-owner Participant in a Clique of more than two members; i.e., the serving Agent Device's Clique will be bipartite, and the Client Device being served will be the Clique's Owner. This seems to be the easiest way to deal with the question of whether the owner or the delegate is removed first; if this turns out to be the wrong way to go about things, I will just have to go back and modify the implementation.

... well... easier.

2011-06-06T07:44:00.000-07:00

A milestone of sorts was achieved on 31 May. There are still a number of yins that need yangs, but I'm quietly confident of an implementation that proves the concept soon. It will be a while more before it looks pretty, but if I can keep progressing as I have, I'll soon be able to demonstrate that it works.

... and then it suddenly got very easy.

2011-05-31T08:19:00.000-07:00

As of yesterday, it seems as though I had fit the yins with the yangs. A milestone reached perhaps?

Evolution of Implementation

2011-05-24T19:25:00.001-07:00

As I write this, I'm contemplating the considerations to do with the implementation that I currently am entertaining. I find that, particularly as my implementation matures in functionality and I meet technical challenges with adequate solutions, I am working toward answering deeper philosophical questions; in other words, I find that the fuzziness of philosophical pondering begins to revolve around strongly technical matters as my implementation approaches realisation.

This is just as I hoped: the framing of fuzzy philosophical questions about notions of the self in practical implementation-based problems appears very achievable. I think that if I can continue to whittle down these notions into sharper technical problems, and indeed, if I can meet these problems with robust and simple technical solutions, I might provide some very sound answers to some very deep questions. This is a hope I have had with Clique Space(TM) since that day in mid-2004.

Word to your mother: philosophy is not the pursuit of dilettantes. The self has, for too long in a secular society, been something which has been avoided. If Clique Space answers questions about how the self might be defined and modelled (as I hope it will), a secular society might then just be in a position to pay respect to what it means to be a self; something only thus far which has barely moved beyond the province of religious mysticism.

Clique Space doesn't attempt to explain the origins of the self just as it doesn't attempt to explain the origins of the universe - but I think that it might at least show that such a notion as the self can be quantified, communicated, and asserted as a property of objects in the world.

I could indeed be a dick. If this is my ultimate discovery, then... ureka!

Another Clique Space(TM) product summary.

2011-05-08T00:25:00.000-07:00

To wit (extracted and paraphrased from an email I put together to someone who is currently expressing interest):

Note that regardless of how complicated you think the solution to the problem of real-time identity is, I think my solution is very simple, and can be technically covered in a few simple systems design (specifically UML) diagrams.

I have had my idea for nearly seven years. Around mid 2004, I believe I solved a way to integrate the notion of the individual with any devices one might be using and any roles one might be affiliated so that one individual might be able to:

represent themselves to any other individual as a collection of devices and these devices' media though which any other individual likewise represented can find an appropriate channel of communication, and engage compatible media with the first individual. Media that can engage more than two participants (one, two, or more individuals) are also able to be modelled in this way.
decide, based both on individual preference and role affiliation associated with each connected device, which other individuals can observe and engage which of each other's devices over a compatible medium. Affiliation is, in essence, also an exercise of individual preference because a particular affiliation is activated for a particular device after that device is connected to a particular Clique Space.
collect, for one's own records, collaborations for which an individual has privilege. Other than being connected to a given Clique Space, the individual does not necessarily have to be a participant in the collaboration of a particular set of devices in order to observe the collaboration in a way that can be communicable through Clique Space.
enforce mandatory privacy rules, but limit the scope of these rules' effectiveness to discretional criteria based on the characteristics of a particular collaboration. Take, for example, two individuals which may not wish to engage a device with the each other directly over any medium, but both will participate in collaborations mediated by a third; lets say that the first two are opposing parties of some type of settlement, and the third is a legal appointee mutually tasked with sorting the issue out.

Such a system as I have envisaged would not operate directly amongst the collaboration media of specific device instances. Rather, collaborating devices continue to collaborate in their device-specific way, and information relating to the devices' state is siphoned off to one or more connected Clique Spaces so this information can be used to represent individuals' activity on each of these Clique Spaces.

Likewise, should the device and the medium permit, control information can be sent from Clique Space to the device so individuals can control their activity through Clique Space, rather than having to coordinate the activity of disparate and esoteric devices and media.

So, here are two main domain solutions to my concept:

Just as you don't have to know how your eyes work in order to see, you don't have to know how a device works so you can use it in Clique Space.
Clique Space allows you to choose which other users can interact with or can observe you in accordance to settings you can apply independently of any device to which you represent yourself as.

A smaller version of Clique Space(TM).

2011-04-28T21:29:00.000-07:00

It has been occupying my mind for some time. I see nothing wrong with a four-element Client Device structure; one that ignores notions of affiliation. In this version, Connections are used to form Participants because neither Account Profiles, Affiliations, nor Active Affiliations would be necessary. This type of Clique Space might be good to represent un-stratified populations where no one registered within has any authority above anyone else, and might be better able to realise a Clique Space that represents an individual or small organisation. The main issue with such a Clique Space is that everyone registered within the Clique Space will have the same basic capability.

If my concept doesn't cover this idea, then all good, possibly, for prior art. Then again, a Clique Space following my specification that has a single Account Profile, and cannot use Account Profiles from any federated neighbour Clique Spaces to create Affiliations registered on the Clique Space in question has as good as a four-element Client Device structure.

Clique Space(TM) and cyberspace.

2011-04-14T17:52:00.000-07:00

Here's something I recently put together in a forum. I think it is another concise description of what Clique Space is meant to do:

Consider this for an every-day example of such a relationship that has been around for much longer than our traditional notions of technology: your hand is a device for grasping things, your mouth is a device you use to eat with, and your eyes are devices through which you see the world. You are an individual, and blood glucose monitoring devices (I think they're somewhere in your brain) tell you that you are hungry. Your eyes see an apple, and other devices within your brain tell you an apple is within your immediate vicinity. You reach out your hand and grasp the apple, draw it to your mouth, and consume it. Now, it is obviously worthless to consider that your eyes were connected directly to your mouth; the intermediary is your nervous system (a Clique Space of sorts), and the individual 'you' exists as a transcendent supervisor who uses one's will to coordinate the activity of each of these bodily sensor and actuator devices to achieve some ends.

What I propose to have done with Clique Space, then, is extend the notion of the individual as a transcendent supervisor to have control over (indeed, to possess) things belonging to realms other than one's physical body to fulfil one's desires. Allowing an individual to possess devices in Clique Space will also allow one individual the ability to record and to negotiate with which other individuals and under which circumstances interaction is going to take place. Clique Space indeed protects what is mine, yours, others', and what is unclaimed or anonymous. It affords everyone in a cyberspatial world to viscerally claim individual ownership of artefacts within it.

And yet something else about what I think Clique Space might be capable of:

As a side point, I don't believe I have invented an AI let alone any AI that is as capable as a human (if ever such an 'artificial' thing could possibly exist). On the other hand, what Clique Space might do is provide an environment within which a synthetic sentience might emerge. This is something quite different to an AI; there is nothing artificial about emergent sentience. The sentience wouldn't feel artificial, and if you tried to convince that sentience that it is artificial, you might well be quickly and laudably rebuffed by it.

And a clarifying comment:

As a tool, I think Clique Space would prove as important in any physical world as it would prove in a world of software and any virtual-reality realm. I use the term cyberspace, but it might seem that by using this word, I am reserving Clique Space's utility only in a virtual world. I want to clearly dispel that myth; I take that cyberspace is the union of the physical and virtual.

Clique Space(TM) functional requirements judged stable.

2011-04-06T07:04:00.000-07:00

Good news indeed.

As of about 20 minutes ago (about 12am on Thursday 7 April 2011) I believe I have a stable implementation of the four basic functions of Clique Space:

Connect/Disconnect
Activate/Deactivate
Form/Disband
Join/Leave

This feat has only taken me until now to complete. Non-functional requirements like: making Clique Space robust and resilient; mapping basic media, Client Device, and Agent Device functionality through Enabling Constraints (the concept of Enabling and Limiting Constraints have been incompletely implemented); and the development of more Media Profiles for a mountain range of other devices - is all that remains.

That's commendable progress.

Self simulation: causal loop closed.

2011-03-14T06:43:00.000-07:00

Something that I had known since I conceived of Clique Space(TM) was the possibility of encountering a causal loop. Although I talk openly about self-reference, I didn't openly admit a causal loop to myself, and hence I haven't talked about it before, because I didn't really know how to deal with it. I felt it best just to continue with my implementation until it moved front and centre.

Indeed, recently, this is what seems to have happened. The issue is manifest in each of us. It concerns the origins of the self (the soul or the mind), and although I rarely give the issue much current personal reflection, this issue perplexes all of us when we do think about it. Although I don't believe I have given Clique Space a soul, I do believe I had to solve the basis of this issue for Clique Space: a self-referential causal loop.

Indeed, it appears that I have corralled this issue, which now rests in the creation of three Elements: the Agent Device's collaborator Connection and this Connection's component Account and Media Profiles.

I have done well.

Clique Space(TM) and topics on the "Self"

2011-02-16T20:59:00.000-08:00

If Clique Space proves a concept as efficacious as my firming hope leads me to believe it will, there are three basic topics (garden paths) concerning the definition of "Self" that I think this system will play a central role in.

The super-self, and an Emergent Social Sentience.

A Clique Space system like I envisage the "Public" Clique Space to be would provide individual selves (you, me, and others) an environment in which our activity might collectively become so intertwined that the Public Clique Space itself might begin to display synergistic coordinated responses to stimuli that are based on the activity of individual users.
Evolution of Synthetic Sentience.

Clique Space systems might be designed to remain physically separate from others in such a way that an individual Clique Space may encompass its own level of autonomy. A Clique Space system might be employed in a manufactured article (some type of robot) to give it a degree of autonomy which would furnish it with a level of awareness.
Definition of the Physical Self, and the Human Body as Just Another Client Device.

A Clique Space user may consider devices they express themselves through as a means to an end for their own self-expression. The human body, being a physical artifact, would necessarily be expressed in a Clique Space system as a collection of one or more Client Devices. As all Client Devices use the common model through which they are expressed, the idea of the individual has a human form will begin to dissolve. Indeed, an individual on Clique Space may exist beyond their human form.

Very interesting subjects...

Self-simulation: Getting closer.

2011-02-11T21:49:00.001-08:00

Twenty minutes after my last post, I was able to successfully project the elements I needed to project to the Client Device making the request. Now, I am working on the leave operation for the Agent Collaboration's Clique Space.

After that is implemented, a few more customisations to the operation of the Agent Device and its Agent Device Clique Space will allow a particular Agent Device on which its Agent Device Clique Space receives and accepts instruction to disband, to hence abruptly disconnect all Client Devices in all Clique Spaces which the given Agent Device is the Client Devices' server, disband all Agent Collaboration Clique Spaces in which the given Agent Device is the Owner, leave Agent Collaboration Clique Spaces in which the given Agent Device is a mere Participant, and disengage itself from other Agent Devices through which it shares an association relationship before merrily shutting down.

One would certainly not want to issue a disband instruction to the Agent Device's Clique Space of the the public Clique Space's Owner Agent Device unless one was absolutely sure that the consequences fit the intent. This is certainly the quickest way to cause the most pandemonium.

Self-simulation: Almost there.

2011-02-09T04:56:00.000-08:00

As of about 20 minutes ago, it looks as if I could join an Agent Device to an Agent Collaboration's Clique Space, although I have yet to project the Elements created on this Clique Space to the administrator Client Device from which the request was made.

More about this soon.

W(ho)TF is watching me?

2011-01-08T17:39:00.000-08:00

Hello! Clique Space(TM).

I'm listening to a broadcast by someone on the BBC . He's yacking about something to do with identifying who is collaborating with who else, and tracking who might be interested in what you (you yourself) is doing from one time to another over the "internet" on any collection of devices with any other collection of individuals.

Clique Space.

QED.

Of Clique Owners and the resolution of "squabbles".

2010-12-30T16:22:00.000-08:00

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.

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

2010-12-28T01:38:00.000-08:00

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:

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.
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.
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.
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.
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.
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.
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".
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.
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

2010-12-08T23:38:00.000-08:00

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

2010-12-01T17:33:00.000-08:00

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.

2010-11-23T17:30:00.000-08:00

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."

2010-11-21T18:39:00.000-08:00

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 fuck...

Invention and the inventor.

2010-11-21T16:58:00.000-08:00

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.

2010-11-20T02:05:00.000-08:00

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.

2010-11-15T06:59:00.000-08:00

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)

2010-11-05T04:12:00.000-07:00

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.

This is extremely relevant in a federation and my initial cursor review of your paper sparks a bit of interest.
[In later correspondence, the same respondent as 1 commented] This fits and benefits various sized federation environments so I am more than fleetingly interested.
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.

2010-11-02T23:06:00.000-07:00

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

2010-11-01T05:38:00.000-07:00

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.

2010-10-17T18:42:00.000-07:00

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

2010-10-07T03:29:00.000-07:00

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.

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

2010-10-05T04:13:00.001-07:00

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.

2010-09-27T23:53:00.000-07:00

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.

2010-09-25T19:53:00.000-07:00

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

2010-09-01T06:22:00.000-07:00

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

2010-08-20T09:57:00.000-07:00

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

2010-08-10T18:00:00.000-07:00

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

2010-07-28T08:35:00.001-07:00

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.

2010-07-27T20:02:00.000-07:00

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.

2010-07-26T19:10:00.000-07:00

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)

2010-07-18T20:13:00.000-07:00

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.

2010-07-09T23:46:00.001-07:00

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.

2010-06-26T06:28:00.000-07:00

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

2010-06-24T22:59:00.000-07:00

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.

2010-06-15T19:54:00.000-07:00

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.

2010-06-08T01:23:00.001-07:00

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.

2010-06-06T00:33:00.000-07:00

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

2010-05-24T06:40:00.000-07:00

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.

2010-05-11T17:47:00.000-07:00

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).

2010-05-04T00:44:00.000-07:00

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.

2010-04-02T16:55:00.001-07:00

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.

2010-03-14T20:37:00.000-07:00

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:

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

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

provide an opportunity to control collaborations in accordance with cross-cutting, device independent criteria associated with the collaborating individuals.
define a uniform media engagement UI which would assist the uptake of new ways of communicating as they became available
can be federated according to mutual agreed organisational boundary conditions.
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.

2010-03-13T02:18:00.000-08:00

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 be 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.

2010-02-23T22:10:00.001-08:00

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.

2010-02-11T03:28:00.001-08:00

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.

2010-01-26T02:27:00.000-08:00

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.

2010-01-10T20:37:00.000-08:00

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.

2010-01-05T05:15:00.000-08:00

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).

2010-01-02T16:26:00.000-08:00

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.

Is Clique Space(TM) the single most important contribution by an individual since General Relativity?

2010-01-01T00:43:00.001-08:00

Let me know how serious this question actually is.

Clique Space(TM) and the argument for regional, rural and remote economic sustainability.

2009-12-25T14:09:00.000-08:00

A friend of mine quizzed me on the utility of a system like Clique Space in relation to non-metropolitan economic sustainability. The argument is a corollary of that earlier post.

Clique Space would provide an environment in which physical is replaced with virtual collocation. Contributors in this environment would be earning an income commensurate with any other physically collocated contributor, and hence, would be bringing this money in to the community where they live. This money would flow through their community, in turn fostering wealth, jobs and the opportunity for others who possess skills that don't readily lend themselves to the same degree of autonomy to stay where they may prefer to reside.

Currently, the persistent trend has been away from this ideal; people are coming together which is putting pressure on others to do likewise. This pressure creates a kind of a gravitation that interferes with the wishes of those who respond negatively to this growing stimulus to be physically bounded together.

The malaise created by what in many respects is a kind of social claustrophobia becomes, if reversed with the help of a system like Clique Space, a means by which an environment of economic self-sustainability might flow to regional, rural and remote communities and individuals. Money starts flowing toward rather than away from people who wish to keep themselves at a distance, because these people have greater latitude to contribute in occupations that derive incomes, yet without having to consider what the greater loss is: to give up the prospect of an income, or to forego the solitude they desire.

An open question for people to consider.

2009-12-20T18:33:00.000-08:00

I have a PCT patent, and this patent is due to expire on 15 July 2010. I applied for this patent because I decided that a concept, which is very simple, may have eluded the minds of 6.5 billion others.

Now, my question is this: If my idea is so simple, why hasn't anyone had a go at it before I applied for my patent?

If anyone can show me that my assumption that no one has done anything like this before I applied for my patent is wrong, then please point this out to me. Alternatively, if anyone out there might be in a position to help me implement it, then approach me.

You have until 15 July when my PCT lapses. There will be no prospect of ownership after this date because if you try, your competitor will point out to you this blog, my lapsed PCT, and all the other stuff I have published and assert that the knowledge is in the public domain.

Get cracking people. What else can I do but disclose the concept publicly. It appears as though the concept is mine. To assert this, and remove the possibility of anyone else making a claim, I can do little else than publish, and invite others to help me realise it because I don't have the means to realise the concept in its entirety myself.

Clique Space(TM) and the self.

2009-12-19T18:37:00.001-08:00

From what I've put here, my Facebook page, and elsewhere, it can be seen that Clique Space defines something that has thus far been a hard concept to pin down: the self.

Anyone (any thing) that wishes to assert the quality of selfness in a Clique Space does so through an Account. Anyone who possesses an account asserts this quality through a Connection to a Client Device and an Affiliation to an Account Profile (some type of group-role representation). The Connection and Affiliation are associated through an Active Affiliation before the Client Device can be used on a Clique Space.

So, what is a self? On a philosophical angle, I don't ultimately know. However, if approached from a pragmatic angle, one might think of it as the origin of one's actions, and that which is ultimately responsible for these actions. In this case, I have a self because I assert this quality to you. Hence, in order for me to do this, I perceive you as another self to whom I assert my quality of selfness. I therefore perceive us as being two distinct selves, and would therefore expect that if you wished to use Clique Space, you would like to have an Account because this is the way one asserts that they are more than just a device to a Clique Space - or more factually, to other selves from a Clique Space.

So, if you want an Account, then you are a self.

Still, what is there to prevent you from having more than one Account? I suppose very little. However, in the "Public" Clique Space, people may want to know that you are who you say you are; that you're not two or more different people at different times (or even simultaneously) whenever it suits you. No one would accept this, and to masquerade as two or more different identities, changing them at your whim would inevitably erode the definition of your self to yourself as well as to others. At least it would to me. Clique Space has a few solutions, but I'll talk about one of my favourites...

Clique Spaces can be federated. In the public Clique Space, anyone can grab any old Account and start generating Client Device activity with it. On the other hand, a proprietary or government administered Clique Space could offer stronger authentication so to guarantee that people who are using it are the people that the government or proprietary organisation intends.

To offer people a level of assurance that I am who you say I am, I might Connect a Client Device to two Clique Spaces: the public Clique Space that everyone uses (a place that might not have strong authentication mechanisms - unless one is willing to pay for them) and to a Clique Space administered by an Australian federal government authority. Obviously, I would obtain these Connections under the same Account.

This Australian Government Clique Space would be a federated neighbour of the public Clique Space, and anyone on the public Clique Space might be able to see that my devices were also logged on to the Australian one, so people could see that my identity was endorsed by the Australian government. I would perhaps be providing my Australian citizenship to others as an endorsement of the Connections to Client Devices I possessed on the public Clique Space. I, for one, like this idea.

I also like the idea of remote authentication and "Connection Limbo". A device (a Client Device) cannot be seen by other users on Clique Space unless the Connection has been Activated. One Activates a connection by associating the Connection with an Affiliation in the process described at the start of this blog entry. A Client Device that has an inactive Connection is in a kind of a limbo state.

Now, a device that is in a limbo state might not authenticate directly. The Clique Space within which a Connection has been obtained might instead, notify another Client Device that the Account holder can authenticate against, and request that the Account holder validate their credentials on this Client Device to authenticate the Connection of the first Client Device. If authentication succeeds on this other Client Device, the first Client Device's connection is Activated along with the appropriate Affiliation. If authentication fails, the first Client Device is disconnected from the Clique Space. Now, there might be a single device through which authentication might be given, and hence, a single and hence simple way to authenticate every Connection to a Clique Space for any Account holder.

Even Connections may not have to be requested by a Client Device. A user could instruct a Clique Space to issue a Connection to a device, and this device might respond in any way it is programmed to respond to Connections from Clique Spaces.

Using Clique Space(TM) to Support Regional, Rural and Remote Sustainability

2009-12-17T22:15:00.000-08:00

Two days ago, I had a conversation with someone from the university where I live, and they identified Clique Space as having qualities that make the concept suitable for enabling rural and remote economic sustainability. This is something I have believed for some time; in providing a system that allows the integration of any device into an organised collaborative activity, Clique Space is a vital tool of the telework enabling puzzle.

Until now, society has relied on collocation to achieve cooperative activity necessary for many organised tasks. Such activity has historically been achieved by providing a central business hub, and locating necessary resources as close as possible within this centre both to maximise the speed of response to changing conditions, and to minimise the handling time to products as they move through a process.

Today, factory floor automation is reducing the necessity for humans to be directly involved in the production of physical goods, yet society still relies on these established mechanisms of collocation to engage in activity that is largely divested from the necessity of physical collocation. Common occupations have largely shirked physical activity. The blacksmiths, farm hands, wood turners, mill and factory workers of 100 years ago have either been made completely redundant, or are well on their way to being replaced by mechanised, robotic devices. Today, occupations such as information workers, secretaries, office hands, and other vocations that involve more of one's intellectual discipline than physical stamina are common place. Basically, people would rather be thinking and planning than making and doing.

I don't think there's anything wrong with that. I like it - thinking and planning is more engaging and more self-determining than is making. Thinking and planning is what comes before making and doing, and it is a normal extension of human nature to desire the former two things over the latter two. Thinking and planning also make for better living due to the reduced strain placed on the body, and therefore the prospect of a longer existence in which one doesn't have to battle an existence where chronic pain, fatigue, injury, or any combination of these are factors that result from physical labour.

Now, should these goals be reserved only for the city dwellers? Has such a question been asked of those who live elsewhere? While it isn't always productive to generalise, I would think the desires of everyone, whether from an urban centre or not, are in this case, generally directed away from repetitive activity; the desire to move away from repetitive physical activity is generally the stronger aversion.

In addition to what we try to move away from, are also those desires we are attracted to. We desire company of the familiar and the familial. Many (I would say most) people desire constancy over dynamism. In saying this, I have no wish to interfere with those who desire the converse; in fact, there is no reason for anyone to fear the diminution of a lifestyle in which change is a continuing factor by recognising that this lifestyle is neither for everyone, nor even for specific people all of the time.

So there might have been a time when humanity might have done well to physically collocate. Personal experience indicates that people are being drawn together by forces that are an anachronistic vestige of an era now past. Although I might not banish coming together on occasion for the esprit de corps of one's colleagues, no "special sauce" that executive or operational managers think might be wrung out of their plebs will yield any ultimate social or economic good from the continuing practice of physically collocating people in the bygone age of factory floor management. None at all.

People who do not live in metropolitan centres are being wrenched out of their communities by anachronism. Clique Space is my answer to this in that as long as one can coordinate, control, and audit activity over devices involved in modern human mediated processes, one might yet be able to choose where (and maybe the when) one gets involved in such collaborative endeavours. I believe such opportunity will enable people to stay in their community, and receive consideration in occupations as would befit someone who did something similar in a metropolitan office block who was subject to an anachronistic management structure.

Bugger Big Brother. The age old maxim to work (whether in an office block or from one's home) remains: getting the work done is usually prerequisite for guaranteeing one's continued employment. The totalitarian practice of huddling people together in an office block for a minimum 40 hours per week is not effective in guaranteeing productivity. This is actually far less effective than letting the individual determine an individual level of contribution in accordance with the individual's circumstances.

Clique Space(TM) and Silicon Valley Bullshit.

2009-12-06T22:37:00.000-08:00

My prime motivation for coming up with something like Clique Space was that in no way was I going to continue to participate further in the software development industry if my participation required becoming a corporate nomad to serve the interests of a management structure that was pathologically attached to the notion of physical collocation.

Together sucks. It really does suck arse. I would rather be getting a pension than participating in your life of corporate nomadicity; wedded to my work so that I can pay off a credit card that affords me nothing more than the ability to accrue a debt that is serviced by the work that I am wedded to.

I have talked to people, and they say to me that in order to promote my idea, I should consider going to Silicon Valley to give it a hearing. You can hear my idea from me now. I am talking about it right now. Anyone on this planet can start talking to me.

I will not be pedalling my idea from anywhere else on this planet unless I get commitment that I will get something from the inconvenience first, and that doing so will not leave me stranded anywhere else on this planet. If it seems that others would rather wait for my patent to lapse than to help me register it world wide, I will frustrate and confound you all when I register my patent in the US and Europe.

In all other respects, I hope to be philosophical.

Clique Space(TM), a social nervous system, and moral good.

2009-12-03T15:44:00.000-08:00

For those who might be following this blog, a question that I have been asking myself is with a system like Clique Space, is it possible to create a system that may express an evolving degree of nervous complexity? If such a concept might be so powerful, then what responsibility might be incumbent on its inventor to offer advice that a system like Clique Space may have undesirable moral consequences?

Firstly, I have stated before that the use of an invention leaves the control of the inventor the moment it is publicly disclosed. I decided that I would publicly disclose Clique Space when I applied for my patent. Now that it is patented, and I have subsequently disclosed it, I feel that I have limited responsibility of its use; such things are now the responsibility of the society in which I live, and like everyone else, I am subject to these decisions.

Now, on the technical side, I think Clique Space is a specification for a nervous system because one connects devices to it to make it function. Devices (Client Devices) are anything that can connect to a Clique Space, including the Clique Space Agent Devices - which may be thought of as the individual neurons that make up the nervous system of a Clique Space - themselves. Not only can a Client Device be something that one person might use to talk to another, but they can be things that might not be collaborative; things like cars (mentioned in my previous post) television sets, golf balls, robotic devices of any type, etc.

So, we have Client Devices that connect to a cluster of Agent Devices (themselves Client Devices) which comprise a Clique Space. The human body is comprised of cells that make up muscles and organs of various types that connect to a special type of cell (called a neuron) of which large numbers of these collectively function as the body's central nervous system. This has to be more than a trivial coincidence.

Clique Space(TM) and MUVEs.

2009-11-26T22:27:00.000-08:00

Another question was raised through an ongoing conversation with the same person who raised the question of Clique Space and Google Wave. What's the difference between Clique Space and a Multi-User Virtual Environment, or MUVE?

Specifically, the statement was made that anyone can connect to a MUVE through "any device", so I think the definition of any device needs to be clarified as it may relate to both a MUVE and Clique Space.

The fact that MUVE and Clique Space both provide a virtual environment is obvious. A device, however, in a MUVE provides a gateway for a user to interact within that environment, whereas in a Clique Space, the device provides activity state to a Clique Space, and may be controlled by the Clique Space in ways that are specified by the Media Profile that the device is Connected through.

In a MUVE, a device provides user access to a virtual environment where that user can do things with others in that medium according to the way that medium functions. The Clique Space environment, however, connects with a device to collect changes in device's state according to its native medium, and control that device in the medium in which that device is operating. Clique Space does not attempt to provide a substitute for an existing media; it compliments a device's functioning so that changes in device state might be centrally recorded and possibly controlled according to concerns that cut across media into issues such as user preference and organisational role.

In this way, a user in a MUVE might use the device one uses to connect to the MUVE to additionally connect to a Clique Space. The MUVE connection is expressed as a Clique Space Connection to this device (known to Clique Space as a Client Device; possibly the device that the user uses to obtain access to the MUVE, or possibly the MUVE provider itself) over a Media Profile that is appropriate for that MUVE. The Clique Space can collect status from the Client Device, and may also control the way the Client Device operates. All this may depend on which other users this particular user is working with, which other Client Device(s) the user has Connected to the Clique Space, which users are affiliated to which organisations in Clique Space, amongst a combination of these and other degrees of access freedom.

Any device has possibly a much wider scope in Clique Space than it does in a MUVE. Can, for instance, a physical car have any meaningful place inside a MUVE? On the other hand, a car might be connected in Clique Space, and its status (engine on/off, speed, fuel level, fuel mixture, tire pressure, engine temperature, etc) might be recorded by Clique Space. This information might be relevant, for instance when placed along side the chatter that happens between the driver and the driver's pit-lane mechanics, the driver's physical condition, the driver's (and car's) location, and the weather. All of the devices that collect this information might be similarly connected to Clique Space to particular Media Profiles, through particular user Accounts, and under particular organisation Affiliations. Fuel mixture might be monitored while the car is racing, and may even be adjusted by mechanics in the race to maximise fuel efficiency and power. All of this information could be available on one device activity log to be reviewed after a race.

To what extent might one also connect other non-collaborative devices to a MUVE? A MUVE is designed to represent an individual's interaction with objects and other individuals in some type of virtual environment. I contend that this concept is different to Clique Space in that a Clique Space collects data from a whole host of virtual and physical environments, and facilitates both an identity and device activity coordination layers on top of all devices so connected.

MUVE's are apparently used as teaching environments, and so to compliment, enrich, and diversify the learning that might be done in these environments, users might connect their MUVE session, as well as other other physical devices they may be using in the exercises being conducted to a Clique Space so the instructor can see and possibly control the functioning of all his or her pupils' devices.

I think a Clique Space is definitely something thoroughly different, yet complimentary, to a MUVE...