On my sites one just enters one's email and gets a link with a hash that sets a persistent cookie. No need for annoying passwords.

That's a cool concept.

If I understood you correctly:

1. The user first enters his email address on your site to login/register.
2. Your server then generates a nonce (say, 128-bit, Base64 encoded) and associates it with that email address.
3. The nonce is then sent to the user's email as the parameter of a hyperlinked URL (e.g. fschmidt.cool.site/authn/ZnNjaG1pZHQncyBzaXRl)
4. Your server checks the nonce for a) an associated email, and b) the time elapsed since generating the nonce and the endpoint call (say, less than 10mins)
5. If all checks pass, you produce a long(er) lived cookie to be used as a bearer token by the user agent (browser, app, etc.)

Which means that the user's email service is the de-facto (albeit indirect) authentication provider.

Cookies should not be valid indeterminately. You'd just be spreading that attack vector wide open. With that in mind, how would you deal with a user who has been inactive past the cookie's expiration date? Do you just send them a new URL containing a new nonce? How do you prevent an attack where nonces are requested repeatedly? Heuristically through API management or do you simply cap-and-throttle?