Updated content will appear here shortly!

TODO: Note that the client device running the user interface needs to be able to register its available local services for accessability through the UI, above and beyond the normal input/ouput devices of a UI; things like location sensors, mobile phone telephony facilities, and so on.

Also discuss petnames; CARBON exists to give things global names as a "trusted path" identity where that's useful, but it's not for everyone. EIDs are the true identities of things, and user agents should keep an address book of EIDs with user-chosen "nicknames" and a log of "referrals" (groups of CARBON statements about the EID, clustered together and tagged with a source).

EIDs received in IODINE messages will often have a name attached in the attendant metadata, so can be added to the address book (if not already present) then a referral logged with the source, timestamp, context of the message if applicable, and the suggested name from the supplied metadata.

EIDs obtained via CARBON can similarly be added to the address book, and logged as being referred from a given CARBON name, with the suggested name from the parent directory node.

Signed information packets received by any means may also contain statements about EIDs that will be counted as referrals.

Entities can be asked directly (via CARBON) what their display name (in the sense of a text string, rather than an IRON symbol) is, which can also be logged.

When an EID needs to be displayed to the user, the nickname will be used if there is one, otherwise one will be crafted from available metadata about the EID; but to avoid phishing attacks, distinguished unforgeable styling will be used based on whether it's a proper nickname, referral from trusted sources, the name the entity itself suggests, etc.