Presence in PSYC
<draft-vonLoesch-presence-00>
http://www.psyc.eu/presence.html

Abstract

The Presence Model and Protocol in PSYC introduces a new degree of abstraction concerning certain aspects of presence, by giving them mathematical values rather than random string names, and by seperating them into different fields in a logical fashion.

Introduction

Excuse the language chaos. Some paragraphs aren't translated yet.

Die sinnvolle digitale Umsetzung von Presence also Anwesenheit/Erreichbarkeit ist eigentlich eine faszinierende informatische Herausforderung, die von den dafür etablierten Internet-Protokollen bisher etwas stiefmütterlich behandelt wird: IRC hat dafür den /away Befehl, der eine Abwesenheit implizieren soll an die sich aber keiner hält. Die Flexibilität eines freien Textes ist jedoch vorteilhaft, und wurde auch in Jabber aufgenommen - allerdings nur als Sonderfall der sonst an ICQ angelehnten, mit Keywords fest gekennzeichneten Zuständen. Weitere IM Systeme halten sich mehr oder weniger ebenfalls an die Keywords. Das legt eine Einfachheit des User-Interfaces nahe, aber warum sollte das Protokoll auf das eingeschränkt werden, was das User-Interface beherrscht? Lasst uns nicht allzulange darauf eingehen, sondern lieber den Plan aufzeichnen für eine höher abstrahierte Form der Presence, welche den Bedürfnissen der Menschen eher gerecht wird.

Model

Presence in digital communications is defined by several factors which should consciously be kept in different data fields:

1. Availability (from chatty to on vacation, numeric)
   _degree_availability
2. Descriptive text or motto of the day
   _description_presence
3. Mood (happy or sad, numeric)
   _degree_mood
4. Bandwidth (how are you connected right now? numeric)
   _bandwidth
5. Physical Position (country, city, or even coordinates for good friends)
   _position
6. Technical Presence
   _time_idle, _time_response_estimate

Wobei, wie in PSYC üblich, keine dieser Informationen zwingend sein muss und sie zudem für jeden Empfänger unterschiedlich aussehen kann. Die idle-time etwa, kann als Eingriff in die Privatsphäre empfunden werden, selbst wenn man diese Information nur seinen besten Freunden zukommen lässt.

Nützlich an diesem Plan finde ich, dass man so einen ungewöhnlichen Zustand wie "mit GPRS-Handy gelangweilt auf die Trambahn warten" gut darstellen kann, und sich die Gegenseite also darauf einstellen kann, sich intensiv mit der Person zu unterhalten, ohne ihr verziehrende unnötige Multimedia-Dokumente zuzuschicken.

Wer an dieser Stelle andere Einteilungen/Felder vorschlagen mag, her damit - aber sollten weitere Erkenntnisse erst in der Praxis kommen, kann man PSYC auch leicht nachrüsten.

Specification

Ansprechbarkeit, idle time, Bandbreite und Laune ergeben, wenn man mag, einen vierdimensionalen Raum in dem die Menschen presence-mäßig positioniert werden können. In der Praxis muss man diese Dimensionen beziffern. Zeit ist klar. Bandbreite könnte man auch in gängigen realen Werten bezeichnen. Die anderen Felder kann man numerisch einstufen und dann in benannte Bereiche aufteilen für den Praxisgebrauch (oder man verwendet tatsächlich auch in den GUIs Drehregler und Ampelfarbabstufungen).

Values of the _degree family are floating point numbers, only to make things easier the leading "0." is left out. So an availability of 3 is formally 0.3 and 33 is 0.33. psyced however simply ignores any following digits and only uses the first.

Protocol: Presence Multicasts

Presence changes are multicast to all or a channel of peers (friends), using your _context according to PSYC multicast. A presence change looks like:

.
:_context	psyc://my.server.psyc/~nick

:_degree_availability	3
:_degree_mood	6
:_description_presence	having coffee
_notice_presence_away
.

Other variables are not in use yet. Also we are currently encoding availability in a redundant way, because the method roughly also expresses it. This makes the use of textdb easy, but we may want to step further and reduce the choice of presence notices to one single _notice_presence.

Protocol: Presence Unicasts

There are situations when you want to _request_presence from an entity. You may want to provide a _trustee. If the recipient finds you worthy of a response, it would look just like a _notice_presence. only it is no longer an update, thus it is called a _status_presence. Also, it is no longer multicast but only unicast to you, thus it would have a different MMP header with _source and _target rather than _context.

But in many cases a unicast is not necessary, as every recipient (UNI) of a multicast is to remember the last presence update received for every person, so it can update its clients from its cache, rather then request it by unicast from the original source (which doesn't scale).

Updating the client could be achieved by MMP re-request of the last multicast packet, or by generating a _status_presence with the original source as _source_relay. Then again it could have its own protocol as part of the dump of peer profiles that a client typically needs from the UNI. This isn't implemented as yet.

Implementation

Und wenn die Werte nun gegeben sind, können wir sie in Bereiche aufteilen. Für die gewählte Ansprechbarkeit so:

• 1.0: realtime verbindung besteht (etwa per audio/video)
• 0.9: chatfreudig
• 0.8: normal anwesend
• 0.7: schaue grad nicht aufs fenster
• 0.6: beschäftigt
• 0.5: nicht am computer, aber dennoch anklingelbar
  beispielsweise in der küche, oder vor dem fernseher..
• 0.4: bitte nicht stören
• 0.3: kurz weg
• 0.2: lange abwesend
• 0.1: nicht erreichbar
• 0.0: zugang erloschen? oder sollte das dann ein _redirect sein?

You can convert the values to percentages when presenting them to the user, or you may want to use a mapping to human strings as psyced does for availability and mood.

Dies lässt noch Spielraum für spätere Bezeichnungen. Die eintreffenden Werte können also zum nächsten benannten Wert gerundet werden und der dazugehörige Text ausgegeben. Man kann die Werte auch an einem Drehregler oder mittels Helligkeit, Regenbogenwert oder Sättigung darstellen.

Mittels Ansprechbarkeit kann man auch logarithmisch einen Zeitwert errechnen, welcher einer groben Reaktionszeitabschätzung entsprechen mag. Ein Client kann somit nicht nur eine Abschätzung von sich geben, wann eine Nachricht den Empfänger wohl erreichen wird, sondern auch anhand seines durchschnittlichen Präsenzverhaltens solche Werte für den eigenen Benutzer einschätzen. Die in den Texten angedeutete Semantik ist daher mit einer Prise Salz zu genießen. Die Formel für eine "estimated response time" steht noch aus.

Noch besser ist es allerdings die _time_response_average zu berechnen als statistischer Durchschnitt zwischen einkommenden Privatnachrichten und dem direkten Antworten des Nutzers. Direkt bedeutet, dass sich der Benutzer als aller erstes der Beantwortung gewidmet hat, als er sich wieder mit der Kommunikationssoftware beschäftigt hat. Wenn er stattdessen beschließt jemand anderem oder einem Raum zu schreiben, wird die Zeitmessung verworfen.

Bandbreiten kann man ebenfalls Bezeichnungen zuordnen, das kann uns jedes File-Sharing-Tool vormachen, daher lasse ich das mal beiseite.

Discussion

ChosenOne hat den Standort vorgeschlagen, und meinte damit Daheim, Arbeit, Schule etc. Das sieht zunächst wie ein Freitext aus, den wir ja schon haben, halte es aber für möglich typische Orte menschlicher Existenz in Kategorien zu stellen: @home, @work (= Büro, Uni, Schule etc), mobile (unterwegs), @other (bei Freunden, im Cafe, am Strand). "Auf Reisen" gilt nicht, weil man auch dort in einem der oberen 4 Zustände sein kann. Ist die Frage ob eine abstrakte Standortsbezeichnung wirklich nützlich ist. Würde man Applikationen machen, die damit etwas sinnvolles anfangen? Etwa alle Mitschüler aus der Freundesliste ausblenden, weil man ja eh in der Schule sitzt und sie alle da sind? Sind sie ja nicht zwingend.

Privacy

Man bedenke weiterhin, dass all diese Informationen typischerweise nur den Freunden zugänglich gemacht werden, je nach Freundschaftsgrad, und zudem auch "gelogen" sein dürfen. Dies ist mit Sicherheit besser als alle bestehenden Technologien, die, falls sie dieser Art Daten sammeln und weitergeben, dies gerne zu freizügig tun und mit inkorrekten Angaben oft nicht umgehen können oder wollen. Daten kommen so oder so auf und zu, also lieber in einer Form in der wir Kontrolle darüber haben.