The desktop integration
mechanism for Sun
's OpenWindows desktop environment
. It allows applications to communicate with each other; the main effect to the user is that things like drag and drop
It uses an RPC daemon, rpc.ttdbserverd, that maintains a database with desktop session information, stored in the TT_DB directory on a mounted file system.
There is also a ttsession wrapper around applications that is used to provide Tooltalk support; furthermore, the OpenWindows window manager olwm has special support for Tooltalk.
Tooltalk lives on in CDE, and CDE is available on many different Unix variants.
Tooltalk was never a success.
Knowledgeable users, confronted with OpenWindows, tend to replace the OpenWindows standard apps with non-OpenWindows ones that work better, or run an entirely different desktop environment. They will never need Tooltalk.
But even on completely default OpenWindows desktops, where users know no better than to use the default OpenWindows apps delivered with the system, Tooltalk isn't used much. This is because even in those apps, most of what you can do with them doesn't use Tooltalk at all.
And this is just about the only good thing that can be said about Tooltalk.
The bugs in Tooltalk's design and implementation make OpenWindows unreliable (e.g. sessions that hang after the initial login); the main problem is the location of the Tooltalk database, which often ends up on a NFS mounted filesystem, an inherently unreliable setup. Also, at least one security hole was found in it, with known exploits all over the planet; scan Bugtraq for rpc.ttdbserverd for details.
Where Tooltalk is available (e.g. on Solaris systems configured to run OpenWindows or CDE), system administrators often disable it by commenting out the rpc.ttdbserverd line in /etc/inetd.conf.
Meanwhile, Tooltalk is very interesting as a design experiment. It was an early attempt to provide desktop integration for X applications, without the huge amounts of resources and code that modern solutions like KDE or GNOME throw at it.