Proof of Concept for Kibitz screen

JohnnieDarko · April 3, 2026, 11:42pm

Hey all,

I’ve been tinkering with a Kibitz environment for OGS and I’d like to share a proof of concept.

The problem I want to solve is: OGS has chat channels and game chat, but not really a place to spectate games together.

If you use the Chat Channels, then you can’t watch games. When you click one of the game previews in the channel, you go away from that chat channel to that Game page.
That game also has chat, but that chat is tied to that game.
So when the game is finished, you need to coordinate together to which game to go to next.

I think it could be a lot of fun to have a third type of chat room, a Kibitz room, where you can discuss an ongoing game, share and discuss variations and when it’s done, the users propose the next game to view and discuss. While keeping the current chats and requiring no moving across different screens.

For this I made a prototype.

The Concept

It starts with a menu entry: Community > Kibitz

This brings you to the new Kibitz view, with from left to right:

Rooms
Main board
Secondary board
Room Chat

Main board
The main board is the game the room is currently watching, and it is shared with everyone in this Kibitz room

Secondary board
The secondary board has two functions:

preview another game privately
view and create variations, shared through chat

So the room stays together on one main board, while individual users can still branch off temporarily without disrupting the shared view.
Planned is also a list of created variations, so users can quickly find older variations, as the chat stream moves on.

below: second screen showing a preview of a different game

Proposing a new game to watch.
If a main game is over, or too boring, then you can preview other games. For now this is implemented with the Top 19x19 and the Top 9x9 buttons below main board. If you click one of those it shows up on the Secondary board. (The idea is to have a more elaborate game preview system).

When previewing a game, you can propose a board change with the button below the Secondary board.

When that is pressed:
a big banner appear for all players with the voting buttons “Change board” or “Keep current”. This is similar to how voting on maps work in multiplayer games.

below: a vote in progress (blue banner)

If a majority voted Change board then the new board becomes the new focus.

On the right you see that the chat persists. As a result, the same group of people can keep discussing games, see variations, propose new games to watch, etc.

below: Main game changed, chat persists on the right

Result

I think this approach gives a lot of flexibility for different types of Kibitzing; a hangout place for regulars to chill, a place for tournament owners to put games in the spotlight, a place for teaching games (on the main board).

What you see in the screenshots is mostly functional. It is working on my local copy of the OGS frontend, connected to the OGS backend. That said, this is still a proof of concept, not a finished proposal.

Some parts already work well as a recombination of existing OGS functionality (watching boards, creating variations, having chat channels).
Some other parts need backend support to do properly (voting, room ownership functionality).

I have given a lot of thought about how workflows should be; for example what room owners should be able to do, what happens when you were watching a variation but the main game changes. I worked those things out, I can post the design docs if anyones interested.

Feedback

What I’d like to know from you is:

Does this model of a persisting chatroom with changing games fit the Kibitz need?
Does the split between shared Main Board and private Secondary Board make sense?
Are there use cases for which this approach wouldn’t work?

Next steps

The main thing I wanted to test first is the idea. I think this could work and be cool but obviously this isn’t an easy thing to make.

So the idea is:

first work this out further as a frontend concept
then identify what backend support would actually be needed
and turn that into a concrete requirement list for the dev side

So at this stage I’m mainly interested in whether the overall idea feels worthwhile and the feedback questions above.

shamisen · April 4, 2026, 12:51am

Can this problem not be solved by embedding spectator view as a tab similar to existing chat channels? Like so:

Coordination can then be done organically in the English or a new Kibitz chat channel, without a need for new backend code. Importantly, each game’s kibitz would be stored in each game, which is how it currently works. This means there’s no need for private secondary boards. Most or all of your UI can be embedded in the existing chat page, so your work wouldn’t be wasted.

I like the blue banner voting feature. There’s potential in that, but maybe in a second update. This design can be split into two updates, first one simply embeds spectate page into the chat page, and the second one adds all the fun interactive kibitz features:

voting
variations – There can be a list sorted by upvotes or number of backlinks
betting – using a virtual “Kibitz points” currency, like Twitch channel points

These are a lot more work and require more testing than one update can handle. Especially a new UI for listing and sharing variations, that’s something that would be useful for reviewing games too – in fact it was a feature I was planning to develop for my Go website for reviewing and teaching.

JohnnieDarko · April 4, 2026, 8:58am

Yes, that was one of the first approaches I looked at.

My goal is to work out the best Kibitz experience, and then see what is necessary to get it implemented. I think once you add the features that turn Kibitz into a full-featured mode, it becomes more difficult to try to fit into the existing Chat page than to start fresh.

If that’s a fundamental requirement/wish, Kibitz chat could also be saved to the Game records of current game in focus on the Main Board. I’ve noted this as a requested feature.

The Secondary Board is there as an improvement to the experience, so you can stay with the live game, while exploring variations. It’s the same as having two tabs open of the same game:

one showing the live game at all times
the other where you browse the variation.

Most of what you see in the screenshots already works with the current backend, its just recombining what already exists. The new Kibitz specific features would need backend support:

the voting system - make sure all users see the voting happening and that all players move to the same next game.
the room features - For example an AGA/EGF tournament host would like to be able pin a game and disable the ability to vote for other games. This could either be new backend features or tweaks to the chat room backend. That’s fully up to Anoek to decide what the best way would be (assuming this idea makes it at all of course).

Here’s the technical summary of which existing backend and frontend features are currently in use.

Backend-backed features

Chat channels via chat_manager.ts
Channel join/part/presence through the existing websocket chat system
Live game discovery through socket.send(“gamelist/query”, …) in KibitzController.ts
Full game metadata through get(“games/”) in KibitzRoomStage.tsx

Frontend OGS pieces being reused

Routing and page shell through routes.tsx
Main nav entry in NavBar.tsx
OmniSearch entry in OmniSearch.tsx
Board rendering through MiniGoban.tsx
Chat line rendering through ChatLine.tsx
Chat input through TabCompleteInput.tsx
Presence/user rendering through Player in the Kibitz presence panel
Translation/localization through pgettext and interpolate

OGS infrastructure in use

Websocket connection through sockets.ts
Request helper through requests.ts
Shared app data/config via data.ts

Not backend-backed yet

Kibitz rooms themselves
current shared board selection
proposals/voting
secondary preview state
variation state and ranking

Those last pieces still live only in the frontend KibitzController.

Agreed. For Kibitz to work, users need to quickly see where the activity is: which chats and variations are currently active. My current idea is to sort the variation list by how many people currently have that variation open in their Secondary Board.

For archived games, a thumbs-up system would probably make more sense, so I’ve noted that separately as a feature request.

If you have ideas for features that would make for a better Kibitzing experience, I’d love to hear them.

shamisen · April 4, 2026, 3:58pm

I’m open-minded to the idea of separating kibitz chat from game records too. I can imagine if a horde of 50+ chatters are invading a game, it’d pollute the resulting SGF file beyond readability.

IMO, it would be a welcome small update to integrate spectator view into the existing Chat page first, and then transition to a full Kibitz page in a second update.

Tournament host features would be nice. This could come with the ability for hosts and mods to post tournament/big game announcements on a home page widget as well as the kibitz room.

Alright, if you’re willing to make this happen I’ll do my part too (frontend coding + design). We can make online Go great again (MOGGA). I don’t fully understand 100% of the proposals yet, especially the secondary board, but I see the vision.

My only concern is I end up getting addicted to this hobby project. I don’t even want a full-time paid position at OGS even if Go becomes 10x more popular meaning it can pay well, I have my own full-time project to make as big as online Go. I guess I’ll contribute until my own site takes off and I have 1000s of angry customers to deal with. I’m having fun so far.

marinakai · April 11, 2026, 12:58am

I think this is a really neat idea! This would definitely get me to spend more time watching in-progress live games.

My main feedback at this point is I’m not completely sold on the secondary board as presented. I appreciate the design impulse — being able to noodle around on your own while still seeing the main game playing out makes a lot of sense — but I’m not sure there’s enough horizontal space to make it work. Even in your preview screenshot, where the aspect ratio is wider than most laptop screens and the secondary board is only 9x9, I think I’d still want to see more screen real estate dedicated to the main board, especially for a 19x19 game.

My gut instinct for an alternate design would be to just show a single board by default. Like the ‘normal’ OGS game UI for a completed game, if you try to place a new stone or use the scrubber, you enter into analyze mode. At that time, a secondary board screen pops up that shows the live game in a much smaller display than the main board. The mental model would be like “picture-in-picture” mode on a TV — you’re focused on the variation, but in the corner of your eye you can keep an eye on the main game until you’re ready to go back to it.

In my mind, this PIP board would possibly be smaller than the secondary board in your mockup, and in an ideal world would behave like the browser-level picture-in-picture video API (i.e. it floats on top of the main page, can be dragged to any location, and can be resized to some extent), but I think the big-picture design brief is “possibly smaller than the existing design, and disappears when not in use”.

For previewing other games, you could then also imagine extending it so that your current game remains on the ‘main’ board but the preview is shown in the PIP display, mimicking your current secondary screen. But I’m also not completely sure previewing other games is an important use case to support. If you’re deciding whether another game is worth jumping to, you probably aren’t paying close attention to your current game, so it might be fine to just say “navigate to another game, and if you don’t want to watch it you can navigate back”.

This would then also scale down better for mobile, you’d just get rid of the ‘PIP view’ entirely, and by treating analyze mode as the ‘main’ board you can still support it.

To pull back from my specific design suggestion, I think that is hinting at a few ideas:

I want the main board to be bigger.
If I’m not using the secondary board, I want to be able to get rid of it to give the main board more space
If I’m looking at a variation board, it is my main focus, and the live game should conceptually be the ‘secondary’ screen instead of the main one

JohnnieDarko · April 11, 2026, 11:23am

Thank you for your considerate feedback. Right off the bat, I agree with most of you said, and the current version already has 75% implemented.

Mainly:

Default mode is a single goban, using maximal screen estate.
The preview goban is optional, hidden by default.
Editing mode gives a much bigger goban. Not yet ‘as big as the main goban with the main goban being small PIP’’ . The idea to make the editing goban bigger than the live game (and have the live game PIP) had crossed my mind too, and your feedback confirms that it makes sense to make that.

Think of the use of the preview board more like “The room (my friends and I) are finished watching or reviewing this game, which game shall we watch next?”.

It can also be used in the context of “this current game is boring, let’s watch something else”, but that’s not the main use. It’s meant to be a community-driven method to keep the party going.

As a small note: the aspect ratio of the screenshot is standard 16:10, but perhaps the screenshots made it look wider than that because the browser tabs and OS taskbar were cut off.

Thanks for the feedback, right on the mark imo, and development is going in this direction.