libchat6

About

libchat6 is a complete library that handles an IPv6 only, peer-to-peer, end-to-end encrypted, decentralised, chat client.

Ideas

• transport is IPv6 only
• all clients are identical and no server is needed (some clients might run to act as bootstrap servers but all clients do that aswell.)
• clients have a built-in bootstrap list of IPv6 addresses. This list gets updated when the client connects to the network. This allows the client to always have a recent list of bootstraping IPs.
• There’s no central registration site, therefor users just choose a nickname and have a private/public key pair (generated by the client). Clients are identified by their public key hash.
• Friends can be searched by their nickname or public key (or hash). If a client changes the nickname without changing the key pair, the friend can still be found using the public key (or hash). This process is completely handled by the library and is transparent to the user.
• The interconnection of clients is handled over other clients. The network builds up and paths between clients are calculated similar as routing protocol for routes.
• When a client connects to another to join the network, it will publish it’s nickname and implicitly it’s public key.
• A client may connect to multiple clients, the network of clients will adjust the routing paths according to a metric and select the best path. The metric is the delay in miliseconds on each connection. A regular keepalive query and response is used to measure the delay and the routing information is adjusted accordingly.
• To avoid dead paths, a relatively short keepalive timeout has to be used.
• The network does not allow store-and-forward of messages if the friend is offline. For mobile clients, notifications might be integrated to wakup the client.
• The network only allows users to find other users. All end-to-end communication goes directly. (should we allow relay in case the end-to-end doesn’t work?)
• How do chat group work without having to create a full mesh of connections?
• Should we allow IPv4 only client to relay over a IPv6 client?
• … ?

Protocol

TIMESTAMP PROOF TOKEN TYPE "quoted key=value pairs" ...

TIMESTAMP

The timestamp is a unixtimestamp represented as a 64 bits signed integer.

PROOF

The PROOF token proves the origin of the message. It is composed of the hash of the client concatenated with a random nonce generated by the client and encrypted using the client’s private key and encoded in base64. It is directly followed by the nonce encoded in base64. The nonce should be 16 octets long and should change for every message sent.

Key=value pairs

NOTE: All encrypted data is represented as base64.

• rsa: the RSA public key, represented in base64 in a single line.
• nickname: the nickname chosen by the client.
• icon: base64 encoded png.
• hash: SHA256 of the RSA public key.
• msgid: a 64 bits integer identifying uniquely a message between two clients.
• message: a base64 encoded, encrypted with the target RSA public key message.
• target_hash: same as hash but specifically of the target

path anouncement and withdrawal

<TIMESTAMP> <PROOF> CLIENT ONLINE {rsa, nickname, icon}
<TIMESTAMP> <PROOF> CLIENT UPDATE {nonce, nickname, icon}
<TIMESTAMP> <PROOF> CLIENT OFFLINE 

keepalive

<TIMESTAMP> <PROOF> KEEPALIVE QUERY
<TIMESTAMP> <PROOF> KEEPALIVE RESPONSE

messages

<TIMESTAMP> <PROOF> MESSAGE SEND {target_hash, msgid, message}
<TIMESTAMP> <PROOF> MESSAGE RECV {target_hash, msgid}
<TIMESTAMP> <PROOF> MESSAGE READ {target_hash, msgid}