Who's here or away. who or what is subscribed to whom or what. Multicast presence and generalized subscriptions solve a broad range of issues from online-notifications to autojoins and newscasting.

Being in and out of something is a too trivial simplification. in the future you won't be totally offline, you'll just be lesser connected, like with a GPRS mobile phone.


Current Status

Availability and Mood

See http://www.psyc.eu/presence for the presence model in PSYC. The current set of availability levels is defined in http://www.psyced.org/dist/world/net/include/presence.h and most of those 'define' names are equivalently available as commands (like /HERE or /UNAVAILABLE). There are also /AVAILABILITY (/av is enough when typed) and /MOOD commands to assign those values as one-digit numeric values. All commands allow you to append a free description of your current presence (the popularely called away-message). Most of these commands will trigger a multicast to all your peers about your change in presence.

Concerning "basstscho" and other silly mood words, they were just meant to be temporary. They should be replaced by the more useful English word representations of mood degrees given here:

		0	:	"",		// unspecified mood
		1	:	"_dead",
		2	:	"_angry",
		3	:	"_sad",
		4	:	"_moody",
		5	:	"_okay",
		6	:	"_good",
		7	:	"_happy",
		8	:	"_bright",
		9	:	"_nirvana"

These also appear in http://www.psyced.org/dist/world/net/library/share.c together with a simple mapping to XMPP moods. You are still very welcome to make suggestions for better words. Nirvana for example could be "bliss" or "blissed" instead.


psyced currently sends the new presence messages as submethods of _notice_presence, like _notice_presence_vacation. I am not sure if that is a good practice (it is however practical in conjunction with textdb), or if we should only send _notice_presence and leave the rest to the numeric values. when implementing presence, please ignore the mc variants and use the numeric availability degree.


This is the command request a client is supposed to send to its identification for it to multicast the change to all subscribed parties.

Among the supported variables are the in the presence draft aforementioned (see link at top of page) _description_presence (in IRCer slang the away message), _degree_availability and _degree_mood.

An extra argument called _degree_automation indicates if a change in presence has been issued manually by the user or at different degrees of automation issued by the client. For instance a client that generates an idle-away-message automatically and has no setting to disable such behaviour should send maximum _degree_automation here, which would be 9, whereas a client that has been instructed by the user to generate certain messages given certain conditions would provide some appropriate value between 1 and 8. Only absolutely manually triggered presence may be transmitted with a _degree_automation of 0.


psyced supports an experimental IRC protocol extension which delivers PRESENCE information in form of a CTCP NOTICE (like a reply, because maybe one day i will let you request it using a PRIVMSG CTCP PRESENCE).

The message is formatted as follows:

: <source> _ NOTICE _ <you> _ 0x01 PRESENCE _ <availability> _ <mood> _ : <description> 0x01

<source> is the sender of the message, <you> is your nickname, _ stands for spaces, 0x01 is msa's CTCP control character while the three fields within the CTCP PRESENCE are the equivalent ones of the PSYC PRESENCE packets.

If you'd like to receive these messages instead of the human readable notices, please issue a +set ctcppresence on

You may also +set presencefilter off to avoid certain lesser important state changes to be filtered by psyced (in case you are building a buddy list for your IRC client based on this protocol).

Link vs Presence

The concept of being linked (thus online and offline) has been separated from the concept of presence.

A user may decide to switch clients or accesses without wanting the identification to go tell everyone about it.

So when logging in with a PSYC client, no presence announcement is sent automatically, and when leaving you can either use /detach or /quit. This behaviour could be extended to the IRC clients, too, making it your responsibility to set your /availability.

Scalability Analysis


One problem with SIMPLE is, just like Jabber it doesn't multicast presence. It round-robins a copy of the presence update to each subscriber by unicast. See the load analysis for details. At least it typically uses UDP which is likely to make it more lightweight.

Cisco's view sharing proposal addresses this issue in a similar way to our context slaves. They call it view sharing. Quote:

One of the primary challenges in presence federation is scale. With a large number of watchers in one domain obtaining presence for many presentities in another, the amount of notification traffic is large. [...] View sharing allows the amount of presence traffic between domains to achieve the theoretical lower bound on information exchange in any presence system.

That second sentence is actually incorrect: A multicast tree distributes presence information more efficiently than simple view sharing.

A "view" is a particular sequence of presence documents that come about as a consequence of a particular composition, authorization and privacy policy.

In PSYC this is addressed in a more abstract/generalized way by the channel concept.

View sharing however requires a separate pre-negotiation of recipients, this makes implementation unnecessarily more complex and brings in new security and trust implications. It's also unnecessary extra traffic. Context slaves simply use the existing subscription agreements between entities, thus need no extra negotiation. They work out of the box and are naturally safer from abuse like SPAM.


Because the Jabber people had to prove that they're better than SIMPLE, they've published their own Internet draft on Presence Scalability. And fippo is finally granted 200 bytes per presence stanza! Should we mention that smarticast would reduce the number of messages sent by a factor between 4 and 20, depending on the scenario?

<fippo> much of the simple traffic amounts to a robustness that xmpp does not have. Of course the draft does not even mention that xmpp has such a problem.

... one year later the SIMPLE folks have found the document and commented it.


Not so easy to figure out. The simple context slave approach already optimizes a lot (It is like smarticast but without the XML overhead), harder to add to the maths is the improvements brought in by multicast and the decentralized state.

<fippo> What about using the same scenarios that XMPP has abused? We should present two pareto-optimal designs though, one which is cheaper on memory but more expensive on traffic (aka: send 'presence probes'), the other being a presence-multicast only with no presence probes and expensive replys, being cheaper in terms of traffic but requiring more memory storage.


fip hotzenplotzt: wenn man jemandes presence anguckt
fip hotzenplotzt: aber dem die eigene nicht zeigt
fip fragt: ist das stalking?

Related Materials

Wikipedia:Presence information.

Linux Presence Framework

galago looks interesting...

Schulzrinne strikes back

Henning and the MBONE people have produced RFC 4480 and RFC 4482 which provide even more funny states and options for rich presence.

They don't have the sort of mathematical presence model we are providing, but they are bringing up some interesting ideas that we could integrate and even gateway to.

Presence is the new dialtone

... says this 2005 white paper from Alcatel.

Intelligent aggregation automates user presence so that users don’t have to manually set and update their presence state. The transparent aggregation of presence from all available sources is essential for widespread usage.

That's why PSYC has a mathematical presence model, rather then string constants. The document also mentions the SPAM problem in the current friendship model.

Presence filtering

Rich presence information must also be distributed intelligently as user and administrator acceptance depends on the implementation of privacy, security and policy. For example, an administrator might impose security restrictions on the distribution of presence information imposing a presence “firewall” to protect the enterprise.

This yearns for channels.

Group presence

The concept of group presence is an interesting new challenge. If anyone of a group could be the person to answer your needs, why not have the entire group as a buddy in your buddy list rather than individuals?

The obvious way to implement this is to subscribe to the presence of a place, then the place signals its presence depending on the cumulative presence of its members, using whatever maths it may find appropriate.

Moody Jabber

Even Jabber has now come up with a mood plan.


Both of the above seem to interpret mood not as a value between happy and sad, but rather as a superhighway for all sorts of feelings which obviously reminds me of good old

MUD Feelings

Here's help feelings from telnet nemesis.de 2000

agree           ahh             apologize       applaud         bang
beg             bite            blush           bounce          bow
breath          burp            cackle          caress          cheer
chuckle         clap            comfort         congrat         cough
count           crow            cry             cuddle          curse
curtsey         dance           dance like <txt>                daydream
despair         disagree        dream <about s.o>               drool
envy            embrace         excuse <to s.o> faint           fart
fear            five            flip            fondle          french
frown (at s.o)  gape            gasp            giggle          glare
gnash           greet           grimace         grin            groan
grope           grovel          growl           grumble         headbang
hiccup          hmm             hold            hold breath     howl
hug             hum             jump            kick            kiss
kisshand        knee            kneel           laugh [burst, crawl, prust]
laugh (over s.o.)               lean            lick            listen
love            meditate        moan            moonwalk        mosh
mourn           mumble          nibble          nod (at s.o.)   ovat
pant            pat             pat  s.o. on shoulder           peer
pinch           point at sth    ponder          
poke someone [eye, ear, stomach, nose]          pose            pogo
pout            praise          puke            punch           purr
puzzle          raise           roll            rub <anything>  ruffle
scratch         scream          shake           shame           shiver
shriek          shrug           sigh            sing [someone]  slap
smack           smile           smirk           snap            snarl
sneeze          snicker         sniff           snore           snuggle
sob             spit            sputter         squeeze         starei
stomp           strangle        stretch         stroke          strut
sulk            swear           sweat           tap             thank
think           tickle          twiddle         twinkle         view
wait            wander          wave            weep            whimper
whine           whistle         wiggle          wink            wish luck
wonder          worship         yawn

See 'help adverbs' for the adverbs you can use with these feelings.
Example: 'grin demonically' where you can abbreviate it to 'grin dem'.
Only the first three characters are usually needed.

The reason why MUDs have such extensive action and feeling commands is because in a MUD you cannot allow players to freely create actions as you do in a chat with the /me command.

Talking about history.. The 1995 MMP specification (which looked similar to http://www.psyc.eu/mmp ) already mentioned a _mood variable embedded in the protocol. It was a joke back then. Heh!  ;°)