<filewiki_vars>
title=Nodes
menu=$title
</filewiki_vars>


# 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_
