-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for acknowledgments #130
Conversation
I'm 👍 for the idea of this PR (haven't done code review). (An aside on why I'm interested in this.) I'm personally still debating whether multiwriter is the right solution for handling multiple devices, or if we should only be using multiwriter for collaboration between multiple people. If we had a 'safe commit' protocol, we could have users reuse the same publishingkeys between devices, and then require checkins with managernodes before publishing updates to a log. This has both upsides and downsides. Upsides:
Downsides:
I'm not convinced of my argument but I wanted to record it. |
Noting conversation with @mafintosh here:
|
Thanks @emilbayes. See also: holepunchto/hypercore#130
@emilbayes what is missing here? |
@martinheidegger this looks pretty stale, but it is also lacking tests |
landed in latest |
I want to make a scheme where I can be reasonably certain that n-peers have received a block before I communicate any confidence that a block is safely "committed". This PR goes with the new flag in the protocol handshake and asks peers to acknowledge any blocks they receive. Of course this does not make any guarantees about byzantine peers, so you should only trust the ack if you trust the peer.
Still needs more tests.