Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

My dream for skotoslib #20

Open
shentino opened this issue May 4, 2021 · 6 comments
Open

My dream for skotoslib #20

shentino opened this issue May 4, 2021 · 6 comments

Comments

@shentino
Copy link

shentino commented May 4, 2021

Ideally, at least from my point of view, what I was hoping for most was to allow any other user to set up an interconnected fleet of servers that would let them run, in their own way, a functionally identical version of how skotos set up their own interconnected games, including a central auth server, separate games connected via the userapi -> userdb backend.

I had a plan for this but I burned out.

I guess time moves on and I fell behind.

@noahgibbs
Copy link

I mean, that's doable. Most users wouldn't want the maintenance burden of dealing with four+ games if they actually had users, though. If you're going to run even one game well, you'll normally want a team of multiple people.

With that said: the current system is actually the same one SkotOS was using for that. You just have a single thin-auth and multiple games, and hook them up with the shim server that makes an outgoing connection to each. It's been a long time since the UserDB was actually running in LPC as far as I can tell. It just used UserAPI to gateway over a socket to an auth server. Castle Marrach, for instance, is very clearly still running that way. That login.php link isn't going to be implemented by DGD.

I don't think we want literally one single auth server (maintained by ChatTheatre?) for everybody everywhere. For starters, the current Auth protocols are not nearly secure enough for that. But if a group wanted to run three games off a single auth server tomorrow, Skotos-Tech-style, that would be easy to do.

@shentino
Copy link
Author

shentino commented May 4, 2021

I mean, that's doable. Most users wouldn't want the maintenance burden of dealing with four+ games if they actually had users, though. If you're going to run even one game well, you'll normally want a team of multiple people.

With that said: the current system is actually the same one SkotOS was using for that. You just have a single thin-auth and multiple games, and hook them up with the shim server that makes an outgoing connection to each. It's been a long time since the UserDB was actually running in LPC as far as I can tell. It just used UserAPI to gateway over a socket to an auth server. Castle Marrach, for instance, is very clearly still running that way. That login.php link isn't going to be implemented by DGD.

I don't think we want literally one single auth server (maintained by ChatTheatre?) for everybody everywhere. For starters, the current Auth protocols are not nearly secure enough for that. But if a group wanted to run three games off a single auth server tomorrow, Skotos-Tech-style, that would be easy to do.

Oh good heavens I wasn't clear at all about what I meant, I don't want a literal single auth server globally at all, lol

Basically I want anyone to be able to run the same kind of sandbox that was skotos games.

@noahgibbs
Copy link

That should be entirely possible. You'd have to set up an SSH tunnel to replace local thin-auth on any server that didn't use local thin-auth. But beyond that, not difficult. The default config assumes you have a single server with thin-auth and one game. But I haven't removed the possibility to configure. I just have (what I feel is) a sensible set of defaults for somebody setting up their first game. If we get people setting up one game successfully, it'll be pretty easy to write tutorials on how to set it up as a confederation.

Right now, though, the focus is more on getting external people to successfully set up one game. So that's more of what you see as far as tests, docs, etc. Right now, setting up a SkotOS game is, frankly, too hard for most people. I'm simplifying where I can. And I'm also packaging up complicated things into neat little bundles where I can -- so often something with powerful configuration isn't documented fully. Nothing stops you from changing the portbase, using thin-auth on a different machine or otherwise pulling it apart onto more VMs. I shudder at trying to get a new user to figure out how to do that, though, so the default setup just puts it all in one place with minimal configuration.

The auth server, which has been running in PHP for Skotos Tech games for a long time now, will also be running in PHP for ChatTheatre SkotOS. I feel pretty okay with having an auth setup that is as Skotos-y as Castle Marrach, as far as fidelity to the Skotos roots :-)

@shentino
Copy link
Author

shentino commented May 4, 2021

Fidelity to the skotos roots is the linchpin of how I feel about pretty much this entire project, including my panic balk at removal of nuggets for example.

@noahgibbs
Copy link

Yeah. And I get worrying about that. I'm intentionally archiving everything right at the start and not permanently destroying anything - if you wanted the ancient UserDB-in-LPC code, it's definitely still in the Git repo. Similarly, Bilbo and Story Nuggets won't be purged. But both are probably going to wind up sunsetted in favour of more recent systems, at least long-term.

One difficulty with 20-year-old code is that you do want things to move along over time and change. Indeed, you can see a lot of places where the code has clearly done that, little odds and ends that once did something and now do something else. The ExportD port has an ancient implementation that isn't even compiled any more, and a "current" implementation that does nothing. The SyncTwo system is long-broken, and if I replace it how I want to it will be with something that looks a lot like the vault tool (plus a little polish and UI.)

To put it another way: "Skotos roots" sounds like a constant, but it really isn't. There's always been a state of gentle flux, things coming and going, and different games doing things in different ways. The trick isn't to pick one point in time and not change. The trick is to capture as much of that spirit of flexibility as possible while maintaining the interesting "feel" that people loved.

I'm not likely to change much in Base, for instance. It's remained relatively unchanging since the early days, and a lot of love has gone into it. It's clearly a very important part of the feel of Skotos.

But if, say, we added a different file format that was easier to write than the XML... That's a big change, sure, but it's also a lot like Karmode and other things people used anyway. It's just a slightly different lens on Skotos, and one that seems in keeping with the spirit. (Note: I am not currently planning to do this. It'd be on my long-term wishlist, though.)

I am also much harder on non-user-visible parts like the UserDB and the XML file format and so on than I am on things that directly affect how non-builders see the game. And it's for the same reason - SkotOS exists to build interesting virtual worlds. I don't cry for the loss of Bilbo or Story Nuggets if we have good replacements for them and can quickly rebuild what we lost. But I don't tear out thin-auth unless we have a pretty, usable replacement that's easy for getting new people into the game, whether I enjoy the quality of its internals or not.

Make sense?

@shentino
Copy link
Author

shentino commented May 4, 2021

Well, bilbo was already slated for deprecation even before the skotos breakup, so I don't cry over it either.

Overall makes kinda sense, even if it's too wide to wrap my narrow mind around at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants