DerbyOS is peer-to-peer, not client-server. There must be no single centralized point of failure (even if the network crashes, the nodes should still be able to gather their own information, and they will come back together when the network comes back). Obviously, if one of those nodes is the visible scoreboard, the bout itself would stop.
DerbyOS peers exchange a variety of messages:
- Node identification: "I'm scorekeeper for Blue team"
- General game information/configuration: "Here's the roster for the Red team", "Periods are 20 minutes"
- Time Synchronization: "What is the period/jam/wall time?" "What jam are we in?" (and corresponding answers)
- On going events: "Red Team 123 gained lead jammer status", "Blue Team 456 got a back block"
- Back-fill events: "What happened in jam 1"?
As a part of DerbyXML, all data should include a "source" - what node it was that claimed this to be true (making it easier to deal with "lineup says 123 was the jammer, but scorekeeper said 456"). Furthermore, data can be corrected later ("jammer ref determines that they missed a skater in the box, and so that last pass was 3 points, not 2 points").
The initial version of DerbyOS assumes that the network transport provides authentication (i.e., the WiFi is password protected). As such, one should not allow the public to access the same network as is used by DerbyOS (since nothing stops a fan in the seat from changing the scores then). Since DerbyOS is built on top of ØMQ, any authentication will be ultimately be provided by that layer (which we will hope will not be subject to session hijacking like web-based products would be).
There is also no direct support for web-based nodes in DerbyOS. This is more a side effect of using ØMQ than a specific design (but also falls out of "no central server" + web browser security models), but one could write a simple local server that provides a web-based interface.