A PSYC application which is reachable and interconnected with other PSYC applications is called a node in the PSYC network. A node always has both a protocol root and an entity root. It may also provide further entities of varying kind.
A PSYC node which is not reachable from the outside by other PSYC nodes is called a leaf. Clients are usually leaves.
There are two concepts of root in PSYC. Depending on architectural choices, both roots, the protocol root and the entity root MAY be implemented in the same place in the source code, or not.
The root entity in a server or application is the object that comes without anything behind the / in its uniform, as in psyc://psyced.org/. It performs jobs like authentication. This root is a full PSYC entity.
The protocol root instead leaves out the / as in psyc://psyced.org. It is used for negotiation for example in circuits and thus operates on the routing layer. If a packet is sent, and either the source or destination is not explicitly or implicitly addressed, the protocol root is intended.
- state: the own state and the state of other PSYC entities. A state is usually a set of persistent PSYC variables.
- trust network: know who the entity trusts and who it can ask for second hand trust.
There is a set of basic entity types, which implement a specific behaviour to meet the needs of a chat network. These are the specified entities PSYC currently knows:
Provided for in the spec, but not currently implemented:
Some entities implement a command interface, to let users actually do something with the entities (like setting the topic of a place).
Each entity has at least one context, which is reachable via his uniform. Some entities, like the person entity, offer multiple sub contexts, called channels, which are addressed by the channel part of its uniform. For example, if psyc://psyced.org/~lynX is the UNI of the person entity, the context where presence updates are multicast, may have the uniform psyc://psyced.org/~lynX#_presence.
Just like an anchor in HTTP URIs, the channel is not a new entity itself but merely defines a different view on the original entity's context. Channels define a variation in routing and its logic (typically a subset of the entity's subscribers), but do not need new subscription procedures as they inherit the trust relationships of the owning entity. Receiving entities are required to accept these messages immediately as if sent by the entity.
For a list of predefined channels, look at the specification of the entity types. Further channels can be provided and named freely, according to the needs of the application.
Channel names are bound to rules for keywords and define their own keyword namespace for the purpose of defining standardized compact channel names like p for _presence. Channel inheritance is defined as follows: Any subscriber of a subchannel is also regarded as the subscriber of the parent channel and the context as a whole, and thus receives traffic transmitted to it, but a subscriber of a subchannel does not receive traffic directed to a completely different subchannel. Examples:
A subscriber to psyc://psyced.org/~lynX#_presence_verbose will receive packets transmitted to psyc://psyced.org/~lynX#_presence_verbose, psyc://psyced.org/~lynX#_presence and psyc://psyced.org/~lynX but not to psyc://psyced.org/~lynX#_rants.
A subscriber to psyc://psyced.org/~lynX#_presence will receive packets on psyc://psyced.org/~lynX#_presence and psyc://psyced.org/~lynX but neither psyc://psyced.org/~lynX#_rants nor psyc://psyced.org/~lynX#_presence_verbose.
Channel state inheritance
This affects also the way state is seen by subscribers of various channels. A subchannel may have a differing member list from its parent channel by applying its own modifications to it. Modifications to the parent channel still affect all of the subchannels. Member lists just being an example, as they are not required for channel routing and currently only serve informational purposes.
Here's an example how this can be useful. Consider a news company that provides headlines and discussion channels. It may want to allow its subscribers to select certain themes. It would find it useful to keep general information like a company logo in a top-level state like psyc://news.example.com/@news, then provide theme headlines in channels like psyc://news.example.com/@news#_sports, and allowing users to subscribe psyc://news.example.com/@news#_sports_talk, where they not only receive the psyc://news.example.com/@news#_sports headlines, but are additionally permitted to talk about them without disturbing the subscribers of the parent channels. This gives the company the possibility to make important global announcements on psyc://news.example.com/@news without having to send copies to a whole stack of chatrooms, because the top channel has all subscribers right there.
the Uniform Network Location is the effective IP address where a user agent (a client) or other mobile entity is operating for a user (or other UNI), usually in combination with an allocated port number. UNLs are volatile, as the current IP number of a client changes frequently, and are typically given to trusted friends for peer-to-peer activity. Usually the UNL points to the root entity of the user's client.
NOTE: How locations work and how they are linked to the identity is not covered in this Specification
the Uniform Network Identification is a permanent uniform of an entity in the PSYC network. Something you can print on your business card or publish in other Internet media. In some cases the entity answering at a UNI will forward or redirect messages to a location addressed by a UNL, in other cases the entity is self-sufficient. UNIs are primarily employed by identities and places.
A UNL is used to address a location, it usually reveals a user's current IP address, as for example in psyc://10.12.14.16:49321.
NOTE: How locations work and how they are linked to the identity is not handled in this Specification
An identity is a linkable entity, typically a person entity, but a service identity may be linkable, too.
A UNI is used to address an identity and the home server is where a user's own identity resides.
The physical source of a packet is either the _source or, if the _source is not given, _context.
To determine where the message came from _logically_ you need to get the logical source. The logical source of a packet is in this order (first hit counts): _source_relay, _source, _context.
The logical target of a packet is either the _context or, if _context is not set, the _target.
To determine which logical context the message belongs to you have to determine the logical context. It is found in this order (first hit counts): _context, _source_relay, _source.
See logical source above to determine who the sender of the message was.