3. Node Specifications

3.1 Channel Server

A DarkChannel channel server essentially is a key server providing clients with the necessary public key material for communicating with groups of clients associated with channel names of joined channels of a client.

A channel server MUST receive a client's public key during a HELLO handshake or it MUST terminate the connection. When a valid HELLO message was received a channel server MUST reply with a HELLO message containing the channel server's public key.

A channel server MUST provide the client's public key to all channel member clients of a channel when that client joins the channel. It SHOULD provide this information only to the member clients participating in a group communication on a channel.

A channel server MAY reply with a JOIN reply message when he receives a JOIN request message. The JOIN message MUST contain the channel to join as the first parameter. The JOIN reply sent to the channel member clients and to the joining client MUST contain the public keys of all new clients for that client on that channel.

A channel server MAY reply with a PART reply message when he receives a PART request message. The part message MUST contain the channel to part as the first parameter. The channel server MUST relay the PART message to all channel meber clients and the parting client.

A channel server also SHOULD provide the means for clients to relay messages to other clients via the channel server using a RELAY message.

Today's networks are full of middle boxes implementing NAT or similar network address translation mechanisms. These will hinder clients to directly connect to each other. Allowing the clients to relay messages via the channel server when they can not be directly reached assures that those clients may still communicate with each other.

There is one use case where the above behavior not desirable and that is, when a channel server wants to enforce that clients do directly connect. A channel server MAY request that all clients are directly reachable and it MUST terminate client connections if they are not directly reacheble in that case.

A channel server SHOULD check a clients direct reachability and inform other clients on the result of this check. It MUST inform other clients communicating with the client on the result of the connectivity check and on the service access point (SAP) of that client, if the test for direct connectivity is successful. It does this by including the connectivity check result and the SAP of that client in the JOIN messages containing that client. This allows the other clients to decide if they may try to directly connect to the client to relay messages or not.

A channel server MUST reply with a LIST reply message containing all available channels for a client when it receives a LIST message from that client.

A channel server MUST reply with a PONG reply message when it receives a PING request.

A channel server MUST keep connections active until disconnected by the client or terminated by the channel server because of a protocol error. Expiring clients based on the last message seen results in many problems with mobile clients if the timeouts are not choosen high enough.

3.1.1 Public Key Harvesting Prevention

A channel server SHOULD limit a clients ability to join arbitrary channels in a short time span to limit a clients ability to join all channels to harvest all public keys of all connected clients.

A channel server SHOULD implement further channel access mechanisms as "channel knocking" and "channel invites". It SHOULD provide the means to slow down and hinder a client which tries to harvest all public keys of all connected clients.

As clients are free to create and use new client keys for every new connection to a channel server the issue of public key harvesting gets further mitigated. Nick name public keys can not be harvested this way, as they are presented only to participating clients in a group communication and this only on the owners request.

3.2 Client

A DarkChannel client MUST generate new client key material for each new channel server it connects to. It MAY re-use the key material for subsequent connections but clients are free to create and use new client keys for every new connection to a channel server.

A client MUST send it's client public key durching a HELLO handshake to the channel server it connects to. A client MUST receive a HELLO reply message from the channel server containing the channel server's public key or it MUST terminate the connection.

After a successful HELLO handshake, a client MAY send arbitrary channel and channel server command messages.

A client MAY list the available channels on the channel server by sending a LIST message to the channel server. The channel server will reply with a LIST message containing the available channels and their topics. Not all channels have to be visible to the client, so the client will see only what his access rights allow him.

A client MAY join a channel by sending a JOIN message to the channel server. It will receive a JOIN reply message from the channel server containing all the client public keys of all the channel members of the channel. Subsequent JOIN and PART messages will be received when a client joins or parts the channel.

A client MAY send a message by sending a RELAY message to the channel server. The RELAY message contains the channel or key identifier of the receiver party and the encrypted message for these receivers. The message MUST be signed with the client key material for the channel server connection. The signature SHOULD be marked with an expiry date of maximum 1 day in the future.

The channel server will relay the RELAY message to all parties involved, meaning all channel member clients of the channel specified or the one client with the specified key identifier.

A client MAY send a RELAY message directly to the recipient client(s) if the channel server marked the client as directly reachable when checking the clients reachability on connect.

A client SHOULD send a PING message every 2-3 minutes. This assures that middle boxes in the internet doing network address translation (NAT) will not timeout the connection to the channel servers.

3.3 IRC to DarkChannel Gateway

XXX: TBD