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.
Contents |
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.
_notice_presence
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.
_request_do_presence
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.
CTCP PRESENCE
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
SIMPLE
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.
XMPP
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.
PSYC
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.
Psychology
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! ;°)