Philosophy ========== Some scattered thoughts by the architect, Neale. Hardening ----------- People are going to try to break this thing. It needs to be bulletproof. This pretty much set the entire design: * As much as possible is done client-side * Participants can attack their own web browsers as much as they feel like * Also reduces server load * We even made a puzzle category to walk people through creating brute-force attacks! * Your laptop is faster than our server * We give you the carrot of hashed answers and the hashing function * This removes one incentive to DoS the server * Generate static content whenever possible * Puzzles must be statically compiled before the event even starts * As much content as possible is generated by a maintenance loop * Minimize dynamic handling * There are only three (3) dynamic handlers * team registration * answer validation * server state (open puzzles + event log) * You can disable team registration if you want, just remove `teamids.txt` * I even removed token handling once I realized we replicate the user experience with the `answer` handler and some client-side JavaScript * As much as possible is read-only * The only read-write directory is `state` * This plays very well with Docker, which didn't exist when we designed MOTH * Server code should be as tiny as possible * Server should provide highly limited functionality * It should be easy to remember in your head everything it does * Server is also compiled * Static type-checking helps assure no run-time errors * Server only tracks who scored how many points at what time * This means the scoreboard program determines rankings * Want to provide a time bonus for quick answers? I don't, but if you do, you can just modify the scoreboard to do so. * Maybe you want to show a graph of team rankings over time: just replay the event log. * Want to do some analysis of what puzzles take the longest to answer? It's all there. Fairness --------- We spend a lot of time thinking about whether new content is going to feel fair. Or, more importantly, if there's a possibility for it to be viewed as unfair. It's possible to run fun events that don't focus so much on fairness, but those aren't the type of events we run. * People generally don't mind discovering that they could improve * People can get furious if they feel like some system is unfairly targeting them * Every team that does the same amount of work should have the same score * No time bonuses / decaying points * No penalties for trying things that don't work out * No one should ever feel like it's impossible to catch up * Achievements ("cheevos") work well here * Time-based awards (flags) don't mesh with this idea