A rule that goes hand in hand is "no special codes" there will, of course, be protocol level identifiers, but things like Blockchains, URLs, global names that require an authority are out. All meaning is what the users say it is.

At least in nostr with the outbox model, there is no routing, and nodes don't control which other nodes they communicate with. I imagined the thing just like browsers connecting to websites. But a completely different architecture could be routed, where a node connects to certain known and trusted neighbors only, and data is routed node-to-node. Such protocols are slower and less reliable, having so many middle-men, but of course if you use Tor under nostr you are pretty much doing that same thing. I lean towards clients connecting to untrusted nodes. And clients being considered very difficult to develop because they must be security hardened. In the same way that browsers must be. In a similar way that computer hardware has to be bug-free before they tape out. Making nostr "simple" proliferates insecure half-assed software. I lean towards complexity as a way of weeding out developers who can't be trusted to make hardened software. But this is just a current leaning. I'm interested in exploring architectures where clients don't have to talk to nodes they don't trust... I just don't see the big picture right now of how this could work without so many downsides.

I don't think it has to be super complicated.. at least you can aim for exactly what you need and nothing you don't to try to keep implementation "easy" and bugs low. For instance I wouldn't send a timestamp. It isn't that you don't want them, it is that you can't trust them. Things are just going to break if you require timestamps and then try to do clever things with them. No one will use them consistently or correctly. I do agree that Nostr's simplicity makes everything else you want hard. If you want to encrypt properly.. good luck. The best you can do is TLS and just trust your relays. Back to p2p, yes it is slow and buggy, but we can have the best of both worlds by doing web-of-trust stuff in a peer-to-peer like fashion but actually disseminate data in a traditional hub and spoke architecture. I wouldn't make it wide open. I think you want authentication as part of the protocol for automatic spam suppression, but you can still have big servers serving stuff. I am tempted to make requesting files non-authenticated. If they are just identified by their hash, good luck guessing a 32byte string. The counter argument is that if you know a commonly shared file "never gonna give you up" then you could find out who is interested in it by seeing whose relays have it cached. Authentication should be fairly straightforward however, a server just accepts connections from a list of keys (not the user's master, just one they use for talking to that server) If I am using a particular relay as a mailbox, I can give it a list of my friends keys to filter on. So every request is something like <Recipient Encryption Key> <Sender Signing Key> <Ephemeral Sender Encryption Key> <Signature> <Payload> I complect things further by having those first two keys Scoped to specific application permissions so the final destination node knows how to unpack the Payload. Key management needs to be perfect. I don't want a "Words with Friends" app to be able to read bank transactions. With properly scoped keys you could leak your whole keystore database to a malicious application developer and still not be compromised. (Assuming encrypted at rest) All that, I get off on such tangents, to say, while the key requirements etc may be complicated the actual protocol does not need to be.