add spec draft to repo
This commit is contained in:
parent
2a0350a564
commit
63de78aaeb
77
solanaceae/ngc_hs2/spec_ngc_hs2.md
Normal file
77
solanaceae/ngc_hs2/spec_ngc_hs2.md
Normal file
@ -0,0 +1,77 @@
|
||||
# [NGC] Group-History-Sync (v2) [PoC] [Draft]
|
||||
|
||||
Simple group history sync that uses `peer public key` + `message_id` + `timestamp` (`ppk+mid+ts`) to, mostly, uniquely identify messages and deliver them.
|
||||
|
||||
## Requirements
|
||||
|
||||
TODO
|
||||
|
||||
### File transfers
|
||||
|
||||
For sending packs of messages. A single message can be larger than a single custom packet, so this is a must-have.
|
||||
|
||||
## Procedure
|
||||
|
||||
Peer A can request `ppk+mid+ts` list for a given time range from peer B.
|
||||
|
||||
Peer B then sends a filetransfer (with special file type) of list of `ppk+mid+ts`.
|
||||
Optionally compressed. (Delta-coding / zstd)
|
||||
|
||||
Peer A keeps doing that until the desired time span is covered.
|
||||
|
||||
After that or simultaniously, Peer A requests messages from peer B, either indivitually, or packed? in ranges?.
|
||||
Optionally compressed.
|
||||
|
||||
During all that, peer B usually does the same thing to peer A.
|
||||
|
||||
## Traffic savings
|
||||
|
||||
It is recomended to remember if a range has been requested and answered from a given peer, to reduce traffic.
|
||||
|
||||
While compression is optional, it is recommended.
|
||||
|
||||
## Message uniqueness
|
||||
|
||||
This protocol relies on the randomness of `message_id` and the clocks to be more or less synchronized.
|
||||
|
||||
However, `message_id` can be manipulated freely by any peer, this can make messages appear as duplicates.
|
||||
|
||||
This can be used here, if you don't wish your messages to be syncronized (to an extent).
|
||||
|
||||
## Security
|
||||
|
||||
Only sync publicly sent/recieved messages.
|
||||
|
||||
Only allow sync or extended time ranges from peers you trust (enough).
|
||||
|
||||
The default shall be to not offer any messages.
|
||||
|
||||
Indirect messages shall be low in credibility, while direct synced (by author), with mid credibility.
|
||||
|
||||
Either only high or mid credibility shall be sent.
|
||||
|
||||
|
||||
Manual exceptions to all can be made at the users discretion, eg for other self owned devices.
|
||||
|
||||
## File transfer requests
|
||||
|
||||
TODO: is reusing the ft request api a good idea for this?
|
||||
|
||||
| fttype | name | content (ft id) |
|
||||
|------|------|---------------------|
|
||||
| 0x01 | time range | - ts start </br> - ts end </br> - supported compression? |
|
||||
| | TODO: id range based request? | |
|
||||
| 0x01 | single message | - ppk </br> - mid </br> - ts |
|
||||
|
||||
## File transfers
|
||||
|
||||
| fttype | name | content |
|
||||
|--------|------|---------------------|
|
||||
| 0x01 | time range | - feature bitset (1byte? different compressions?) </br> - ts start </br> - ts end </br> - list size </br> \\+ entry `ppk` </br> \\+ entry `mid` </br> \\+ entry `ts` |
|
||||
| 0x01 | single message | - message type (text/textaction/file) </br> - text if text or action, file type and file id if file |
|
||||
|
||||
## TODO
|
||||
|
||||
- [ ] figure out a pro-active approach (instead of waiting for a range request)
|
||||
- [ ] compression in the ft layer? (would make it reusable) hint/autodetect?
|
||||
|
Loading…
Reference in New Issue
Block a user