personally i like BIP-340 secp256k1 signatures. but the simple fact is that they are basically the same as ed25519 except with a group that has a couple more roots than 19. even the modulo multiplication of signatures is almost identical, basically schnorr. which was technically out of patent when satoshi dealt with it. and also, secp256k1 and ed25519 are both "nothing up my sleeve" curves and what's better about the bitcoin curve is you can use the exact same group to do ECDH where you have to use curve25519 to do ECDH in edwards universe. which is a problem.
compression should really be considered to be a transport layer thing, what is received by the client should be the uncompresssed binary anyway.
we don't need kinds. that's what tags can be used for. and we don't need multiple value fields, because the only reason why nostr has multiple fields is because of the "only single alpha character is indexable" idea. if you throw away that silly idea, then you see that kinds becomes a tag, which simplifies the database indexing and simplifies search notation as well. and it also means we can use standardised mimetypes, like email and http.
i like quic too but i think that for mostly non-interactive stuff it's a waste of time using sockets. you have requests, and you have push on the other side.
it would be zero change to most code to enable listening with quic protocol and connecting with it as well. and since it's all http, it could be in the headers to request transport upgrades other than websockets, like quic, i think that's already pretty much standardised.
TLS auth basically works on the same principle as nip-42, nip-98 and JWT anyway. signature, timestamp, challenge.
i thought you might appreciate my counterpoints on those.
i'm not against edwards curves at all but the support for ECDH to do symmetric encryption is very clumsy right now in comparison.
