Denatured Ethyl Crew

sdchat rfc

Go back to sdchat.

This is the current sdchat RFC. This document still needs more explanations on how to implement the protocol.
Important: this document is out-of-date and may not reflect the current implementation.

Basic protocol syntax

All command names and features must be case-sensitive.

Initial status for newly connected avatars is always "Available". The current implementation encrypts HI, MESSAGE, EXTENDED and extended commands.

`HELLO' is left clear because of handshake. `BYE' is left clear because of routing when a node goes down. Both `HELLO' and `BYE' must be routed at nodes level instead of avatars. `PING' is left clear because it's a node to node message. Notice that in the above cases the source of the message can't be verified anymore.

The `PING' command doesn't expect to receive a PONG, it's only needed to keep the connection alive and to track lag.

Whenever data is encrypted, the data must be also signed in order to obtain the source avatar id.
In a GPG implementation, AVATARID is the 8-chars hexadecimal pub/sub key identifier.

Examples (E{} means encrypted-signed data, ?? means length depends on ecryption):

16 - HELLO A234567F
?? A234567F E{HI speexoggaudio,rooms Available}
?? A234567F E{MESSAGE my message}
?? A234567F E{EXTENDED speexoggaudio}
12 - BYE A234567F


Implementations must exchange a common protocol for extended features.

standard features

rooms

Potential avatar IDs are the avatars that have either joined the room or been accepted in the room and waiting for joining. It's the case when an avatar in the room invites another avatar RHELLO'ing him and waits for a RHI response.

speexoggaudio

This protocol encodes audio in Speex, contained in the Ogg format. The message is being compressed in bz2.
The handshake is needed as the Ogg demux needs the complete flow of the buffering since the beginning (first chain).
Each avatar must listen for data playback when starting the meeting without recording until either an SPEEXOGGHELLO or SPEEXOGGHI is received. Once recording is started, all buffers must be sent to the remote avatar as it's an OGG stream.

files

This protocol is supposed to support resuming in case one of the peers disconnects. This is ensured by telling to the sender the sent bytes in `SEEK'. `ID' is an arbitrary positive ordinal number generated by the sender that must be unique per avatar file transfer.
The `filebye' command is sent by one of the two peers, still connected to the net, to abort the file transfer.
Hash sums must be in HEX digest to avoid spaces in the command.

editor

The ID is an arbitrary positive ordinal number generated by the sender that must be unique per avatar editor. `OFFSET's are offsets in chars from the start of the editing buffer. The editor has a lock that's owned always by one and only one of the two avatars. Initially the lock is being acquired by the sender.

paint

The ID is an arbitrary positive ordinal number generated by the sender that must be unique per avatar painter. Coordinates are integer numbers.
`DATA' format is PNG.

Design and contents by DECrew licensed under a CC Attribution-Noncommercial License.