Code review comment for lp:~mir-team/mir/attestable-timestamps-server

> > I can also imagine a desire to provide a different verification model in a
> > (hypothetical) downstream server.
>
> libmircookie is going to be used by Content Hub; Mir will share the secret
> with CH, and then CH will be able to verify cookies sent to it (for copy/paste
> and drag/drop operations). This is why it's a split-out library.
>
> As such, it's actively harmful for downstream servers to override the
> implementation, as multiple processes need to agree on the method to verify
> cookies.

Oh, I agree that within a UI stack it ought to be fixed. Just imagining that someone /could/ want a different implementation in a different stack.

> As an added bonus feature, it also means that libmircookie can have an actual
> ABI that's stable even under mild code churn :).

OK, that's an argument for a separate library. In fact, is it really something that will need to be released with every Mir release? Or should it be a separate project?

BTW this last argument doesn't address the "Cheshire Cat vs Interface" point. The ABI could easily be:

std::unique_ptr<CookieFactory> CookieFactory::create_with_secret(std::vector<uint8_t> const& secret);
std::unique_ptr<CookieFactory> CookieFactory::create_without_secret();