NEON is a user interfacing toolkit.

A node with a physical human interface system can run NEON to provide an interface to the system, primarily by navigating the CARBON namespace and interacting with entities.

When one first approaches a NEON node, it will want you to log in. This may be done by navigating through CARBON to locate your IODINE user agent, or picking one from a configured list.

NEON will then contact your user agent and use a special interface to request a login with it. If the user agent accepts the request, it will return a block of CHROME code.

This code is given access to the human interface, and will then attempt to authenticate you. It will send the evidence of its authentication back to the user agent (the UA cannot, of course, trust the code it sent out). If the user agent is convinced that it is actually you, then it will issue a certificate authorising the NEON implementation to act on its behalf. The code it downloaded can now act "on your behalf"; with the certificate installed in its context, MERCURY requests issuing from it will carry that certificate, so that clients can check it and see if it is acting properly on behalf of your user agent, and thus you.

What happens next is up to the user interface code you have installed in your UA, but generally, it will provide some interface to browse CARBON for you, displaying what it sees using the hardware it finds to hand. When displaying simple value nodes from the CARBON directory, it will use whatever handlers it has installed to display them; so an object of class "phone number" may (if no better handler is defined) be just displayed as the string contained within, but if you have a special handler installed, it may instead come up with the phone number plus a number of buttons to make your phone (via bluetooth) call the number, to initiate a VoIP call, to look the number up in your address book - etc.

When you visit an entity reference in the directory, it will contact the entity using the standard NEON interface to request a user interface. The result of the request can contain some CHROME code to provide a UI, and/or a list of top level stateless "basic commands", giving each a name and other arbitrary metadata, including a parameter list specification; these commands can be invoked by name, returning either a simple value or some CHROME code to open up a more complex interaction.

For example, an entity representing a light switch might just provide basic commands called "On" and "Off" that, when invoked, return nothing. There might also be a "View History" command that returns a CHROME user interface module that provides some kind of interactive interface to a history of light bulb activations, replacements, and so on.

It is intended that the basic commands can at least be used even on the lowest common denominator of user interface hardware.

The CHROME code that gets downloaded into a NEON implementation to interact with an entity is presented with a fairly abstract interface to the interaction hardware; more in the spirit of CLIM or Vis than, say, the Windows API. It should be possible to write the UI code provided by entities such that it will work seamlessly on a wide range of interfaces, from command lines through to graphical workstations, without modification. In cases where a particular interaction style is required - eg, it is hard to write a decent drawing application without a graphical canvas and a pointing device - then code can access more specific APIs if it wishes, but where this is not necessary, abstract APIs should be available.