This comment caused me to watch Let’s Get Stone’d and while I think you’re absolutely right that a central stone workflow is entirely underappreciated, its a smaller ask to get the user.db centralized than it is to have our entire Flame setup reworked.
It did remind me why I used a sync’d user.db instead of symlinking everything to one location. Its the exact issue that you come up against in the video. The user can’t be open on two Flames at once. While there’s nothing wrong with just creating additional users like you do in the video it recreates the issue that I’m trying to avoid which is multiple usernames per user and default user settings. My inelegant solution last time was to compare the local users against the central database each night, write them back to the central database if any changes were detected, and then redistribute the users to all of the Flames.
I would love to change the method slightly but I’m not sure if its even possible. Ideally the application would “load” the central user by pulling a copy locally when booting into a project and then write the local user back to the server when exiting the application. Seems like it would have to load every user through the application start hook and then write them all back out on the exit hook which seems like a prohibitive amount of data to be moving each time. Also since Flame crashes so frequently on exit it probably wouldn’t be the most reliable solution.
Ultimately its a lot easier to not worry about any of that which is why I’m hoping to just read and write from a single central location. Its relatively rare that anyone would need to log in at two Flames concurrently so I’m willing to accept that as a downside in order to get the benefits. Just hoping there aren’t too many other downsides.
Do you manage your users in any way beyond the centralized stone and wire?