I need to finish up my Logical Map Whitepaper; however, I have an idea for Nostr that I can't tamp down. Nostr devs have figured out a great MVP for sending notes over relays (NIP-01), as well as dealt with many other issues via the other NIPs. My own use of Nostr for a crisis scenario, though, requires more control and efficiency. I think it would be useful to control both sides of the connection before application data flows. This will reduce spam and CPU/network use. It requires an issue by the server to specific clients. Now, part of the administrative nightmare can be mitigated by combining it with Nostr identity. Consider an MQTT broker a "tower", and an MQTT publisher client a "set" (as in CB/Shortwave set). A tower could issue certs for npubs. These npubs all have the same cert. The cert is just used to secure communication. The server has two ways to verify, then, the cert and the fact that the event objects were signed by the nsec.
Another NIP (NIP-TWR?) would define how this works on the client app (the web app running in the browser that connects to relays over Nostr). I'm thinking the set could be a local service that takes event objects over websockets and routes them through to the tower. The tower works on pub/sub with varying QoS values (deliver once, broadcast only, deliver more than once, etc... pure MQTT). There would be 40 topics on each tower that match. Towers share messages based on follower lists. Alice might have a set/tower tunnel to Tower A. Bob might have a set/tower tunnel to Tower B. If Alice posts "need help getting water", she could post it on channel 9 (matching CB emergency). Bob follows Alice. Bob will see a replicated message from Tower B on channel 9.
What I've done is broken up tiers of identity so that we get a middle tier rather than completely distributed. NIP-TWR could ensure compatibility easily, as the client app can do both (and read Kind 0 references for towers, etc).
MQTT has an advantage in that it already exists, offers pub/sub, has websocket options, is ubiquitous, and often uses self-signed TLS client certs. Much of the meta verification and communication could be handled over regular Nostr, but the key appeal of spammers (notifications and views) could be completely blocked out, yet still retain compatibility. No wacky WoT is needed, just a cert issued by a tower operator (and there is nothing stopping somebody from bringing up their own tower and updating their kind-0 entries). We know MQTT scales because of IoT.