소스 검색

Update 'README.md'

master
Pascal Gloor 5 년 전
부모
커밋
e1bb7e91b8
1개의 변경된 파일25개의 추가작업 그리고 15개의 파일을 삭제
  1. 25
    15
      README.md

+ 25
- 15
README.md 파일 보기

@@ -12,19 +12,19 @@ libchat6 is a complete library that handles an IPv6 only, peer-to-peer, end-to-e
* 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.
* 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 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?
* 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.
* ... ?

## Protocol

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

### TIMESTAMP
@@ -43,29 +43,39 @@ NOTE: All encrypted data is represented as base64.
* 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.
* 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.

### path anouncement and withdrawal

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

### keepalive
### KEEPALIVE

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

### messages
### MESSAGE

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

### NEIGHBOURS

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

Loading…
취소
저장