I have been feeling like it was time to do something with SixSpotting again recently, but it was someone asking out on Mastodon how old the game was that led me to dig in further. It turns out the very first checkin was on 2014-05-21. SixSpotting is now officially 10 years old! On this occasion I'd like to reflect a little bit on the history of the game and share a little news.
Much of the code was written at TriPython meetings over the span of a few months. Being the Triangle (Raleigh-Durham-Chapel Hill, NC), there were three different meeting locations and they rotated between them. My house is convenient to two of them, so I would go and vibe off the energy of a bunch of us working on our various projects.
Originally the game used Postgres as its backend because I wanted an excuse to learn it. Most everything else I had done up to that point had been on MySQL, and I was able to drop most everything else on that server to SQLite, so it was nice to have a single database engine running. Eventually I had a need for MariaDB and wanted to keep that single engine, so I branched the code and ported it to the PyMySQL connector. The data itself was relatively easy to migrate (everything is in two tables) so I kept all the users and checkins.
It was tempting to say this is such a simple app and very niche so I could just store the passwords as plaintext, but I made sure to use good hashing algorithms. That simplicity means there is no password reset mechanism, mostly because I didn't want to deal with email. I did have a couple players need their passwords reset, which was an interesting challenge.
Many things in IT are cyclical. I have an application that moved to Postgres as its preferred engine. I find myself running two database engines again, but I would like to eventually move away from MariaDB. So, in November 2023 I updated the database code again to allow it to switch between engines with a config file update. I doubt I'll need to pivot back and forth frequently, but this was an opportunity to examine the schemas and unify the queries. There are no conditionals for the queries, only the connection object. Additional tweaks include making sure the timestamp objects are Y2038 compliant and a checkin rate limit (sorry SIDN Labs).
The game play itself is largely targeted at fellow networking people, though you certainly don't need to be one to get in on the fun. It was mainly a novel way to track how well deployment efforts were going. A fairly unique feature serves as another nudge: the site is only reachable over IPv6. This was done to serve as another tool for people trying to convince their ISPs to deploy IPv6. Most of those conversations usually end up going something like this:
User: Hi, when can I expect to see IPv6 on my connection?
ISP: IPv6 is not on our road map. We have no ETA on this.
User: Oh, OK. Goodbye.
Instead I hope the user can say "There's a website I can't reach. Can you please fix this?" Sadly the ISP response to this is varied based on how much knowledge their support department has, but at least it puts the impetus back on them to improve their service rather than just ending the conversation.
This 10 year anniversary seems like the perfect time to borrow a strategy from the big game studios and do a full reset. Delete all players and checkins and start anew. Quite a bit has changed in a decade of IPv6 deployment and it will be interesting to see how the scores shake out on the other side. And it means I don't have to migrate all the data again when switching back to Postgres. :) I'm planning to flip the switch on 2024-06-01. The first of the month falling on a Saturday makes it convenient and it will be done in time for this year's World IPv6 Day.
Thanks to everyone who has played over the years!