Benutzer:Amogorkon/PiLife/Chat

On registration, a secure password is generated that is also used for creation of a GPG-keypair. The private key is stored locally (with a special warning for safety), the server acts as PK-authority. All private communication is encrypted with the public key of the sender and receiver before the messages are sent. The server logs all communications (except when marked OTR) in a database in such a manner that sender, receiver, timestamp, communications-medium and encrypted message is recorded.

Player-nicknames are used to automatically create a jabber and email address on the network so players can be reached without login. It is possible to enter auxiliary email addresses for message forwarding.

I suggest a general function to substitute mentionings of player's/entitie's names inside messages with account/entity-IP(hash) when sending the message. When receiving, the ID are resubstituted by the corresponding name. This way addressing, also within messages, is uniform and independant from temporary names. On one hand this makes searching logs for references easy and reliable, on the other hand deleting accounts also breaks references, which is desirable for privacy reasons.

Different Ways to Chat

All chat uses a logging facility on the server that stores all messages in a database. The logging facility removes the need to idle or use bouncers on the client side. This is achieved by using the timestamp (ntpd provided, see Time) as unique ID for each message so the client sends the server a list with the IDs of the last X messages it has logged and which labels/channels are subscribed. The server then queries the DB to get the missing messages of the given labels in the given timeframe. The result of the query is packed as XML and sent via XMPP to the client which then joins the result in its own DB.

As messages can contain anything, also URLs to other content, this enables the flood prevention mentioned below, distribution of files via P2P, Twitter, RSS or voice-messaging (hit key to record voice, release to send it as message). Also messages can be filtered and searched in every possible way.

Use-Schema

Schemas can turn specific sets of labels active or inactive, so you can effectively focus on an activity. For instance you can set the schema "coding", which enables the labels of your working group and disables the whole big rest. Or you want to play, so you define a schema "playing" which removes all work/RL-based channels from your focus and allows you to relax without getting distracted. When you switch schemas, the given labels are re-subscribed so the server loads the messages you missed in the meantime.

Names

If you want to address someone, a @ can be prefixed (automatically by the client?), which causes the server to substitute the name by a reference to the account who is addressed. This reference is sticky, which means that it survives namechanges but is also stripped if the account is deleted. This allows label-independant addressing ("poking") in global chat even when the receiver has not the corresponding label active, as well as statistics and automatic alternative message-delivery using other specified channels outside PL like email etc.

Public, Global

This is the main utility for coordinating things globally. Text sent to this channel potentially can reach everyone online, and further (if bridges to other media are built). Global Chat works like one single, big chatroom where also all external media like twitter is piped to. However, every message has to be in one (multiples could be abused) category, which can be done by using a predefined, extendable list of labels. The selection can be overridden by specifying another label inside the message in twitter-manner. People then can use dedicated filters to only get relevant messages for them, without splitting topics by using several unrelated channels. I imagine a filter system where you can have labels

• not subscribed
• no preference
• subscribed

Subscribing a category makes all messages with this label visible to the user, while unsubscribing does the contrary. However, there can be exclusions to these rules like specifying users of which you want to get messages (or not) even though you have not subscribed the category (or the other way round). Messages in categories set to "no preference" are randomly displayed. If there's little traffic for this category, all messages are displayed, if there's a lot, only few are shown. The user also can define the probability of having messages displayed for a category set to "no preference". The labels are not managed. This means that people can use labels in more closed circles by letting only few know about them. One could enforce sending the messages only to people having the label subscribed (excluding those who have "no preference" by using a label like !#closedCircleLabel. This comes close to secret IRC channels.

Treating every message as entry in a db and displaying the chat as listbox makes it possible mark single messages or whole threads as "special" (bad or good) and assigning them a keyword for bookmarking. In global chat, messages are only logged for a day, but when marked, the message is kept for 1 month. If 3 different people or one privileged marks the message, it is archieved and never deleted. Also, 3 normal or 1 privileged user can remove the archiving label, the message then is removed after a month (allowing revision of the decision). A low level of karma can deny you the possibility to mark messages. This way trolls can be limitted in their activities. Moderators also can relabel messages and seperate and join threads this way. Having set a keyword for bookmarking, these messages can be searched and shown in digest.

Public, Local

As you can move around the world playing with your avatar, there's also the 3D aspect of distance between entities affecting communication. In this mode one should be able to select how "loud" to talk - from whispering to shouting.

Private

Special attention needs to go to the private conversations. All communications are encrypted end-to-end and at no time readable by outsiders or even server admins. However, they are logged (headers plaintext, messages encrypted) so that sender and recipients can read them later.

Private messages from one person to another are rather simple to realise. Encrypted one-to-many conversations are more difficult. A feasible way may be the following: The group-founder creates a symmetric key and deposits it encrypted with his own public key on the server as backup. The founder invites someone to the group by encrypting the symmetric key with the public key of the new member. This is done with every invitation. Messages to the group are encrypted with the symmetric key. The server sends these messages to the group. The group-key can be revoked at any time. At that moment, the group is decoupled from the symmetric key and the group basically needs to be recreated (which can be a simple function). However, the old key is kept on the server as backup for the former receivers who still can read up the logs and decypher its contents. Old logs are inaccessible to new members of the group after revocation. Only revocation and recreation of the group can enforce people to be kicked off.

Off the Record

In few cases you don't want any record of a conversation, even if only the headers (time, who to who, which channel) might be readable. In this case you can use OTR which provides an encryption method that allows you to deny a conversation ever happened and also no logs are kept from these.

Additional Features

Translation and Spellcheck

A must for an international communications-platform.

Flood-Prevention

Floods happen if one copy&pastes a huge text and tries to send it. During such a flood, chat is impossible in the channel. To prevent such happening, the server can log the original message (in private chat either way) and instead forward a substitution-link, also indicating the length of the original message, so people can read the text in a seperate window or insertion-like ("click to display full text") without interrupting the chat while still allowing sending messages of great length conveniently.

Another type of flood is made up of a series of subsequent small messages. This type of spam/flood can be auto-relabeled by the receiver (like relabeling the spam from #normalchat to #normalchat-1). A possible treatment there can be a auto-proposed split of the commuications window to (not) display the flood seperate from the rest.

Inner Voice

One of the main functions of the platform is to merge a great number of different communication channels for different purposes, threfor a good filtering mechanism is required. Because it also should be barrier-free and not solely based or navigateable via graphical clues, a new concept is needed. The idea is to use an agent system which assists the player in filtering the flood of information which learns which sort of messages are important in which situations. Also blind navigation ingame can be made possible by text-clues which are processed by the same common text2speech module. The Inner Voice could give clues by colour-highlighting of keywords in messages, visible or audible notification, notification text messages or more functions of various other human interfaces.

Mood-Modes

Smilies and other descriptors of the emotional state are an important part of textual communication. The 3D approach of PiLife can bring these to the next level by so-called Mood-Modes. This is an additional attribute to text messages that describe in which mood the sender is. The default-mode is "informal" which can be modified by shortcuts and buttons to the effect of substituting a great deal of emoticons and smilies by mimic and gesture-animations of the avatar as well as having specific symbols or layout of the text adapted to the designated mood.

This feature is important for roleplay and might be useful in making PiLife barrier-free.