PROTOCOL FOR SYNCHRONOUS CONFERENCING
Last updated 2007
Carlo v. Loesch
Whitepaper on PSYC
PSYC is a flexible protocol to set up a worldwide distributed messaging
infrastructure mostly for text-based conferencing (popularely termed
It was developed with the goal in mind to replace the Internet Relay Chat
protocol, which has reached its limits. It however extends many of the
concepts commonly found in chat and community systems and is
utilizable for purposes such as multimedial communication.
Existing conferencing systems can easily be interfaced into the PSYC
network since the complexity of the protocol resides on the client side.
Basic principle is to not even start setting up a world wide
directory service on the presence of people and existence of
conferences, but rather borrow the URL concept from the web:
assign locators to people and rooms, then let the client programs
set up direct or multicast connections between each other.
The servers have a powerful role in coordination and control,
yet aren't troubled with directory, traffic or routing problems.
Matching this new role distribution for clients and servers
PSYC provides a minimalistic conference control system which
allows for total profiling of conference politics (Who's to join
a group? Who's allowed to listen in? etc.) without affecting
routing (with or without multicasting ability).
What is a chat system?
A real-time synchronous conferencing system, aka a chat system,
is a form of group communication where people sitting at a networked
computer in different locations on the planet get together in a virtual room
and speak with each other typically by typing text, at least these days.
The word "chat" alludes to the typical relaxedness of socialisation
going on in chatrooms, but don't be misled by it: chat systems can
very well be suited as an additional tool for business communication.
What we want
Decentralization is cool
Decentralized structures are commonplace on the Internet,
since they scale best and avoid bureaucracy by design.
For asynchronous communication we have e-mail servers and
clients, for information gathering there is the WWW.
Anonymous FTP is popular for publishing of files and software.
But for synchronous conferencing there is no comparable protocol
What we have
talk, msend, SMTP SEND ..
talk and similar protocols do operate using the client/server
principle, but are aimed at machines where people sometimes log into,
instead of orienting themselves directly at the people.
Systems with a central server
Easy, flexible, everything under control, typically proprietary,
very popular in the commercial arena.
Buddy lists as provided by AOL and ICQ use proprietary protocols and
are based on central database servers. Privacy is also an issue here,
as unsolicited promotional messages can be.
Internet Relay Chat
This is where IRC came in back in 1987, and slowly advanced to become the
biggest chat system on earth.
No matter where you are entering IRC from, you always meet your friends
and colleagues since they always use the same nicknames and channels
Additionally IRC is capable of telling you when certain nicknames,
your friends and colleagues, show up on the net.
Unfortunately IRC suffers of inscalability, bureaucracy, hackability.
Use internet telephony for chatting?
SIP is too simple, H.323 has less conference control features than IRC.
It's a better idea to launch telephony from a well-conceived messaging
system than the other way around.
So what about Jabber™ aka XMPP?
What's good about it
It's good that Jabber has an open distributed network structure
and the concepts of identification and location are quite similar to PSYC.
Jabber is designed as an instant messaging system with a focus on
one to one communication.
Efficient distribution to groups of people is missing although every
update of presence information goes out to a big group of peers!
No surprise Jabber already encounters massive scalability issues.
Limiting the amount of permissible contacts per person cannot be the answer.
Additionally the XML format is enforced, which suggests a certain order
and structure. But on the downside it makes framing impossible, that is
to be able to know where a packet ends without having to analyze all data
as it arrives. Also transfer of files can only be achieved with cumbersome
And then there are a thousand little oddities that fippo had to deal with
while he worked his way through the implementation. You can find some more
hints like that in the
jabber2psyc help page.
Why is it so hard?
What's the problem?
The reason why there isn't a simple and clear solution to the
problem yet lies in the complexity of
as well as in the
management and routing of conferences.
How do we get over this?
First of all, throw out the directory service by introducing a global
Then make someone really in charge of conference control, and rather
ensure that the administrative power over chatrooms is distributed over
the whole world according to where the people using them are.
We'll get to both of these points now:
Uniform Network Identifications & Locations
This is how people modeling works with PSYC: UNIs like
induce a client implementation
to connect to the psyc.kanzleramt.de server.
A program answers on that server that acts on behalf of chancellor
Schröder. It will accept the message and maybe deliver it to wherever
Gerhard is located, be it in China or Tuvalu. It might aswell be instructed
to allow for a direct peer to peer connection between the two clients.
In this case it would require a UNL, such as
By the way: ve stands for "virtual environment".
advantages of addressability
UNIs (The term resource in URI
is just slightly unfriendly to humans) give you a huge amount of benefit:
They can be interspersed into the web, appended to e-mail signatures,
or appear on business cards, papers and magazines.
It will always either put you in touch with the person right away,
or let you leave a note on the answering machine.
nicknames are owned
The UNI allows for easy authentication schemes which guarantee
the identity of a given person, so you won't be able to "fake"
another person by taking his nickname, as it is feasible on IRC.
Applications of UNI+UNL messaging
Should Gerhard be busy playing golf with Bill
his home-server will accept messages for him, or
simply "call back" as soon as the chancellor is back at the keyboard.
Or it could be voice control.
Simply to be able to send messages "around the corner" brings
a lot of potential applications. Think of BITnet's "tell" command,
you could execute it from within all kinds of automations and
scripts, for example to announce the arrival of e-mail, notify you
of machines crashing or computation jobs completing.
PSYC even supports foreign uniform schemes within its protocol
so that routing messages to gateways is not a problem.
Protocols, which do not have the ability to reach the receiver
location-independently could be taught to do so by gatewaying them
into PSYC. I will name a few, that may or may not be familiar to you:
An internet messaging protocol is useful for a whole range of
applications. Which ones come to your mind?
Other approaches to this particular issue
Dynamic DNS (exposes personal computer)|
IPv6 (waiting for godot)
SIP (although beyond original scope)
Jabber™ (a bit cumbersome, but works)
Conferencing: rooms and groups
This is what a UNI of a conference session would look like.
It points to a group manager object and suggests the client should
ask the named server for access to this group,
but it could actually call on all kinds of methods in this object.
The "@" sign simply declares this object to be compliant to the
room interface, so it can be entered.
Both conference control and routing are programmable in the manager of the room!And yes, you can have more than one manager if you think one alone isn't safe.
The multicast principle is fundamental to PSYC
PSYC has a notion of routing and delivering to multiple recipients on the
lowest layers of its design. This sounds so obvious, it is hard to believe
only very few multicast technologies really exist. Even the word itself
has turned into a synonym for one particular technology, IP Multicast,
which for most purposes isn't even suitable.
With its basic concepts of context, logical targets and packet ids
PSYC consumes a lot less bandwidth, makes it easier to detect abuse
and implement efficient protection against "SPIM" (messaging SPAM).
Let's take the junction networks as an example. They are one of several
multicast strategies of PSYC. They are an IRC-like tree structure, but
a lot more efficient since the involved rooms create an optimal tree
themselves rather than relying on the topology of an IRC network.
They are wonderfully suited for the delivery of news headlines, a lot
more efficiently than unicast poll technlogies like RSS ever could be.
Also applications like BitTorrent could make extensive use of the
realtimeness of PSYC as an announcement medium.
The context slaves are a much more everyday approach to multicast
where better routing is automatically figured out as soon as there are
more recipients linking into a transmission from a specific source.
This happens behind your back and keeps traffic low.
multipeer to peer
You may not want your servers to deal with bandwidth intensive
applications like file transfers, but rather have the users communicate
with each other directly, peer to peer. That's very welcome in PSYC too
and thanks to the UNI and UNL easier to set up. Then again you may find
it interesting to create hybrid applications between backbone and peer
to peer networking.
PSYC is conceptionally open to supporting new and even external
multicast strategies. Did you know GPRS has builtin multicast
subprotocols? We'd like to use those. Or even plain IP Multicast,
should we ever need that. With packet ids we are able to support
redundant topologies and/or lossy subprotocols, where it is fundamental
to sort out duplicates, or where the duplicates tell which one is the
Programmable conference control
programmable conference control
This doesn't mean the manager object will always let clients in.
In fact it can use whatever strategy it likes to, to determine
who's allowed to enter the room.
You could let people in by asking for a password, or only those
who have been invited or those who are in a fixed list of authenticated
users, or maybe just everyone within the domain
I particularely like the thought of end users being able to set up
their own persistent rooms just like they want them, by using HTML
forms for instance. And should a feature be missing in the form,
the user could ask the server admin to implement it.
In general only the manager object has the authority over the conference
such that it can set up its properties and modify its member list.
This protects conference sessions from take-overs as they happen on IRC.
distributed communication however
The actual message interchange between group members can happen
directly peer to peer, through servers or proxies if you want it to,
or via a multicast layer. This is achieved via PSYC's
minimalistic conference control module, which basically gives
the members a list of the other members, how they can be reached
and, for the purpose of making moderated rooms, wether they are
speakers or just listeners.
The social network of your friendships can be modeled as a room.
This way your presence updates can be delivered efficiently
It has become extremely popular to send an email to all friends. By using
friendcast you can also reach out for the friends of your friends, if you
want to and they agree. So you could invite your entire social network
to a party. Yes social networks, decentralized, open source and combined
with proper multicasting.. There's quite some interesting potential in there!
Switching to other protocols
choice of protocols
The action of forwarding a person identification (UNI) to
the current client software of this person isn't necessarily
limited to one single UNL. A whole collection of protocol schemes,
port numbers and even multicast schemes may be passed on so that
more sophisticated communication systems may be integrated.
VoIP, SIP, Audio/Video-Conferencing
Now if we had UNL-schemes for all sorts of audio and video
conference systems, PSYC would be able to negotiate for them easily.
PSYC even provides much more evolved conference control than
these systems usually provide.
On the other hand developers of such real-time systems would no longer
have to worry about conference control and simply concentrate on
making good streaming protocols.
multicast routing with or without PSYC
It's useful to have a choice of protocols even for text-based communication.
Multicast strategies, from the PSYC-based network of proxy servers
to PSYC over Multicast IP (with the help of PIM-SM probably) up to
totally independent multicast or even broadcast schemes.
Optional protocol modules
For completeness PSYC itself offers the ability of defining
the content type contained in messages, so it doesn't necessarily
have to be plain text, it may just as well be text/html or image/jpeg.
It is then up to the implementor to decide what to do with
module for binary content
Appropriately, PSYC has the option of binary content delivery.
Combined with a fragmentation option you can implement multicast
file transfer over any of the supported multicast protocols, even hybrids.
Or you might switch to a multiplexing variant of PSYC.
the concept of modules
But it is only necessary to implement those modules that are needed
for the application, so a minimal PSYC server is quickly coded.
The basic functionality of PSYC, delivery of text messages, is
guaranteed however and per se very useful.
You're welcome to conceive your own modules and add them to the
Example of a protocol message (verbose)
example of a message in PSYC's unabbreviated format
=_identification psyc://psyc.cool.org/~cool :_target ~suzie =_nickname Coolman =_nickname_alias Cool =_description As cool as ice ice baby :_action whispers to you _conversation Hi! Any plans tonight? .And here's what Suzie is probably going to see:
here's what Suzie is probably going to see:
Coolman whispers to you: Hi! Any plans tonight?
Example of a protocol message (compact)
The same message in PSYC's compact format
=i psyc://psyc.cool.org/~cool :t ~suzie =n Coolman =n_alias Cool =D As cool as ice ice baby :a whispers to you c Hi! Any plans tonight? .
PSYC 1.0: compact keywords will be introduced.
The detailed specification of the protocols resides at http://www.psyc.eu/tech.en.html.
Ways in and out of IRC
Access by using an IRC client
The psyced software has the built-in ability to emulate an IRC server
so you can access most of the strengths of the PSYC dimension with your
favourite IRC client, like these:
Gateways into IRC networks
IRC is still very popular, and since IRC cannot handle all its users
within a single network a broad variety of networks has arisen since
the dramatic split of 1990. That was not the intention of IRC.
psyced provides gateway solutions which makes IRC users addressable
from PSYC using irc:-URLs. You can't always be sure that the same person
answers on the other side, but it's better than nothing.
PSYC could even act as gateway between IRC networks and the Jabber™.
Compression and encryption
The protocol supports multiple encoding formats applied onto each
other, like TLS/SSL on top of zlib. GnuPG/PGP would be an obvious
option for end-to-end cryptography applications, but we prefer the
OTR approach and would like to support that natively.
Future: interface descriptions for PSYC objects
For chat and messaging purposes the interface descriptions suggested
by the ~ or @ characters in a UNI are sufficient. Ulterior methods
may be guessed. Should developments go far beyond this, we may
need an interface description syntax at some point. So far it hasn't
Conceptional merge of chatrooms and buddy lists
Broadcasting your presence information to your friends is implemented
as a special case of a chatroom where you have the chance
to apply all features and flexibility of elaborate conference control
to manage your contacts, and at the same time we end up with less code.
What's available today?
isn't just a PSYC
server; it also implements the functionality of PSYC clients allowing
users of Java applets, Telnet, Jabber™ and IRC clients to enter the PSYCspace.
can communicate with Jabber™ servers and provide
chatrooms for PSYCers, IRCers and Jabberers all at once.
It also provides gateways to several IM- and IRC- networks as well as
serving as a web server for distributed multi-user applications.
It is implemented in LPC and
released as open source.
Scalable, programmable, effective.
... are not so important at the current stage of PSYC development,
since psyced acts as client simulator and allows you to use your
favorite IRC or jabber client applications. You can even just use the
web access if you're not planning to install your own psyced.
The developers themselves currently like to use IRC clients, PsycZilla, psycion or an
enhanced unix telnet software called powwow.
Once you have become familiar using psyced as a server, you may want to dig deeper and look at native PSYC applications:
Based on Mozilla you can either install it as a Firefox Extension or
standalone. It is a graphical crossplatform client with neat web
integration. Absolutely try it out!
psycion is the most elaborate PSYC client to date. It is aimed at unix
console users and comes with a very fancy curses-based multi-screen
interface. The code is modular so it is easy to add a GUI.
psycion is being distributed with perlpsyc.
comes in a package with a collection of PSYC automations, command line
messaging scripts, the cool psycion client and even an MP3
player you can remote control using PSYC messages
or the command 'psyccmd <command>' from any shell prompt.
jaPSYC, Psychedelic and other Java™ apps
Mario 'BitKoenig' Holbe started out developing this library in Java
back in 1996 while I was sorting out basics of the protocol syntax.
Later on, I decided to motivate him to finish his work. The result is an amazingly
elaborate implementation of the protocol suited for all sorts of client,
server or hybrid applications. This development library is available
free of charge as open source.
AboutCarl von Loesch has been developing chat systems since 1988. During his work on IRC software he introduced the notorious /me command. Commercially successful with PSYC-based high scalability chat solutions from symlynX. Join our upcoming MTV Europe Music Awards Chat Event! And because all of this is actually quite boring he also makes music. You can buy it on vinyl or CD. And you can listen to his radio shows.