Message handling and routing
When a packet with a _message method is received for a person entity it MAY be stored in a log of last messages.
When there are entities linked to the person entity, and the message is a multicast message, routing is done as described in Spec:Routing.
If the message was a unicast, the person entity relays it to the linked entities as described in Spec:Routing (the original _source is put in the _source_relay variable).
This routing behavior is applied to all other packet methods the person entity isn't able or willing to handle.
Some exceptions are described below for message echoes.
When the person entity receives a _message_private it SHOULD generate a _message_echo_private and send it back to the _source unless the sender is unwelcome or other reasons make the generation of echo problematic.
When the person receives a _message_public from one of the subscribed contexts and the _source_relay of that message is the uniform of the person entity itself, it SHOULD generate a _message_echo_public and send it (instead of relaying the _message_public) to all linked entities.
See also Spec:Message.
The person entity offers these channels:
- # - The context all its contacts are member of.
- #_presence - The context all contacts receiving presence updates are member of.
In order to subscribe to basic contact data of a person (make friendship), apply the context subscription protocol to his contact channel. To also subscribe to a person's presence data, use it on her presence channel. An example presence channel's uniform looks like this: psyc://example.net/~heela#_presence
To offer some other person entity friendship a _request_context_enter has to be sent to the other entities #friends channel.
The other entity then SHOULD request to enter your #friends channel, and if the access is granted he should also grant your enter request.
Person entities should store whether someone made this request, so a user can later come back and approve the friendship request.