Why I’m betting on Nostr

It is always fascinating reading VC hit pieces like these to see just how many leaps of faith they must make and bags of salt they must eat to justify their investments the way they do. With the benefit of hindsight, Sequoia waxing lyrical about world's first trillioniare remains the best example among them all.

Lightning is an online protocol, so your wallet must be available to complete the transaction. No online wallet, no zaps.

I had looked at nostr before, and I had some criticisms of it:

1. The serialization and canonization of JSON. Fortunately the conversion to arrays without floating point numbers avoids the problem with digitally signing the canonized JSON, but this is still messy. There are other problems with using JSON too, including inefficient binary data, restriction of which character sets you can use, lack of proper 64-bit integers, and others. I preferred a efficient binary format instead.

2. Servers cannot send messages to each other. I would allow it as an optional capability, in addition to clients sending messages to multiple servers.

3. It should not need WebSockets; plain TCP (with optional TLS; it should not be mandatory) would do. Other optional protocols can also be possible to do, e.g. HTTP POST requests, or even HTTP GET (or Gemini) to merely receive a single message by its ID. (WebSockets in binary mode could also still work.)

4. Character encoding. Unicode is too messy as well as other problems. My proposal is you can specify what code page to use, including an extended TRON code (including ISO-IR-169, Cangjie, and others). A few control codes might be used, e.g. line break, furigana, and text direction; for simplicity you might not need much more than that I suppose.

5. Lost messages. Blockchaining (i.e. each message contains the hash of the previous message) might help a bit, but still sometimes you will have lost one, or an entire account is lost without anyone else referencing them. Making this mandatory comes with many problems, but being optional also has different problems, so it is unclear.

6. Some other stuff, too (I do not remember all of them at this time).

I had tried to design a better one, but I did not know what to call it so I just reversed "nostr" to make "rtson", but that doesn't seems like very good either. (Although, maybe is not needed; NNTP is good enough anyways.)

1. I concur. But it's no big deal. 2. Nothing prevents this, but it would be specified as a sister protocol. I haven't seen it specified, but I know that relays are doing it. 3. Websockets allows pub-sub. Clients stay connected to relays and instantly get the next message when it arrives. Polling means either lots of polling or having delays. 4. I can't even comment on this one. 5. Optional chaining is possible and has been proposed.

I also started a nostr-like protocol back in November 2022 based on my gripes with it. Then I came to my senses... nobody is going to use my variant. Perfection is the enemy of the good.

Hmm. I hadn't considered that. In my defense, I'm actually not a crypto guy at all, and so I hadn't given much thought to the actual dynamics. And now that I think about it, I don't think I've seen many relays actually implement that particular protocol extension, and this is probably why.

On the other hand, I think it's reasonable to note that individual relays could very well change their proof-of-work requirement over time to deal with network conditions. Because clients are expected to send events to as many relays as possible, it's not unreasonable to suppose that a client's message might very well make it through _somewhere_, even if a particular relay won't accept their message at a particular moment. Clients can always try again later.

I think it's also worth treating PoW as part of a "swiss cheese model" for managing abuse. There are layers in front of it (since the protocol uses WebSockets, all your standard DDOS protections can sit in front) as well as behind it (blacklisting or throttling pubkeys you don't know very well.)

One example that comes to mind is another protocol extension which provides a mechanism for client authentication, where a server can send a challenge string, in which case the client is expected to respond with a special event type which includes that same challenge string. Requiring a much higher proof-of-work requirement for this message type (and then accepting a lower PoW for messages sent afterwards on the same connection) is at least one idea of a scheme for mitigating spam.

---

For what it's worth, I wouldn't say I'm a True Believer at this stage of the game, but I find the whole thing pretty compelling, and at the very least it's something fun to hack on and experiment with.