Clique Space(TM): An engaging development.

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?

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.

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.

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.

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

Evolution of Implementation

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

Another Clique Space(TM) product summary.

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:

1. 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 two or more participants (one, two, or more individuals) are also able to be modelled in this way.
   
   
2. 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.
   
   
3. 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.
   
   
4. 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:

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