It is true. Your Axle is a private part that you may share with others, but if you give your sovereign away, your sovereignty goes with it.

How do I know who I am on Clique Space(TM)? How do I let others know who I am on Clique Space? How do others on Clique Space know who I am?

Axles serve an intimate purpose of self-identification. In Clique Space, Axles identify what is yours to yourself, and if you wish it, to others who you have nominated as being privy to your Axle's components, but especially the Axle's identifier. You can share or withhold this Element's identifier from disclosure through any Identity you have created. You know all these Identities are yours because they have been created only by you as the possessor of the Axle, and by using your Axle's sovereign - a private key which you never disclose to anyone else - to sign each Identity's identifier. You let others know each Identity you have created is yours by disclosing your Axle. If you don't want to let others know who is behind an Identity you publish, then you assign a Limiting Constraint to your Identity that prevents disclosure of your Axle to them.

I believe there is certainly a versatility - nay, even power - given to the individual in cyberspace through this Clique Space concept.

Now, to a more practical matter: the relaying of device activity to the individual Axle holder. This matter concerns, indeed, Clique Space mandates the concern of how devices having an interest in the Clique Space activity - any Agent Device or View/persistence mechanism-enabled (V/PM) device - are kept informed of the state of the one or more Clique Spaces to which the said devices are connected. In order for a device to be Clique Space aware, the device must be connected to a Clique Space. An individual - an Axle-holder - is really the thing capable of being aware of Clique Spaces just as they are aware of how hot or how hungry they may be; devices merely relay temperature or blood glucose levels to a device loosely called the brain wherein, in today's society, an individual appears manifest.

An Agent Device is a type of device which can talk to other Agent Devices. Agent Devices share information about Clique Space Elements, participating in the distribution of device activity throughout a Clique Space (a domain which is managed by a subset of the individuals who use the Clique Space) as the activity of all individuals who use the Clique Space. An individual, having both the capacity and the desire to observe or persist activity on a particular Clique Space connects one or more devices capable of doing this through their own Axle. In order to use these devices in any meaningful way, their Connections must be expressed through one or more Identities - created using the same Axle.

Any device which is not an Agent Device or a V/PM device is connected to a Clique Space using this same mechanism, but the Elements and components (really, just the components) used for and generated by the connection operation are not disclosed to the given device. This is because the device, not being an Agent Device or a V/PM device, doesn't have a facility to make sense of Clique Space Elements.

Lets now take a look at the Agent Device and the V/PM devices. These devices need a way of receiving information about the change in the state of all the connected devices. Now, any device (be it an Agent Device or a V/PM device) must be accessible from one collection within the Agent Device to which it is connected. It appears intuitive, and technically it is also a reasonable proposition, for the Axle's instance on a particular Agent Device to contain a set of all such Connection instances.

I have removed the notion of an "Adapter" interface except for the class called the Participant adapter - which is now implemented by any V/PM device. I think the adapter interface is a good candidate for massage so that the Agent Device's Connection can also implement this interface.

I predict some heavy-duty thinking over the next several weeks. For instance, if wer're going to use the adapter interface, then we must recognise that the methods on this interface must supply the same information for the Agent Device's Connection as is necessary for any other V/PM device.

This method's implementation on the Connection of the administrator client transmits a quantum from an Agent Device to a V/PM device. It has the following signature:

•  void transmit(SourceParticipantAdapter participantAdapter,Transmitter transmitter)
       throws CliqueSpaceException;

The first parameter, participantAdapter discloses the Connection to which the desired quantum, enclosed in the transmitter given as the second parameter will be transmitted. Currently, only the administrator client's Connection (AdministratorClientConnection) implements this method, but I think it would be a good thing if this method were declared in the adaptor interface; it isn't currently. The adaptor interface needs to be implemented in the Agent Collaboration's Connection (AgentCollaborationConnection), an instance of which is created in the underlying Agent Collaboration's Clique of any other client collaboration's Clique - remember - if the client collaboration's Clique involves the participation of more than one Agent Device.

With both of these Connections implementing the same adapter, they can be contained within a set of adapters inside the same Axle as the one through which this Agent Device is connected. This, however, seems to hint at a complication: if each adapter of this set must name the same Axle in which this set is contained (must it?), then what happens if someone, using a different Axle, connects a V/PM device to this Agent Device? Is it possible that this ominous restriction is actually a ray of clarification?

The Agent Collaboration's Connection would surely implement the transmit method differently to the V/PM device; rather than transmitting the transmitter directly to the device (this would be the case in any instance of a V/PM device that I can currently think of), the Agent Collaboration's Connection would find its associated Participant (of which there would only be one) and transmit the information to all other members of the Clique excluding itself. This mechanism is detail around the concept exactly as I envisaged in mid-2004.

Some heavy-duty thinking to flesh out and implement this mechanism is needed indeed, but more than eight years of heavy-duty thinking has drawn me slowly to the acceptance that this overall concept will eventually be proven.

We'll see...