From the Ecosystem page: "So, instead, Roughtime is only available for products that can be updated. The server lists have an explicit expiry time in them and we will actively seek to break clients that try to use old information in order to maintain ecosystem health. At the moment changing the hostname or port of a server is the easiest way to enforce this but we expect to add a per-server id in the future that clients would need to send in order to prove to the server that they have a current server list."
I see a slight chicken and egg problem here. This service is mostly needed to provide initial time synchronization to devices that have just powered on and don't know what time it is - but of course, since they don't know the time they have no way of checking the freshness of the server list. Which in practice means that a lot of devices will end up having to download a new server list every time they need to synchronize their time. That's a lot of load on the server providing the list, which effectively becomes a critical part of the Roughtime system that's hardcoded into the clients.
This is a good point and we might need to change things because of this; it depends on what client needs turn out to be.
But I'm hoping that the software-update mechanism is the foundation of any modern system, and that can use nonces to show freshness. It's fairly common for systems to update immediately on power-on and hopefully that will get the fresh Roughtime server-list that allows the rest of the system to come up.
(The alternative is that we try to guarantee that Roughtime servers will never change, and that's very hard.)
Why not just use a hash of the server list to query whether or not you're up to date? You ping the server with your hash and it replies OK or it sends you the latest one.
That reduces the impact of each query, but doesn't reduce the amount of queries.
Imagine if a few popular models of IoT devices take security seriously and get their time with roughtime. They are still built from cheap components with minimal capability for persistent writes though, because price is key. Any large blackout could mean that millions of these devices power up simultaniously, putting huge load on the list update server.
You essentially make the list update servers crucial infrastructure that has to potentially handle huge load spikes.
I see a slight chicken and egg problem here. This service is mostly needed to provide initial time synchronization to devices that have just powered on and don't know what time it is - but of course, since they don't know the time they have no way of checking the freshness of the server list. Which in practice means that a lot of devices will end up having to download a new server list every time they need to synchronize their time. That's a lot of load on the server providing the list, which effectively becomes a critical part of the Roughtime system that's hardcoded into the clients.