I could well be wrong, but In my humble and uneducated opinion, I found the parallel with rK-selection inadequate.
Considering that protocols are winner-take-all, the most appropriate strategy seems to be, first to optimise for adoption by lowering the barrier of entry, then later for security. Why spend $$$$ for the most expensive lock to secure something no-one uses?
I am in favour of a backward compatible nip-88, but not of a new separate protocol. But maybe we could build integrations in the future, similar to what we currently have between nostr and the fediverse
reply
I might've missed context, but it doesn't sound to me like he's arguing R or K is better - merely that they both exist as strategies.
Backwards compatibility is usually the right move unless it prevents the project from achieving its goal. Just like Bitcoin has and likely will need to hard fork, nostr might too. It seems to me nostr has bigger fish to fry than reworking the encoding but what do I know.
reply
Not the same but a great potential improvement with backwards compatibility: https://github.com/nostr-protocol/nips/blob/nip93-nson/93.md
reply
You're probably right about him not arguing about which one is better. I've read the note again and I think he's just using it as an analogy to make a point. Analogies are never 100% perfect...
reply
This is classic software nerd optimizing for the most "correct" protocol instead of using the one with users and adoption.
reply
Why they are using a TLV encoding when they could use something like flatbuffers which already has libraries/benchmarks/etc available?
reply
It creates a great opportunity to be upset at other developers that will inevitably end up messing up the bytestreams...
reply