six78/2-story-points-cli

Decentralized poker planning in terminal

Lock, Stock and Two Story Points

Decentralized. Poker planning. In terminal.

Description

• This is a CLI app for poker planning
• We use Waku for decantralized players communication
• Messages are end-to-end encrypted, the key is shared elsewhere as part of the room id

Build it your own

git clone https://github.io/six78/2-story-points-cli
cd 2-story-points
make build
./2sp

Or just run the code with a shadow build:

make run

Now share your room id with friends and start estimating your issues!

Protocol

Description of the protocol can be found here.

2-story-points-cli's Issues

Implement standard project layout

https://github.com/golang-standards/project-layout

Embed HintView into room view

Remove `roomViewState`

roomViewState seems redundant. We could just use Focused state of view components now.

Extract spinner component with style

Though it's just 2 lines, it's quite a duplication already. We should extract this to a component.

2-story-points-cli/view/components/issuesview/issues_view.go

Lines 35 to 36 in 6fca0f9

	s := spinner.New()
	s.Spinner = spinner.MiniDot

2-story-points-cli/view/components/issueview/issue_view.go

Lines 52 to 53 in 6fca0f9

	s := spinner.New()
	s.Spinner = spinner.MiniDot

2-story-points-cli/view/components/voteview/voteview.go

Lines 43 to 44 in 6fca0f9

	s := spinner.New()
	s.Spinner = spinner.MiniDot

2-story-points-cli/view/model.go

Lines 104 to 105 in 6fca0f9

	s := spinner.New()
	s.Spinner = spinner.MiniDot

Implement a new `HintView` component

Approximate design:

  ╭───────┬─────┬─────────┬────────┬─────────╮                                       
  │ Alice │ Bob │ Charlie │ Didukh │ Sirotin │  Recommended: 3                          
  ├───────┼─────┼─────────┼────────┼─────────┤  Acceptable:  x - too big votes variety
  │   1   │  3  │    8    │   13   │    3    │  What to do:  Listen to Alice and Didukh arguments                                        
  ╰───────┴─────┴─────────┴────────┴─────────╯                                                                  

Require at least 50% of votes for Hint.Acceptable

2 things to check:

Absence of vote

Potential difficulty: what if the user went offline? Should we track only online users?
Or should we open a separate issue to allow dealer to kick members? And then it's dealer responsibility to keep the players list valid.

Vote ?

Potential difficulty: How to consider this value? Now it's just another string value in the deck.
Maybe always add a question mark to deck?
Maybe automatically treat question mark as special value? Property of deck or game? Maybe -deck.unsure=false?

Render GitHub issue author and assignee

Calculate measurements and generate a hint for given vote result

Ignore `?` for hints

Username is blinking

The username is shown in grey color when the user is offline. But there's either some bug in logic (most probably), or some Online messages are not delivered (many times from all users).

A few things should be done:

1. Make sure any message (excludingOffline) from a user marks the user as online.
2. Review the user online/offline logic.
3. Maybe increase the user timeout?

There's only me working this so far, so I didn't bother with recording a video of the bug. I know how it looks like.

Support light-background terminals

No peers on `shards.test` fleet

Refactor interfaces

Description

For proper mocking and testing we need to separate packages from each other with interfaces. In particular, this is blocking me from cover Model (quite a big class) with tests.
Now it's only done for Transport:

2-story-points-cli/game/providers.go

Lines 5 to 10 in 6fca0f9

	type Transport interface {
	SubscribeToMessages(room *protocol.Room) (*MessagesSubscription, error)
	PublishUnencryptedMessage(room *protocol.Room, payload []byte) error
	PublishPublicMessage(room *protocol.Room, payload []byte) error
	PublishPrivateMessage(room *protocol.Room, payload []byte) error
	}

Implementation

I'm leaning towards chain of responsibility pattern.

Some thoughts:

• NewGame(transport *Transport, storage *Storage)
• initialModel(game *Game, transport *Transport)
• storage = nil when config.Anonymous == true
• type App is not needed anymore. This was kind of an orchestrator before.
  Create everything needed in main and pass to Model. There we subscribe to game and transport events.

Improve labels color readability

This pink color doesn't look good:

Here how it looks on GitHub:

status-im/status-desktop#15008

Votes are saved to storage as `nil` in revealed state

1. Igor (dealer) and Alice voted
2. Dealer restarted the app and joined the same room (state restored from storage)
3. Bob and Charlie voted
4. Dealer revealed votes:

Update to Go 1.21

go-waku now supports Go 1.21:

• waku-org/go-waku#1091

Implement hint descriptions

• Discuss and re-vote
• Debate between players voted farthest from the median (try to implement advice with particular player mentions)
• ... Something more?

Fixed-height UI

When switching between room and issues views, shortcuts section should remain in same position.
Issues list will require scrolling.

[EPIC] Result recommendations

When votes are revealed, dealer (or everyone) should be provided with recommendations on final issue estimation.

As minimum, it should include a median value of all votes.
But would be nice to make it smarter, e.g. detect a big diversity in votes and suggest revoting.

• #51
• #53
• #57
• #54
• #55
• #65

Protocol version 2

The idea of version 2 briefly:

IDEA 1.

Encrypt votes with dealer's public key.
Other players can distingush that you voted, but can't decrypt the value.
When revealing, dealer publishes all votes openly.

IDEA 2.

Generate a keypair for each issue.
Public key is the issue id.
Votes are encrypted with the issue's public key.
When revealing, dealer publishes the private key for the issue.

---

In both cases votes should be signed with player’s private key. This way we ensure that they’re not forged.

Automatically quit on fatal error

Implement app events

Current we subscribe to app events with WaitForGameState and WaitForConnectionStatus.
This leads to code duplication here:

2-story-points-cli/view/commands/commands.go

Lines 71 to 82 in 1c657bf

	func WaitForGameState(app *app.App) tea.Cmd {
	return func() tea.Msg {
	state, more, err := app.WaitForGameState()
	if err != nil {
	return messages.FatalErrorMessage{Err: err}
	}
	if !more {
	return nil
	}
	return messages.GameStateMessage{State: state}
	}
	}

2-story-points-cli/view/commands/commands.go

Lines 97 to 110 in 1c657bf

	func WaitForConnectionStatus(app *app.App) tea.Cmd {
	return func() tea.Msg {
	status, more, err := app.WaitForConnectionStatus()
	if err != nil {
	return messages.FatalErrorMessage{Err: err}
	}
	if !more {
	return nil
	}
	return messages.ConnectionStatus{
	Status: status,
	}
	}
	}

As well as the subscriptions in the App.

Instead, we should implement an event-based system from the App.

Add version command

Automatically reveal votes when all players voted

Give a timeout of 2-3 seconds

the app crashes on the first start

I've installed the release version
then I ran ./2sp from the command line and got this error:

 ☠️ fatal error: failed to create waku node
panic: runtime error: invalid memory address or nil pointer dereferencewaku-pp-2024-05-29T15-55-30Z.log
[signal SIGSEGV: segmentation violation code=0x2 addr=0x58 pc=0x100dbfac0]

goroutine 832 [running]:
2sp/game.(*Game).LeaveRoom(0x0)
	/Users/runner/work/2-story-points-cli/2-story-points-cli/game/game.go:58 +0x20
2sp/view/commands.QuitApp.func1()
	/Users/runner/work/2-story-points-cli/2-story-points-cli/view/commands/commands.go:148 +0x24
github.com/charmbracelet/bubbletea.(*Program).handleCommands.func1.1()
	/Users/runner/go/pkg/mod/github.com/charmbracelet/[email protected]/tea.go:294 +0x30
created by github.com/charmbracelet/bubbletea.(*Program).handleCommands.func1
	/Users/runner/go/pkg/mod/github.com/charmbracelet/[email protected]/tea.go:293 +0x11c

The second time it worked perfectly.

Crash when clicking `Enter` in inappropriate time

Implement a dealer connection status

We don't have any information if we stopped receiving state from the dealer.

Possible ways:

• make a timeout for State (then dealer should send it periodically)
• process playerOnline state by all players. Then dealer's playerOnline state will also work (now it just doesn't).

Probably something similar to ● Waku: N peer(s) next to the Room.
Or maybe just show when the last state was received.