Probably not just the “Learn to Play Go” section, but other sections as well don’t sync across devices. I changed a setting on the computer, but it didn’t update on the phone. So, different progress appears under the same account depending on whether if I’m on my computer, phone or tablet, or am I missing something?
It’s a great one to call out.
OGS technically is able to (and does) elect to have device-specific (most of them) or account specific settings.
For example, it (arguably) makes sense to have different sound settings on different devices.
But for sure “Where I am up to in Learn To Play Go” sounds like it should be an account level thing.
3 Likes
I suppose game chat template messages should be account level too.
Arguably 
The implementation of this is a 5 minute job (done).
Turns out I was wrong about that.
If it were the case that you were only ever logged into one device at one time, then syncing on login would be a breeze.
But… that’s a dream. You’re logged into your phone and your desktop, and you have the same darn Learn To Play tab open on both. And you expect the one on the phone to update to the next puzzle when you complete the current on the desktop eh…
4 Likes
Just broadcast state via Webscoket connections.
That would be exactly the case. And what would it look like the first time the implementation is complete? Ideally all the devices would be in a state where you are in the most advanced progress in each section.
1 Like
It’d be great if your up for helping with this - it sounds like you have the skills!
The trick is not receiving the state, the trick is changing the existing front end code to understand that it needs to be able to change state from “here” to “there”, for any “here” and “there”, at any time. As opposed to “the state always changes from N to N+1”.
I didn’t look at the code.
I suppose the account state event listener is global. Maybe I am wrong. Maybe each page has different code for events. In this case I hope event identifiers are unique. Maybe I am wrong here too. Maybe different events share the same name. But it is possible to rename. Then to merge event listeners.
Something like that.
It’s easy when you haven’t looked at the code, isn’t it
3 Likes
Okey. There is another way. It is possible to suggest a solution without looking at the code. There is an easy but very nasty solution.
When the state is changed just broadcast a notification about it to every device related to the user. On the frontend add simple listener to reload an entire page.
Of course, it is possible to simplify it more. It will even work if notification will be broadcasted to every connection. It is just a notification that some user has a change in state without any details about anything. Actually it is just a command to frontend to reload the page. It can be broadcasted to every user.
I hope users would appreciate it. Especially at blitz games.
I think you didn’t hear what I said.
The work involved is not “how to transmit” or “what to transmit”.
The work involved (drudgery, not a technical challenge) is changing the existing code so that it is able to jump from one random state to another.
It never ceases to both amaze and annoy me that people with a small amount of coding knowledge think that advice in a forum without even looking at the code can be remotely helpful.
We’d really love actual help with fixing issues like this.
It’s one of the comparatively rare problems these days that can totally be fixed in the front end, where the code is open source.
I’d invest countless time and effort to help anyone interested get started. I’ve done it before, starting with “I’d like to help but I don’t even know how to code”. Great, let’s teach you.
But don’t think for a moment that postulating solutions in the forum without looking at the code is even remotely helpful. It’s just showing off, annoying, demotivating and time wasting. Sorry - but I think you need to know this.
6 Likes
I appreciate the countless time helping me read the codebase and getting started with react etc 
6 Likes
It is not about the particular code. The issue is related to dozens of apps. The OGS is not the only.
Today is 2025. There are plenty helpful Web APIs for such thinks.
- Websockets as a base layer for online communication page (frontend) - backend (server).
- Service Workers as proxy. Here you handle cache and connection issues.
- Web Workers as backend level for page level. Web Workers may be shared between different tabs but not devices/browsers
- Broadcast Channels as communication between tabs and workers.
- And many other cool things like local storage, session storage and etc.
The basic idea is
- At page level you start or connect to Shared Worker. And open Broadcast Channel for communication inside browser. Page level code is only for the UI. All user actions like stone placements, preference updates and etc you post to Broadcast Channel. Also you listen to Broadcast Channel for incoming events such as opponent stone placement, game start, account specific updates notifications and etc for UI purposes.
- At Web Worker level you do all business logic such as maintain device and account state, websocket connection to backend (server), data exchange. You listen to Broadcast Channel for UI events and process them. If necessarily notify server via websocket. For example if you got an event from UI about device preference update such as volume you store it locally in Indexed DB (sorry but no localstorage at web workers ). If it is a stone placement event then you send a message with details via websocket. If you got a message via websocket about opponent stone, account state update and etc you post it to Broadcast Channel.
- At server side you process all messages from web workers and send notifications. If you got a an account preference update message you broadcast it to other web workers via websockets related to account.
It is very simple and very robust.
Sounds like the front-end code is rubbish and you just need to rewrite it.
Please read
Just kidding, with the “just” just to trigger you even more! I know there’s no just about it: at work we finally launched and got real users on the new version of our product which was a total rewrite of the front-end, and major changes to back-end too. It started 4 years ago, the original planned launch date was October 2023, we went live end of June 2025. Even that was a bit of a miracle and the result of a really hard push with long hours over these last several months.
4 Likes
Any code is rubbish and you always need to rewrite it. There is no such thing as perfect code. (c) me
Perfect JS code to maintain fresh state
window.setTimeout(() => {location.reload();}, 0);
If you were a man and I were a woman, this would be “mansplaining”
I can’t think of a tidy analogous term, to my regret.
We are continually rewriting OGS, of course we are, duh!
Why are you beating your chest here with your “knowledge” of Web APIs"?
I can’t be any clearer: it is not welcome.
A thread with a developer talking to a user about what they want and the challenges of implementing it is not the place for a third party to leap in and say “I know all these cool theoretical things that can help, aren’t I clever!” … but not actually offer to do anything.
I can’t dictate what you write in this public forum, but just know that you’re pissing me off with your egotistical contributions.
Why should you care?
That’s up to you. The person you’re pissing off is the one writing your site. I can spend time enthusiastically supporting requests like the OP’s, and supporting others to do that, or I can get distracted by contributions from the few unfortunate folk like you. It’s simply a fact that posts like yours do distract. If I were a better person, maybe they wouldn’t. 
Up till now, you didn’t necessarily know this - you were blissfully ignorant of how your contributions land. Now you can’t claim that anymore.
Your choice.
Can we just agree that no one knows how to implement this feature and move on
Nope, I don’t remotely agree with that.
I know how to implement it. The remote data protocol for server-side account data is already there.
As I said, it’s just front end coding drudgery, nothing mystical WebAPIish.
I shared the challenge with the OP, to reset my original estimate of the effort involved.
They agreed that the reason for the increased effort is valid.
My invitation of support to anyone who wants to help remains open.
1 Like
It’s okay to admit defeat