Mea culpa: things I did wrong on Nostr

Things that we mostly can’t fix, but that maybe could have been done better if they were here from the beginning – or something like that.

• Choosing secp256k1 felt cool and maybe it still feels cool because it is the Bitcoin curve, but since many people have pointed out that other curves and algorithms are much faster maybe picking those would have been better.
• Writing a spec for direct messages and implementing them was bad. In my defense, it was an attempt to please the public, but still I should have not have done that, or thought more about it before doing it.
• For a long time I didn’t realize Nostr wasn’t useful just for “social networking” things. I wonder what else could have been better designed in the relay-client interface if the needs of non-social-networking apps were kept in mind.
• The querying system is sometimes too generic, it could have been better if it was more restrictive, but more complete. For example: allowing generic querying over tags is weird, can lead to O(n²) issues in some cases and relays are left to fend for themselves – on the other hand we can’t query for the absence of some tags. But I don’t know how any of these things could have been better even today, so maybe it wasn’t so bad.
• Making the events be JSON: sometimes I think this was a bad idea and a binary format would have been better, but most of the times I think Nostr wouldn’t have become any popular at all if this was the case – also binary is slower than JSON in JavaScript, so I guess this wasn’t a completely bad choice. Perhaps if something like NSON had been adopted from the start, though, that would have been better for everybody.

When I decided to write this I had one item in mind, but when I started I forgot what that was. I’ll add it here back when I remember.