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.)
> 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.
How is "your messages can be in any coding on earth" simple compared to "everything is unicode, and every single programming language, storage solution and client library has been unicode-aware for at least a decade now"?
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.
> 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.
Then, how are you supposed to know how to do if it is not specified?
> 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.
You can remain connected even with plain TCP (or with TLS) too. But, if you only want to send or receive a single message (rather than waiting as new messages arrive), then HTTP would also do.
> I also started a nostr-like protocol back in November 2022 based on my gripes with 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.)