Show More
@@ -17,19 +17,21 b' Protocol version is the version of the s' | |||
|
17 | 17 | of data models. If at least one of them is different, the sync cannot be |
|
18 | 18 | performed. |
|
19 | 19 | |
|
20 | The node signs the data with its key. The receiving node saves the key at the | |
|
20 | The node signs the data with its keys. The receiving node saves the key at the | |
|
21 | 21 | first sync and checks it every time. If the key has changed, the info won't be |
|
22 | saved from the node (or the node id must be changed). | |
|
22 | saved from the node (or the node id must be changed). A model can be signed | |
|
23 | with several keys but at least one of them must be the same as in the global | |
|
24 | ID to verify the sender. | |
|
23 | 25 | |
|
24 | 26 | Each node can have several keys. Nodes can have shared keys to serve as a pool |
|
25 | 27 | (several nodes with the same key). |
|
26 | 28 | |
|
27 |
Each post has an ID in the unique format: |
|
|
29 | Each post has an ID in the unique format: [key-type][key][local-id] | |
|
28 | 30 | |
|
29 | All requests pass a request type, protocol and model versions and a list of | |
|
31 | All requests pass a request type, protocol and model versions, and a list of | |
|
30 | 32 | optional arguments used for filtering. |
|
31 | 33 | |
|
32 |
Each |
|
|
34 | Each request has its own version. Version consists of 2 numbers: first is | |
|
33 | 35 | incompatible version (1.3 and 2.0 are not compatible and must not be in sync) |
|
34 | 36 | and the second one is minor and compatible (for example, new optional field |
|
35 | 37 | is added which will be igroned by those who don't support it yet). |
General Comments 0
You need to be logged in to leave comments.
Login now