IODINE is a series of standard MERCURY interfaces for representing persons - both humans, and abstractions like corporations, or roles - as entities.

An entity representing a user is known as a User Agent, or UA. This entity is like your home page and your email address rolled into one; it's a central point of identification for you as a network resource.

The IODINE interfaces allow other entities to perform actions such as sending you a message, requesting interactive textual, audio, or video communication with you; requesting a mutually convenient appointment; and so on.

Also, the CARBON protocol may be used to request metadata about you from your user agent, just like FOAF. As well as the usual long-lived information like your name, address, and gender, it can provide more transient information; are you at your computer right now, or offline? Busy working, or free to chat?

Note that a decent user agent should allow you to use access control lists to specify what information to give to who!

User agents may also provide a public user interface with NEON, like any other entity. This means they can act as a home page, a blog, or any of the usual combinations of the two.

A user agent may also be a storage space entity, allowing you to manage your own entities on the same physical cluster as your user entity lives; in that sense it is also your "home directory".

Messaging

I am hoping that the IODINE interface to send somebody a value (a text string, an image, an entity ID, or whatever) can really be abstracted out into a generic "value push protocol" to send things to entities to do whatever they like with. That way, the same protocol can be used to send people messages as to, say, log events with a log database. This same protocol can be used by a user interface to support "drag and drop" onto entities, too; printer driver entities would do their best to convert what is passed to them into marks on paper, and so on.

Doing this all with one protocol should avoid a lot of duplicated effort, and enable things to work together in interesting ways...

Note that I have suggested a lot of FLUORINE protocol gateways would support the object push interface; eg, the result of resolving the name fax:44... in CARBON would, if appropriate hardware was available, be an entity that supports object push to send faxes to that number. Not only could one drag and drop a document onto such an object to send a fax, one could tie any system that generates messages to that fax number as its target, and have a faxed copy of whatever object comes by sent. The fax gateway, in its attempts to convert the objects it receives to a 2D bitmap, may have to resort to getting them to describe themselves as a string - the most basic description interface to an IRON value, that all should provide - and then use a font to convert it into text. But this means you can get away with sending ANYTHING to a fax machine.

I think that, as well as the raw IRON value, the push protocol should allow the originator to supply optional CARBON metadata about it - such as a description, an icon, that sort of thing. This can, amongst other things, be supported by directory nodes to allow you to drag and drop an object into them to add it to the directory, whereupon it will start life with sensible initial metadata.