One core feature of PSYC is the way an entity isn't just a set of data but instead a freely programmable device that can act in whatever way that suits you. Places for example are programmable using psyced's archetype.gen. Persons too could be modified heavily, psyced doesn't support that in the same way as for places, you can however change the code on your own server instance. A person class generator in the same way as the place generator is planned. Currently psyced only employs the root, person and place kinds of entities. Some tools or ideas employ service entities. Here are further details from the specification:

Entity

An entity is any object that can be addressed by a uniform using the appropriate protocol, in most cases either a person entity or a place entity. Entities in PSYC must have:

• 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.

Entity Behavior

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:

• Root
• Person
• Place

Provided for in the spec, but not currently implemented:

• Services

Some entities implement a command interface, to let users actually do something with the entities (like setting the topic of a place).

Channels

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 inheritance

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.