Protocol version 2

[igor-sirotin]

We wanted to write a working app first. Gather all weak points, list State properties, and then come up with protocol V2.
The ideas below were in our minds when implementing V1, but we intentionally postponed them.

There're 2 main problems with protocol V1.

1. Disable dealer to rig the vote

Problem

In current protocol there's no way (except visual check) to check the validity of other player's vote.
The dealer is able to write any votes by any players and distribute it to other players.

Proposed solution

1. Each player generate a pair of public/private keys.
2. Player's public key becomes their ID
3. Each vote is signed with player's private key
4. Other players are able to check the vote signature knowing other player's public key.

Same applies to online/offline messages. And basically any messages sent by player.

2. Reduce network load and decrease "dealer-centralization"

Problem

We're harassing waku network by 2 simplifications:

1. All messages are only processed by dealer, who then distributes a new game State message to everyone.
2. We use json instead of protobuf

Proposed solution 1

1. Player A encrypt their vote with dealer's public key.
2. Other players "hear" in the network that Player A voted, but they can't decrypt the value.
3. Dealer receives the vote and decrypt it.
4. To reveal votes, dealer distribute decrypted votes to all players

Not sure, maybe keep the symmetric encryption on top of assymetric encryption.

Proposed solution 2

1. Dealer generate a keypair for each issue
2. Dealer shares the public key of each issue
3. Players encrypt their votes with the issue public key
4. Other players "hear" votes in the network, but they can't decrypt values
5. To reveal votes, dealer shares issue's private key, so players are finally able to decrypt votes values.

Not sure, maybe keep the symmetric encryption on top of assymetric encryption.

3. Split State message

Problem

Currently we send fully State message on any change of it's properties:

2-story-points-cli/pkg/protocol/state.go

Lines 9 to 16 in ef759ff

	type State struct {
	Players PlayersList `json:"players"`
	Issues IssuesList `json:"issues"`
	ActiveIssue IssueID `json:"activeIssue"`
	VotesRevealed bool `json:"votesRevealed"`
	Timestamp int64 `json:"-"` // TODO: Fix conflict with Message.Timestamp. Change type to time.Time.
	Deck Deck `json:"-"`
	}

I.e. any new player, issue or even a single vote, leads to full State redistribution.

This is obviously not needed, only updated parts should be resent.

Proposed solution

1. Introduce VoteID.
   This should be some form of RoomID, that will keep the encryption key as secret.

2. Introduce IssuesDescirption, PlayersList and Deck messages
   Below is the idea with example for IssuesList, but the logic applies for all of the new proposed messages.

   type IssuesDescirptionMessage type {
       VoteID string
       Issues IssuesList
   }

   It should be distributed any time:

   • Issues are added/removed
   • Issue description is changed
   • New player joins (maybe, if we don't trust store nodes)

   This messages should not be part of global State message.
   This message probably shouldn't contain vote. Though not sure how to retrieve history then. 🤔

3. Introduce a message for Clause 2 (issue private key / revealed votes)

   I don't like to store revealed votes separately from the issue list. But maybe it's not that bad?

[igor-sirotin]

By the way, maybe it's better to soft-delete issues to prevent potential collisions.