Let me work from home part time.

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.

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?

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.

1. 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.
   
   
2. 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.
   
   
3. 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.
   
   
4. 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.
   
   
5. 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.
   
   
6. 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?

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.

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.

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.