It is my typo. I mean retransmission. Pages will load slower.
Why chat messages? There is no messages here (in UI). Only counters. Every time I open a new tab a got this junk. I hope it is not a reason for things such OGS Connection issues for BT users - and maybe others (update)
Please check out the functionality of the symbols at the top right.
The messages you are seeing are driving those, at the very least.
You joined the channels because you are getting notifications for them.
Maybe they can be trimmed, maybe the benefit of delivering all the info at once instead of notification-then-data is worth it: this way the server does not need to know whether you are on a page that is rendering the message or not - information which would be easy to get out of synch.
I understand. Easy to implement.
What about users on mobile devices with slow internet?
4G/5G is fast enough.
On 3G with HSPA+ OGS loads very slow. On pure 3G (UMTS without HSPA) it is a nightmare.
Things may change if voice/image/(other big) messages will be implemented.
Itâs wise to consider potential problems before proceeding.
Itâs premature to try to anticipate every problem before proceeding
Perfomance issues are almost always best explored by prototype and profile.
I look forward to a prototype, and am on standby to help with âHow to do Dev with OGS frontendâ if needed.
I donât want my opponents to be able to make random noises come out my speakers.
It is a good point. So we need a new checkbox in Individual sound options
Thatâs quite a weak argument here. Itâs interesting that a go server will exclude automatically consideration on voices. Why?
IMHO there is new development to investigate. With care as @Uberdude suggests but still, voice and video is used already with streaming. But in a very limited way
For the moderation part, itâs not acquired we got problems as there is quite a difference between a horde in a FPS and kibbitzers around a game.
I suggest some limited experimentation in which we try to replicate more a real life game (sounds and video) and adding what online brings (like kibbitzing not heard by the players).
Rather than a checkbox in settings, what about a play button on the clip? This is standard in existing chat interfaces and doesnât require a person to dig into the settings menu to opt in.
Lmao, this has bugged me forever 
not even for perf reasons - it also makes debugging websocket issues a PITA
The standard chat interface may be implemented. But the autoplay button is still required.
There is an issue. User need to monitor chat box for new messages while focused on the board. It is one of the cause of suggested feature. Especially in blitz.
Chat jamms the language processor of the brain. But I hope with autoplaying voice messages it will be less loaded than by reading text.
There are lots of studies that language processor in brain is like a general purpose processor in brain. When brain process speech it cannot do any computations including playing go. By monitoring the incoming voice messages to click the play button youâre distracted from the game.
(from 14:49 to 18:35) It is not a joke. It i a lecture at MIT.
I hate WhatsApp for this interface. Iâm waiting a new voice message while chat screen is active. When it arrives I got a sound notification. An nothing happens. I need click play button by manual. Why?
Not everyone speaks the same language on OGS. If you receive a message in a language you donât understand, itâs easy to translate it if itâs text, more difficult if itâs voice.
This almost seems like an argument against auto-play. I can just stop my opponentâs brain during a blitz game by talking to my opponent 
(of course thatâs absurd, but I really donât follow your line of thought)
To speak more seriously, if we do accept that speech processing presents a significant cognitive load, then a âplay buttonâ is the better option.
With autoplay, the cognitive load is introduced at the whim of the speaker. With a play button (which presumably presents no significant load), the listener can determine when the best time to play the message is - hopefully when they can afford a pause in the game.
It depends. The process of monitoring for incoming messages or clicking button may be more expensive. Not speech processing, language processing. That is different. As far as I know speech brain has different machinery for speech. So simple messages like âHelloâ, âAtariâ, âMisclickedâ, âPlease undoâ, âThanksâ will not jam brain at all.
But some sequence of words that donât make sense or hard to understand will. For example âWhite potato made by writing blue box on the red cucumber with a black sun of stone which had been eaten tomorrow last weekâ. However, this is a malicious use of this feature in order to mislead the opponent. Same may happen in text chat.
So the checkbox is required.
I think itâs bonkers that we are even talking about adding on significant bells and whistles features like this, when there are still glaring feature gaps in the core go-playing functionality of OGS such as Allow undo request on your move
And reminder:
Review is different. You can set up VC anywhere and attach link to the chat.
You can even stream it elsewhere or record.
I donât think such solutions are convenient for random games.
In principle I agree with you, but note that this is possible in front-end only code, which means that someone passionate about it enough to invest in it can do so, wheras core features are bottlenecked by limited development resources in the backend.
Remember though that a motivation was to be able to say âatariâ 
Whilst it may be possible, is that architecturally the best design? Closed-source back-end with limited development resources + open-source front-end with volunteers hacking in things as FE only which really should be full-stack is a recipe for bloated, unreliable and hard to maintain code. Saying âNoâ is one of the most important parts of product design. But yes I appreciate itâs a difficult balancing act.
Heh heh ⌠no-one said âyesâ yet
Itâs just that this is not the tradeoff:
This is a more legitimate concern:
⌠but that is only true if the proposed FE solution is in fact bad.
If enthusiasm about voice chat gets more people at least thinking about contributing, thatâd be a good thing IMO.
Itâs unfortunate that so many features get designed in a FE only way just because of that constraint 
