pull down to refresh
359 sats \ 3 replies \ @398ja 11 May 2023 \ on: reNostr: Faster, scalable, private nostr upgrade - a SegWit for Nostr nostr
Dr. Maxim Orlovsky posted this:
https://snort.social/e/nevent1qqs89t7lkfuz8mqmxc5sauwfwcltqkfyvqnty3gu8w3v3sq7uqdp9hcpzamhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuegzyz8war66qqh9x05lnll0znr38kjyns3l2m6yzhnej42jqadq95wnwqcyqqqqqqgu0typn
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
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