What if you could run your node on a raspberry pi in your closet, and interact with thousands of others doing the same (at the cost of a static IP address)?

https://github.com/nostr-protocol/nips/blob/master/65.md

A judge from a dying empire doesn't matter in the larger scheme of things.

IMHO blockchain is an ugly terrible solution to a problem that had no other solution. The chain just gets bigger never smaller, requires expensive proof of work, requires complex synchronization protocols. Why so many people want to copy the worst part of bitcoin for their new billion dollar startup idea has always been beyond me.

No, nostr does not have a blockchain.

This is a current problem. The solution is sending a small message telling everyone where you post to lots and lots of relays, then just posting to a few of them.

So far, there haven't been many "bad and toxic actors". I have met one bad actor among thousands on nostr and I muted him. I heard there was porn in global chat, but my client doesn't even offer global chat.

People don't consider their relays "hostile", but they don't trust them with things they don't need to trust them with. That's not the contradiction you imagine. Relay operators are trusted with things like spam filtering, illegal content removal, etc. One method is that a proof-of-work is required to start writing to a relay, and your public key can be banned quickly for bad behavior, resulting in another long proof-of-work to try again.

Trusting a relay with account management, for example, is horrible. Trust as little as necessary.

> The protocol doesn't define a transport but seem to use WebSockets.

The protocol transport is over WebSockets.

> How does it handle poor/dropping connections?

The way HTTP underneath it handles poor/dropping connections. It is request-response like HTTP, there isn't state to recover, just try again.

> Does it allow usage of alternate transport protocols?

If you think it is useful, write a NIP for it.

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

Being readable is helpful for debugging. I agree there is less structure than could be used, but it is well-defined and libraries can more strongly type the data and name the fields, for example. One thing you can't easily do is go back and change the protocol, that would create far too much complexity.

> Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled?

The part that is signed is defined well enough that at least dozens (probably near a hundred now) coding implementations are inter-operating on this without issue. Is the definition formal and rigid enough to ensure nobody misinterprets it? Probably not. I've had to ask for clarification and when I got it, I put in a PR to change the NIP. It was accepted right away.

It is not XMPP. Have you read the XMPP RFCs? I couldn't even get through the table of contents of the first one. The guiding principle of nostr is that it is the simplest protocol that has a chance of working.