| 13 Jun 2023 |
 emily | the "This will cause the timer to start; and after 1 second start all the services with a randomised delay." idea sounds nice enough - but then we're talking about, your sites have broken SSL for up to an entire day? | 20:07:23 |
| emily | I'm curious how Caddy/certmagic handles this since it has pretty sophisticated logic for cert issue timing | 20:08:08 |
 m1cr0man | Could you let me know what you find from that? But to your point about one size fits all, it seems like we will need to introduce an option for users to decide what they want. We can default to the current situation, but provide an option like renewOnActivate for other situations? | 20:09:44 |
| emily | I'm tempted to say that people can just poke at the systemd.* options themselves if they really want rate limiting, but I'm biased :p | 20:10:27 |
| emily | I would consider it acceptable to do something out of the box if we found a solution that leads to large numbers of certs being activated in minutes rather than hours/days though | 20:10:48 |
| emily | if you have dozens/hundreds of certs then you're probably expecting initial setup to take about that long | 20:11:28 |
| emily | I don't want to significantly penalize the common case of just a few domains for that though, or stretch it out to "without manual intervention migrating your NixOS box will result in your sites being offline for the next day" | 20:11:54 |
| emily | fundamentally if you want your sites running with TLS you have to spend a certain amount of compute, memory and network to get there | 20:12:15 |
| m1cr0man | yep, I'm in full agreement with all of that. I might explore the chained services option to see how it performs and if there's a way to work around the activation delay, with the thought that this solution would be an optional (default off) feature of the module | 20:14:49 |
