update links

This commit is contained in:
Oskar Thoren 2019-07-19 19:26:03 +08:00
parent 97ddb3872f
commit 410b526ea0
No known key found for this signature in database
GPG Key ID: B2ECCFD3BC2EF77E
1 changed files with 1 additions and 1 deletions

View File

@ -56,7 +56,7 @@ For requirements or design goals for a solution, here's what we came up with.
## MVDS - a minimium viable version
The first minimum viable version is in an alpha stage, and it has a [specification](https://github.com/status-im/bigbrother-specs/blob/master/data_sync/mvds.md), [implementation](https://github.com/status-im/mvds) and we have deployed it in a [console client](https://github.com/status-im/status-console-client) for end to end functionality. It's heavily inspired by [Bramble Sync Protocol](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md).
The first minimum viable version is in an alpha stage, and it has a [specification](https://github.com/vacp2p/specs/blob/master/mvds.md), [implementation](https://github.com/vacp2p/mvds) and we have deployed it in a [console client](https://github.com/status-im/status-console-client) for end to end functionality. It's heavily inspired by [Bramble Sync Protocol](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md).
The spec is fairly minimal. You have nodes that exchange records over some secure transport. These records are of different types, such as `OFFER`, `MESSAGE`, `REQUEST`, and `ACK`. A peer keep tracks of the state of message for each node it is interacting with. There's also logic for message retransmission with exponential delay. The positive ACK and retransmission model is quite similar to how TCP is designed.