A library for a decentralised peer-to-peer chat over IPv6 only.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
root 245446d540 message processing пре 5 година
bin config read/write fully working. пре 5 година
inc message processing пре 5 година
lib reorganised files пре 5 година
src message processing пре 5 година
Makefile reorganised files пре 5 година
README.md added note пре 5 година

README.md

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, public key and icon.
  • 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 is used.
  • The network does not allow store-and-forward of messages. If the friend is offline, messages cannot be send and the client has to store the message until the friend is available. For mobile clients, notifications might be integrated to wakup the client (no clue how? anyone?)
  • The network allows users to find other users.
  • Chat groups require to send the message to all the clients.
  • Each client will randomly add a certain amount of time to its own metric to avoid disclosing its identifiy to any incoming connection.
  • … ?

notes

  • use TAI64 for timestamps

NEW PROTOCOL TO BE DOCUMENTED!!!

Protocol

TIMESTAMP PROOF TOKEN TYPE key=value pairs ...

TIMESTAMP

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

PROOF

The PROOF token proves the origin and signs the message. It is composed of the hash of the client concatenated with a hash of the message without the PROOF and with a metric value of 0 (if present).

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.
  • key: a symetric key encrypted with the target rsa key.
  • icon: base64 encoded png.
  • hash: SHA256 of the RSA public key.
  • chatid: a uuid defining the chat group.
  • msgid: a uuid defining a message for a specific chatid.
  • message: a base64 encoded, encrypted with the target RSA public key message.
  • target_hash: same as hash but specifically of the target
  • neighbour: ipaddress,port
  • metric: a 32 bits unsigned integer representing the sum of all latencies between the client and the announcing client.

begin and end of session

HELLO {version}
BYE

path anouncement and withdrawal

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

KEEPALIVE

<TIMESTAMP> <PROOF> <MSGHASH> <KEY> KEEPALIVE QUERY
<TIMESTAMP> <PROOF> <MSGHASH> <KEY> KEEPALIVE RESPONSE

FRIENDS & MESSAGES

<TIMESTAMP> <PROOF> <MSGHASH> <KEY> FRIEND REQUEST {target_hash, key}
<TIMESTAMP> <PROOF> <MSGHASH> <KEY> FRIEND CONFIRM {target_hash, key}
<TIMESTAMP> <PROOF> <MSGHASH> <KEY> MESSAGE SEND {target_hash, chatid, msgid, message}
<TIMESTAMP> <PROOF> <MSGHASH> <KEY> MESSAGE RECV {target_hash, chatid, msgid}
<TIMESTAMP> <PROOF> <MSGHASH> <KEY> MESSAGE READ {target_hash, chatid, msgid}

NEIGHBOURS

<TIMESTAMP> <PROOF> <MSGHASH> <KEY> NEIGHBORS REQUEST # request the neighbours of your neighbour
<TIMESTAMP> <PROOF> <MSGHASH> <KEY> NEIGHBORS RESPONSE {neighbour,..} # neighbours list, multiple time the same key