|
|
|
|
The AVATAR idea Extending IRC fun: the AVATAR idea |
Introduction |
|
Starting from version 3.0.0 KVIrc supports the AVATAR protocol.
The AVATAR term dictionary definitions include: - Hindu mythology incarnation of a God - Embodiment of a concept or philosophy - In cyberspace communities, the representation of an user in a shared virtual reality. The AVATAR protocol attempts to improve the IRC communication by adding a method for associating a graphical representation to an IRC user. Since this may involve binary data transfers between users, the protocol is intended to be client based. |
The terms |
| The user that wants to offer a digital representation of himself will be called source user. The ones that will receive the notification will be called target users. Every IRC user can be either a source user or target user. |
The idea |
|
Every IRC user has a client-side property called AVATAR. Let's say that there
are two users: A and B. When user A wants to see the B's avatar he simply sends a CTCP AVATAR request to B (the request is sent through a PRIVMSG IRC command). The presence of the avatar is announced by the ASCII sequence ETX, one of '0'-'7', SI, which doesn't show up on IRC clients, at the start of B's realname, where bit 2 (the fours place) of the ASCII digit is set when an avatar is present. (Bits 0 and 1 are unrelated to avatar negotiation and should be left unset if not being used.) User B replies with a CTCP AVATAR notification (sent through a NOTICE IRC command) with the name or URL of his avatar. The actual syntax for the notification is: AVATAR <avatar_file> [<filesize>] The <avatar_file> may be either the name of a B's local image file or a URL pointing to an image on some web server. The optional <filesize> parameter is sent only if <avatar_file> is stored on the B's machine and there will be more info on that later. Anyway, after A has received the notification he tries to locate the avatar file in its local cache (yes, <filesize> may help here and more on this later). If the file can be found and loaded then it is simply displayed in some way near the B's nickname otherwise A must download the avatar from some place. If the <avatar_file> contains a leading URL prefix (http://) then A fetches the image from the specified URL and after that displays it near the B's nickname. If the <avatar_file> does not contain the leading URL prefix then it is assumed that B offers this file for downloading via DCC from his machine. In this case A may also avoid requesting the file if the <filesize> is too large and the transfer would occupy too much bandwidth (for example). The DCC download is initiated by issuing a DCC GET <avatar_file> request to B. B may then reply with a standard DCC SEND or a DCC RSEND (KVIrc's extension). The implementation of the DCC GET protocol is defined by other documents here around :). The CTCP AVATAR messages can be sent to a single user, a set of users or a channel: this depends only on the source user and how many clients he wants to reach. There should be a convention on the image sizes: not a protocol limit. For example, the convention could be that all the images should be smaller than 129x129 pixels. The preferred image format is png (Portable Network Graphics) since it allows good compression rates without compromising the image quality. Other formats may be accepted as well (Theoretically this protocol could be extended to allow movies or 3D images). The preferred image size may grow with time, as the network transmission speed grows. |