Earlier quoted context omitted.
Which is a naive way to implement reuse mitigation because you have have a db that grows endlessly. Send a nonce and have the user sign it. Make sure the nonce is only valid for one use (burn it after it’s used). Then you only have to remember active nonces and you can expire them after a short interval.
Used signatures are purged from the DB after they are no longer valid (too much time has passed). I realize this is a naive, toy implementation (in general). I wrote it to have a broader discussion.
The inclusion of a nonce/challenge (and other chosen-text and offline-attack mitigations) helps with a lot of security flaws, and that you've omitted them for no clear reason undermines your position as creator of a novel protocol.
As a trivial example, imagine that someone else comes up with a protocol that uses a signed current-date to authorise a bank transfer; as it's not distinguishable from your protocol, there would be many avenues for tricking a user into providing you with the ability to steal their money.
In responses elsewhere in the thread, you say that users should have a public key per website, but in your readme, you repeatedly imply that users have a single key-pair. "Register your base64 encoded public Ed25519 key with the website." "Use your private Ed25519 key to sign the current Unix Epoch Time" "Websites store the users' public keys."
Requiring users to keep generating keys and manage them manually introduces insecurity through non-compliance. It's not simple if you've got to manage something that behaves entirely like a local password database.
You say elsewhere "The demo website and the github repo contain this information" - but the demo website has no descriptive text (can you perhaps provide a link?) and the readme barely mentions threat models or goals. How do you prevent MitM attacks? Can your design support multi-party authentication or delegation of any kind?
I have no experience with WebAuthn, but it's likely that a lot of its features are to improve security in many ways, and omitting these features might make things easier at request-protocol level, but perhaps just simplistic overall.
You say you're trying to facilitate a conversation, but the proposal is so basic that you're effectively asking people to create a useful protocol for you.