Nostr.how – A Complete Guide to Nostr
I read everything there and all NIPs (they look like underage RFCs, but also drunk) and I'm a little confused.- The protocol doesn't define a transport but seem to use WebSockets. How does it handle poor/dropping connections? Does it allow usage of alternate transport protocols?- Messages are defined as JSON but doesn't use much of its structure anyway. Some fields are just arrays of values. And even then some parts are just strings with some other arbitrary syntax. Seems like a poor choice.- Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled?- Messages are just sent around without any delivery confirmation. There's a NIP to introduce delivery confirmation from the client to relay. And then there's another NIP to signal completion of messages retrieval from the relay. Both are optional.- It's unclear how to preserve/port data. A relay is supposed to keep (or not) messages and the client is supposed to send messages to multiple relays. But what happens when a relay goes down? Can a client send messages to a new relay? Should the client keep all messages just for such a case?Overall feeling after reading all that is it's XMPP but worse. It's worse defined. It's not quite decentralised as there's a single point of failure: relay. And it's unspecified how to handle demise of a relay and port data to another relay. Signing and encryption is nice but message structure makes me feel dirty. XMPP wasn't inititally meant for a decentralised public messaging but there are a few XEPs that do exactly that, as well as signing and E2E encryption. And all other good stuff like BOSH (XMPP over HTTP), for example.