Commit 0dc97a0c authored by Éloïs's avatar Éloïs

ref negociation secret flags

parent 404ff964
......@@ -32,7 +32,7 @@ We are also taking advantage of these changes to address minor issues :
* [Useful non-primitive types](#useful-non-primitive-types)
* [Binary messages format](#binary-messages-format)
* [Endpoints v1](#endpoints-1)
* [Endpoints v2](#endpoints-v2)
* [Endpoint binary format](#endpoint-binary-format)
* [Endpoint utf8 format](#endpoint-utf8-format)
* [Peer card](#peer-card)
......@@ -291,9 +291,9 @@ The signature is generated from the byte vector of the entire message (signature
| PENDING_REVOCATIONS | 14 | yes | no |
| PENDING_TXS | 15 | yes | no |
## Endpoints v1
## Endpoints v2
WS2Pv1 used endpoints version v0. So, in WS2Pv2 we improve to endpoints version v1.
WS2Pv1 used endpoints version v1. So, in WS2Pv2 we improve to endpoints version v2.
### Endpoint binary format
......@@ -369,11 +369,11 @@ General utf8 endpoint format :
VERSION := version number prefixed by `V` (example : `V1`)
NF := NETWORK_FEATURE
AF := API_FEATURES in hexadecimal
AF := API_FEATURES in hexadecimal prefixed by `0x` (example : `0x01`)
Example:
WS2P V2 TLS 7 443 g1.durs.info ws2p
WS2P V2 TLS 0x7 443 g1.durs.info ws2p
Same endpoint in binary format :
......@@ -612,6 +612,7 @@ chunkstamp := Blockstamp of the last block of the chunk. This field is present o
| 0000_0001 | SYNC |
| 0000_0010 | ASK_SYNC_CHUNK |
| 0000_0100 | RES_SYNC_CHUNK |
| 0000_1000 | CLIENT |
SYNC := Boolean indicating whether the connection corresponds to a synchronization request or not. In case of a synchronization request, the connection will necessarily be accepted if it's possible* but temporary. Whereas in the normal case the connection may or may not be accepted according to classic ws2p rules, but it will be permanent.
......@@ -621,6 +622,8 @@ ASK_SYNC_CHUNK := So that the synchronization is not too slow, the nodes to whic
RES_SYNC_CHUNK := A WS2P Public node that asks to synchronize sends its PeerCard to the network, which can then contact it spontaneously to send chunk, the node in synchronization will accept in priority this type of connections.
CLIENT := A third-party program wants to connect in client mode.
### ACK message
| data name | size in bytes | data type |
......@@ -633,30 +636,31 @@ The message is already signed at the container level, so there is no need to rep
### SECRET FLAGS message
| data name | size in bytes | data type |
|:-------------:|---------------|------------------|
| flags_size | 1 | u8 |
| flags | flags_size | WS2PSecretFlags |
| member_proof | ? | Opt(MembreProof) |
MembreProof type :
| data name | size in bytes | data type |
|:-------------:|---------------|-----------------|
| flags_size | 1 | u8 |
| flags | flags_size | WS2PSecretFlags |
| member_pubkey | ? | Opt(PubkeyBox) |
| member_proof | ? | Opt(SigBox) |
| pubkey | ? | PubkeyBox |
| sig | ? | SigBox |
If its valued, the `member_proof` field must contain a signature of the challenge* send by other node in their CONNECT message.
_*It's the remote challenge for the signatory, and the local challenge for the verifier._
#### WS2PSecretFlags type definition
| bit | flag |
|:---------:|-----------------|
| 0000_0001 | LOW_FLOW_DEMAND |
| 0000_0010 | MEMBER_PUBKEY |
| 0000_0100 | MEMBER_PROOF |
LOW_FLOW_DEMAND := The sender node of this message indicates that it's behind a low speed connection and therefore care must be taken to transmit low volumes of data to it. All the code will do is to be careful to send only essential information and not already sent, which requires caching and pre-processing, that's why we don't do it for normal connections.
MEMBER_PUBKEY: Indicates whether or not the member_pubkey field is present in the message.
MEMBER_PROOF := Indicates that the message contains proof that the sender node is a member. If this boolean is false, then the member_proof field must not be present.
If this boolean is true, the "member_proof" must contain a signature of the challenge* send by other node in their CONNECT message.
_*It's the remote challenge for the signatory, and the local challenge for the verifier._
### OK message
In most cases, the OK message is empty (=3 zero-bytes), it simply indicates that the remote node accepts the connection establishment. If the local node has also sent an OK message, then it considers the connection as fully established.
......@@ -905,7 +909,7 @@ _/!\ This description is approximate, it allows you to quickly understand the fo
Example :
3:g1:0:0:0:0:0:7iMV3b6j2hSj5WtrfchfvxivS9swN3opDgxudeHq64fb:50-000005B1CEB4EC5245EF7E33101A330A1C9A358EC45A25FC13F78BB58C9E7370:durs:0.1.0-a0.1
3:g1:0:0:0:0:0:7iMV3b6j2hSj5WtrfchfvxivS9swN3opDgxudeHq64fb:50-000005B1CEB4EC5245EF7E33101A330A1C9A358EC45A25FC13F78BB58C9E7370:durs:0.2.0-a
vwlxpkCbv83qYSiClYA/GD35hs0AsZBnqv7uoE8hqlarT2c6jVRKhjp8JBqmRI7Se4IDwC2owk0mF4CglvyACQ==
2
......@@ -973,7 +977,7 @@ This human-readable format will be used by all APIs that wish to provide heads i
Example :
{
"content": "3:g1:0:0:0:0:0:7iMV3b6j2hSj5WtrfchfvxivS9swN3opDgxudeHq64fb:50-000005B1CEB4EC5245EF7E33101A330A1C9A358EC45A25FC13F78BB58C9E7370:durs:0.1.0-a0.1",
"content": "3:g1:0:0:0:0:0:7iMV3b6j2hSj5WtrfchfvxivS9swN3opDgxudeHq64fb:50-000005B1CEB4EC5245EF7E33101A330A1C9A358EC45A25FC13F78BB58C9E7370:durs:0.2.0-a",
"signature": "vwlxpkCbv83qYSiClYA/GD35hs0AsZBnqv7uoE8hqlarT2c6jVRKhjp8JBqmRI7Se4IDwC2owk0mF4CglvyACQ==",
"step": 2,
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment