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.)